idnits 2.17.1 draft-claise-export-application-info-in-ipfix-03.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 document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC5102]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 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 473 has weird spacing: '...512/tcp rem...' == Line 476 has weird spacing: '...512/udp use...' == Line 480 has weird spacing: '...513/tcp rem...' == Line 485 has weird spacing: '...513/udp mai...' == Line 489 has weird spacing: '...514/tcp cmd...' == (2 more instances...) -- The document date (October 30, 2011) is 4556 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC5811' is mentioned on line 535, but not defined == Missing Reference: 'RFC5353' is mentioned on line 543, but not defined ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) Summary: 6 errors (**), 0 flaws (~~), 10 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. Ben-Dvora 5 Expires: April 30, 2012 Cisco Systems, Inc. 6 October 30, 2011 8 Export of Application Information in IPFIX 9 draft-claise-export-application-info-in-ipfix-03 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) 2011 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 IPFIX information 53 model specified in [RFC5102] to export application information. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 58 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 59 "OPTIONAL" in this document are to be interpreted as described 60 in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Overview ............................................... 4 65 1.1. IPFIX Documents Overview .......................... 4 66 2. Introduction ........................................... 5 67 2.1. Application Information Use Cases .................... 7 68 3. Terminology ............................................ 7 69 3.1. New Terminology ................................... 8 70 4. applicationTag Information Element Specification ....... 8 71 4.1. Existing Classification Engine IDs ................ 10 72 4.2. Options Template Record for the Application Name .. 12 73 4.3. Resolving IANA L4 port collisions.................. 12 74 5. Grouping the Applications with the Attributes........... 15 75 5.1. Options Template Record for the Attribute Values .. 16 76 6. Application Tag Examples................................ 17 77 6.1. Example 1: Layer 2 Protocol ....................... 17 78 6.2. Example 2: Standardized IANA Layer 3 Protocol ..... 18 79 6.3. Example 3: Cisco Systems Proprietary Layer 3 Protocol 19 80 6.4. Example 4: Standardized IANA Layer 4 Port ......... 21 81 6.5. Example 4: Layer 7 Application .................... 22 82 6.6. Example: port Obfuscation ......................... 23 83 6.7. Example: Application Mapping Options Template ..... 24 84 6.8. Example: Attributes Values Options Template Record 25 85 7. IANA Considerations .................................... 26 86 7.1. applicationDescription ............................ 27 87 7.2. applicationTag .................................... 27 88 7.3. applicationName ................................... 27 89 7.4. classificationEngineId ............................ 27 90 7.5. applicationCategoryName ........................... 28 91 7.6. applicationGroupName .............................. 28 92 7.7. p2pTechnology ..................................... 28 93 7.8. tunnelTechnology .................................. 28 94 7.9. encryptedTechnology................................ 29 95 8. Security Considerations ................................ 29 96 9. References.............................................. 29 97 10. Acknowledgement ....................................... 30 98 11. Authors' Addresses .................................... 31 99 Appendix A. Additions to XML Specification of IPFIX 100 Information Elements....................................... 32 102 List of Figures and Tables 104 Figure 1: applicationTag Information Element ............... 8 105 Figure 2: Selector ID encoding ............................. 10 106 Table 1: Existing Classification Engine IDs ................ 11 107 Table 2: IANA layer 4 port collisions between UDP and TCP .. 13 108 Table 3: IANA layer 4 port collisions between SCTP and TCP . 15 109 Table 4: Existing Application Tag Static Attributes ....... 16 111 1. Overview 113 1.1. IPFIX Documents Overview 115 The IPFIX Protocol [RFC5101] provides network administrators with 116 access to IP Flow information. 118 The architecture for the export of measured IP Flow information 119 out of an IPFIX Exporting Process to a Collecting Process is 120 defined in the IPFIX Architecture [RFC5470], per the requirements 121 defined in RFC 3917 [RFC3917]. 123 The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records 124 and Templates are carried via a congestion-aware transport 125 protocol from IPFIX Exporting Processes to IPFIX Collecting 126 Processes. 128 IPFIX has a formal description of IPFIX Information Elements, 129 their name, type and additional semantic information, as specified 130 in the IPFIX information model [RFC5102]. 132 In order to gain a level of confidence in the IPFIX 133 implementation, probe the conformity and robustness, and allow 134 interoperability, the Guidelines for IPFIX Testing [RFC5471] 135 presents a list of tests for implementers of compliant Exporting 136 Processes and Collecting Processes. 138 The Bidirectional Flow Export [RFC5103] specifies a method for 139 exporting bidirectional flow (biflow) information using the IP 140 Flow Information Export (IPFIX) protocol, representing each Biflow 141 using a single Flow Record. 143 The "Reducing Redundancy in IP Flow Information Export (IPFIX) 144 and Packet Sampling (PSAMP) Reports" [RFC5473] specifies a 145 bandwidth saving method for exporting Flow or packet 146 information, by separating information common to several Flow 147 Records from information specific to an individual Flow Record: 148 common Flow information is exported only once. 150 2. Introduction 152 Today service providers and network administrators are looking 153 for visibility into the packet content rather than just the 154 packet header. Some network devices Metering Processes inspect 155 the packet content and identify the applications that are 156 utilizing the network traffic. Applications in this context 157 are defined as networking protocols used by networking 158 processes that exchange packets between them (such as the web 159 applications, peer to peer applications, file transfer, e-mail 160 applications, etc.). Combined with other information elements, 161 some of which being application specific, the applications can 162 be further characterized. 163 Examples include: web application to a specific domain, per 164 user specific traffic, a video application with a specific 165 codec, etc... 167 The application identification is based on different kind of 168 methods or even a combination of such methods: 169 1. L2 protocols (such as ARP, PPP, LLDP) 170 2. IP protocols (such as ICMP, IGMP, GRE) 171 3. TCP or UDP ports (such as HTTP, Telnet, FTP) 172 4. Application layer header (of the application to be 173 identified) 174 5. Packet data content 175 6. Packets and traffic behavior 177 The exact application identification methods are part of the 178 Metering Process internals that aims to provide an accurate 179 identification with a minimum false identification. This task 180 requires a sophisticated Metering Process since the protocols 181 do not behave in a standard manner. 182 1. Applications use port obfuscation where the application 183 run on different port than the IANA assigned one. For 184 example a HTTP server might run a TCP port 23 (assigned 185 to telnet in [IANA-PORTS]) 186 2. IANA does not accurately reflect how certain ports are 187 "commonly" used today. Some ports are reserved, but 188 the application either never became prevalent or is not 189 in use today. 190 3. The application behavior and identification logic 191 become more and more complex 193 For that reason, such Metering Processes usually detect 194 application based on multiple mechanisms in parallel. 195 Detecting applications based only on port matching might 196 wrongly identify the traffic. Note that this example stresses 197 the need for the engine strength. If the Metering Process is 198 capable of detecting applications more accurately it is 199 considered as stronger and more accurate. 201 Similarly, a reporting mechanism that uses L4 port based 202 applications only, such as L4:, would have a 203 similar issues. The reporting system should be capable of 204 reporting the applications classified using all types for 205 mechanisms. In particular applications that does not have any 206 IANA port definition. While a mechanism to export application 207 information should be defined, the L4 port being in use must be 208 exported using the destination port (destinationTransportPort 209 at [IANA-IPFIX]) in the corresponding NetFlow record. 211 Cisco Systems uses the IPFIX application tag as described in 212 section 4. to export the application information with the IPFIX 213 protocol [RFC5101]. 215 Application could be defined at different OSI layers, from the 216 layer 2 to the layer 7. Examples: Cisco Discovery Protocol is 217 layer 2 application, ICMP is layer 3 application [IANA-PROTO], 218 HTTP is layer 4 application [IANA-PORTS], and skype is layer 7. 220 While an ideal solution would be an IANA registry for 221 applications above (or inside the payload of) the well known 222 ports [IANA-PORTS], this solution is not always possible as the 223 some applications require well known specifications. 224 Therefore, some reverse engineering is required, as well as a 225 ubiquitous language for application identification. Clearly 226 not realistic. 228 As this specification focuses on the application information 229 encoding, this document doesn't contain an application registry 230 for non IANA applications. However, a reference to the Cisco 231 assigned numbers for the Application Tag and the different 232 attribute assignments can be found at [CISCO]. 234 2.1. Application Information Use Cases 236 There are several use cases on which the application 237 information is used: 239 1. Network Visibility 241 This is one of the main use cases for using the application 242 information. This use case is also called application 243 visibility. Network administrators are using such 244 application visibility to understand the main network 245 consumers, network trends and user behavior. 247 2. Billing Services 249 In some cases, network providers are willing to bill 250 different applications differently. For example, provide 251 different billing for VoIP and Web browsing. 253 3. Congestion Control 255 While the traffic demand is increasing (mainly due to the 256 high usage of peer to peer applications, video applications 257 and web download applications), the providers revenue 258 doesn't grow. Providers are looking at a more efficient way 259 to control and prioritize the network utilization. An 260 application aware bandwidth control system is used to 261 prioritize the traffic based on the applications, giving the 262 critical applications priority over the non-critical 263 applications. 265 4. Security Functions 267 Application knowledge is sometimes used in security functions 268 in order to provide comprehensive functions such as 269 Application based firewall, URL filtering, Parental 270 control, Intrusion detection, etc. 272 All of the above use cases require exporting of application 273 information to provide the network function itself or to log 274 the network function operation. 276 3. Terminology 278 IPFIX-specific terminology used in this document is defined in 279 Section 2 of the IPFIX protocol specification [RFC5101]. As in 281 [RFC5101], these IPFIX-specific terms have the first letter of 282 a word capitalized when used in this document. 284 3.1. New Terminology 286 Application Tag 288 A unique identifier for an application. 290 4. applicationTag Information Element Specification 292 This document specifies the applicationTag Information 293 Element, which is composed of two parts: 295 1. 8 bits of Classification Engine ID. The Classification 296 Engine can be considered as a specific registry for 297 application assignment. 298 2. m bits of Selector ID. The Selector ID length varies 299 depending on the Classification Engine ID. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Class. Eng. ID| Selector ID ... | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | ... | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 1: applicationTag Information Element 311 Classification Engine ID 313 A unique identifier for the engine which determined the 314 Selector ID. Thus the Classification Engine ID defines the 315 context for the Selector ID. 317 Selector ID 318 A unique identifier of the application for a specific 319 Classification Engine ID. 321 Note that the Selector ID term is in sync with the PSAMP 322 terminology. See [RFC5476], Packet Sampling (PSAMP) Protocol 323 Specifications. 325 When an application is detected, the most granular 326 application is encoded in the Application Tag: for example, 327 ICMP would be encoded as layer 3 value 1, SNMP as layer 4 328 value 161, bittorent as layer 7 value 69. 330 The overall length of the applicationTag Information Element 331 may be specified either in the IPFIX Template Record or by 332 using an IPFIX Variable-Length Information Element. The 333 receiver / decoder must respect this length rather than using 334 the Classification Engine ID to make an assumption about the 335 Selector ID size. 337 When exporting applicationTag information in IPFIX, the 338 applicationTag SHOULD be encoded in a variable-length 339 Information Element [RFC5101]. However, if a legacy protocol 340 such as NetFlow version 9 is used, and this protocol doesn't 341 support variable length Information Elements, then either 342 multiple templates (one per applicationTag length), or a 343 single template corresponding to the maximum sized 344 applicationTag MUST be used. This avoids the need for 345 multiple Template Records with different applicationTag 346 lengths when the IPFIX variable length encoding [RFC5101] is 347 not available. 349 As a consequence, although some Application Tags can be 350 encoded in a smaller number of bytes (eg, an IANA L3 protocol 351 encoding would take 2 bytes, while an IANA L4 port encoding 352 would take 3 bytes), nothing prevents an Exporting Process 353 from exporting all Application Tags with a larger fixed 354 length. 356 Note that the Selector ID value is always encoded in the 357 least significant bits as shown: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |Class. Eng. ID | zero-valued upper-bits ... | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | ... Selector ID | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 2: Selector ID encoding 369 4.1. Existing Classification Engine IDs 371 The following Engine IDs have been allocated by Cisco 372 Systems. 374 Name Value Description 376 0 Invalid. 377 IANA-L3 1 The IANA protocol (layer 3) number is 378 exported in the Selector ID. 379 See 380 http://www.iana.org/assignments/proto 381 col-numbers. 382 CANA-L3 2 Cisco Systems proprietary layer 3 383 definition. Cisco Systems can still 384 export its own layer 3 protocol 385 numbers, while waiting for IANA to 386 assign it. The Selector ID has a 387 global significance for all Cisco 388 Systems devices under CANA 389 governance. Hopefully the same IDs 390 will be maintained after the IANA 391 standardization. 392 IANA-L4 3 IANA layer 4 well-known port number 393 is exported in the Selector ID. 394 See 395 http://www.iana.org/assignments/port- 396 numbers. 397 Note: as a flow is unidirectional, it 398 contains the destination port in a 399 flow from the client to the server. 400 CANA-L4 4 Cisco Systems proprietary layer 4 401 definition. Cisco Systems can still 402 export its own layer 4 port numbers, 403 while waiting for IANA to assign it. 405 The Selector ID has global 406 significance for all Cisco Systems 407 devices under CANA governance. 408 Hopefully the same ID will be 409 maintained after the IANA 410 standardization. Example: IPFIX had 411 the port 4739 pre-assigned in the 412 IETF draft for years. While waiting 413 for the IANA registration, we could 414 use this Selector ID. 415 5 Reserved. 416 USER- 6 The Selector ID represents 417 Defined applications defined by the user 418 (using CLI or GUI) based on the 419 methods described in section 2. 420 7 Reserved. 421 8 Reserved. 422 9 Reserved. 423 10 Reserved. 424 11 Reserved. 425 CANA-L2 12 The Selector ID represents the Cisco 426 Systems unique global layer 2 427 applications. The Selector ID has a 428 global significance. 429 CANA-L7 13 The Selector ID represents the Cisco 430 Systems unique global ID for the 431 layer 7 applications. The Selector ID 432 has global significance for all Cisco 433 Systems devices. 434 14 Reserved. 435 15 Reserved. 436 16 Reserved. 437 17 438 to Available. 439 254 440 MAX 255 255 is the maximum Engine ID. 442 Table 1: Existing Classification Engine IDs 444 Note 1: "CANA = Cisco Systems Assigned Number Authority", 445 Cisco Systems's version of IANA for internal IDs. 447 Note 2: This is an extensible list, and new Classification 448 Engine IDs may be allocated at any time. See [CISCO] for the 449 latest version. 451 4.2. Options Template Record for the Application Name 453 For engines which specify locally unique Application Tags 454 (which means unique per engine and per router), an Options 455 Template Record (see [RFC5101]) MUST be used to export the 456 correspondence between the Application Tag, the Application 457 Name, and the Application Description. This is called the 458 "options application-table". For engines which specify 459 globally unique Application Tags, an Options Template Record 460 SHOULD be used to export the correspondence between the 461 Application Tag, the Application Name and the Application 462 Description, unless the mapping is hardcoded in the NetFlow 463 Collector, or known out of band (for example, by polling a 464 MIB). 466 4.3. Resolving IANA L4 port collisions 468 Even if the IANA L4 ports usually point to the same protocols 469 for both UDP, TCP or other transport types, there are some 470 exceptions. The following table lists 10 ports that have 471 different protocols assigned for TCP and UDP: 473 exec 512/tcp remote process execution; 474 # authentication performed using 475 # passwords and UNIX login names 476 comsat/biff 512/udp used by mail system to notify users 477 # of new mail received; currently 478 # receives messages only from 479 # processes on the same machine 480 login 513/tcp remote login a la telnet; 481 # automatic authentication performed 482 # based on priviledged port numbers 483 # and distributed data bases which 484 # identify "authentication domains" 485 who 513/udp maintains data bases showing who's 486 # logged in to machines on a local 487 # net and the load average of the 488 # machine 489 shell 514/tcp cmd 490 # like exec, but automatic 491 authentication 492 # is performed as for login server 493 syslog 514/udp 494 oob-ws-https 664/tcp DMTF out-of-band secure web services 495 # management protocol 496 # Jim Davis 497 498 # June 2007 499 asf-secure-rmcp 664/udp ASF Secure Remote Management 500 # and Control Protocol 501 rfile 750/tcp 502 kerberos-iv 750/udp kerberos version iv 503 submit 773/tcp 504 notify 773/udp 505 rpasswd 774/tcp 506 acmaint_dbd 774/udp 507 entomb 775/tcp 508 acmaint_transd 775/udp 509 busboy 998/tcp 510 puparp 998/udp 511 garcon 999/tcp 512 applix 999/udp Applix ac 514 Table 2: IANA layer 4 port collisions between UDP and TCP 516 The following table lists 19 ports that have different 517 protocols assigned for TCP and SCTP: 519 # 3097/tcp Reserved 520 itu-bicc-stc 3097/sctp ITU-T Q.1902.1/Q.2150.3 521 Greg Sidebottom 522 # 5090/tcp 523 car 5090/sctp Candidate AR 524 # 5091/tcp 525 cxtp 5091/sctp Context Transfer Protocol 526 RFC 4065 - July 2005 527 # 6704/tcp Reserved 528 frc-hp 6704/sctp ForCES HP (High Priority) channel 529 # [RFC5811] 530 # 6705/tcp Reserved 531 frc-mp 6705/sctp ForCES MP (Medium Priority) channel 532 # [RFC5811] 533 # 6706/tcp Reserved 534 frc-lp 6706/sctp ForCES LP (Low priority) channel 535 # [RFC5811] 536 # 9082/tcp 537 lcs-ap 9082/sctp LCS Application Protocol 538 # Kimmo Kymalainen 539 540 04 June 2010 541 # 9902/tcp 542 enrp-sctp-tls 9902/sctp enrp/tls server channel 543 # [RFC5353] 544 # 11997/tcp 545 # 11998/tcp 546 # 11999/tcp 547 wmereceiving 11997/sctp WorldMailExpress 548 wmedistribution 11998/sctp WorldMailExpress 549 wmereporting 11999/sctp WorldMailExpress 550 Greg Foutz 551 March 2006 552 # 25471/tcp 553 rna 25471/sctp RNSAP User Adaptation for Iurh 554 # Dario S. Tonesi 555 556 07 February 2011 557 # 29118/tcp Reserved 558 sgsap 29118/sctp SGsAP in 3GPP 559 # 29168/tcp Reserved 560 sbcap 29168/sctp SBcAP in 3GPP 561 # 29169/tcp 562 iuhsctpassoc 29169/sctp HNBAP and RUA Common Association 563 John 564 Meredith 565 08 September 2009 566 # 36412/tcp 567 s1-control 36412/sctp S1-Control Plane (3GPP) 568 # KimmoKymalainen 569 570 01 September 2009 571 # 36422/tcp 572 x2-control 36422/sctp X2-Control Plane (3GPP) 573 # Kimmo Kymalainen 574 575 01 September 2009 576 # 36443/tcp 577 m2ap 36443/sctp M2 Application Part 578 # Dario S. Tonesi 579 580 07 February 2011 581 # 36444/tcp 582 m3ap 36444/sctp M3 Application Part 583 # Dario S. Tonesi 584 585 07 February 2011 587 Table 3: IANA layer 4 port collisions between SCTP and TCP 589 Instead of imposing the transport protocol (UDP/TCP/SCTP/etc.) 590 in the scope of the "options application-table" Options Template 591 for all applications (on top of having the transport protocol as 592 key-field in the Flow Record definition), we define that the L4 593 application is always TCP related, by convention. So, whenever 594 the Collector has a conflict in looking up IANA, it would choose 595 the TCP choice. As a result, the UDP L4 applications from Table 596 2 and the SCTP L4 applications from table 3 are assigned in the 597 Cisco L7 Application Tag range (ie, under Classification Engine 598 ID 13): 600 Currently, there are no discrepancies between the well known 601 ports for TCP and DCCP. 603 5. Grouping the Applications with the Attributes 605 Due to the high number of different application tags, 606 categorizing them into groups offers the benefits of easier 607 reporting and action, such as QoS policies. Indeed, most 608 applications with the same characteristics should be treated the 609 same way; for example, all video traffic. 611 Attributes are statically assigned per application tag and are 612 independent of the traffic. The attributes are listed below: 614 Name Description 616 Category An attribute that provides a first 617 level categorization for each 618 application tag. Examples include: 619 browsing, email, file-sharing, 620 gaming, instant messaging, voice- 621 and-video, etc... 622 The category attribute is encoded by 623 the ApplicationCategoryName 624 Information Element. 626 Application- An attribute that groups multiple 627 Group application tags that belong to the 628 same networking application. For 629 example, the ftp-group contain the 630 ftp-data (port 20), ftp (port 20), 631 ni-ftp (port 47), sftp (port 115), 632 bftp (port 152), ftp-agent(port 633 574), ftps-data (port 989). The 634 application-group attribute is 635 encoded by the ApplicationGroupName 636 Information Element. 638 P2P-Technology Specifies if the application tag is 639 based on peer-to-peer technology. 640 The P2P-technology attribute is 641 encoded by the p2pTechnology 642 Information Element. 644 Tunnel- Specifies if the application tag is 645 Technology used as a tunnel technology. The 646 tunnel-technology attribute is 647 encoded by the tunnelTechnology 648 Information Element. 650 Encrypted Specifies if the application tag is 651 an encrypted networking protocol. 652 The encrypted attribute is encoded 653 by the encryptedTechnology 654 Information Element. 656 Table 4: Existing Application Tag Static Attributes 658 Every application is assigned to one ApplicationCategoryName, 659 one ApplicationGroupName, has one p2pTechnology, one 660 tunnelTechnology, and one encryptedTechnology. 662 5.1. Options Template Record for the Attribute Values 664 An Options Template Record (see [RFC5101]) is used to export the 665 correspondence between each Application Tag and its related 666 Attribute values. An alternative way for the Collecting Process 667 to learn the correspondence is to populate these mappings out of 668 band, for example, by loading a CSV file containing the 669 correspondence table. 671 The Attributes Option Template contains the ApplicationTag as a 672 scope field, followed by the ApplicationCategoryName,, the 673 ApplicationGroupName, the p2pTechnology, the tunnelTechnology, 674 and the encryptedTechnology Information Elements. 676 A list of attributes may conveniently be exported using a 677 subTemplateList per [RFC6313]. 679 An example is given in section 6.8. below. 681 6. Application Tag Examples 683 The following examples are created solely for the purpose of 684 illustrating how the extensions proposed in this document are 685 encoded. 687 6.1. Example 1: Layer 2 Protocol 689 From the list of Classification Engine IDs in Table 1, we can 690 see that the layer 2 Classification Engine ID is 12: 692 L2 12 The Selector ID represents the layer 2 693 applications. The Selector ID has a global 694 significance. 696 From the list of layer 2 protocols at [cisco], we can see that 697 PPP has the value 24: 699 NAME Selector ID 700 ppp 24 702 So, in the case of layer 2 protocol PPP, the Classification 703 Engine ID is 12 while the Selector ID has the value 24. 705 Therefore the Application Tag is encoded as: 707 0 1 708 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | 12 | 24 | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 So the Application Tag has the value of 3097. Instead of 714 representing the Application Tag in hexadecimal format, the 715 format '12...24' is used for simplicity in the examples below. 717 Flexible NetFlow creates a Template Record with a few 718 Information Elements: amongst other things, the Application Tag. 719 For example: 721 - sourceIPv4Address (key field) 722 - destinationIPv4Address (key field) 723 - ipDiffServCodePoint (key field) 724 - applicationTag (key field) 725 - octetTotalCount (non key field) 727 For example, a Flow Record corresponding to the above Template 728 Record may contain: 730 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 731 ipDiffServCodePoint=0, applicationTag='12...24', 732 octetTotalCount=123456 } 734 The Collector has all the required information to determine that 735 the application is PPP, because the Application Tag uses a 736 global and well know registry, ie the IANA protocol number. 737 The 24 value is globally unique within Cisco Systems for 738 Classification Engine ID 12, so the Collector can determine 739 which application is represented by the Application Tag by 740 loading the registry out of band. 742 6.2. Example 2: Standardized IANA Layer 3 Protocol 744 From the list of Classification Engine IDs in Table 1, we can 745 see that the IANA layer 3 Classification Engine ID is 1: 747 IANA- 1 The IANA protocol (layer 3) number is 748 L3 exported in the Selector ID. 749 See 750 http://www.iana.org/assignments/protocol- 751 numbers.. 753 From the list of IANA layer 3 protocols (see [IANA-PROTO]), we 754 can see that ICMP has the value 1: 756 Decimal Keyword Protocol Reference 757 1 ICMP Internet Control Message [RFC792] 759 So in the case of the standardized IANA layer 3 protocol ICMP, 760 the Classification Engine ID is 1, and the Selector ID has the 761 value of 1. 763 Therefore the Application Tag is encoded as: 765 0 1 766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | 1 | 1 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 So the Application Tag has the value of 257. Instead of 772 representing the Application Tag in hexadecimal format, the 773 format '1...1' is used for simplicity in the examples below. 775 Flexible NetFlow creates a Template Record with a few 776 Information Elements: amongst other things, the Application Tag. 777 For example: 779 - sourceIPv4Address (key field) 780 - destinationIPv4Address (key field) 781 - ipDiffServCodePoint (key field) 782 - applicationTag (key field) 783 - octetTotalCount (non key field) 785 For example, a Flow Record corresponding to the above Template 786 Record may contain: 788 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 789 ipDiffServCodePoint=0, applicationTag='1...1', 790 octetTotalCount=123456 } 792 The Collector has all the required information to determine that 793 the application is ICMP, because the Application Tag uses a 794 global and well know registry, ie the IANA L3 protocol number. 796 6.3. Example 3: Cisco Systems Proprietary Layer 3 Protocol 798 Assume that Cisco Systems has specified a new layer 3 protocol 799 called "foo". 801 From the list of Classification Engine IDs in Table 1, we can 802 see that the Cisco Systems layer 3 Classification Engine ID is 803 2: 805 CANA- 2 Cisco Systems proprietary layer 3 806 L3 definition. Cisco Systems can still export 807 its own layer 3 protocol numbers, while 808 waiting for IANA to assign it. The 809 Selector ID has a global significance for 810 all Cisco Systems devices under CANA 811 governance. Hopefully the same IDs will be 812 maintained after the IANA standardization. 814 A global registry within Cisco Systems specifies that the "foo" 815 protocol has the value 90: 817 Protocol Protocol Id 818 foo 90 820 So in the case of Cisco Systems layer 3 protocol foo, the 821 Classification Engine ID is 2, and the Selector ID has the value 822 of 90. 824 Therefore the Application Tag is encoded as: 826 0 1 827 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | 2 | 90 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 So the Application Tag has the value of 602. Instead of 833 representing the Application Tag in hexadecimal format, the 834 format '2..90' is used for simplicity in the examples below. 836 Flexible NetFlow creates a Template Record with a few 837 Information Elements: amongst other things, the Application Tag. 838 For example: 840 - sourceIPv4Address (key field) 841 - destinationIPv4Address (key field) 842 - ipDiffServCodePoint (key field) 843 - applicationTag (key field) 844 - octetTotalCount (non key field) 845 For example, a Flow Record corresponding to the above Template 846 Record may contain: 848 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 849 ipDiffServCodePoint=0, applicationTag='2...90', 850 octetTotalCount=123456 } 852 Along with this Flow Record, a new Options Template Record would 853 be exported, as shown in Section 6.7. 855 6.4. Example 4: Standardized IANA Layer 4 Port 857 From the list of Classification Engine IDs in Table 1, we can 858 see that the IANA layer 4 Classification Engine ID is 3: 860 IANA- 3 IANA layer 4 well-known port number is 861 L4 exported in the selector ID. 862 See http://www.iana.org/assignments/port- 863 numbers. 865 Note: as a flow is unidirectional, it 866 contains the destination port in a flow 867 from the client to the server. 869 From the list of IANA layer 4 ports (see [IANA-PORTS]), we can 870 see that SNMP has the value 161: 872 Keyword Decimal Description 873 snmp 161/tcp SNMP 874 snmp 161/udp SNMP 876 So in the case of the standardized IANA layer 4 SNMP port, the 877 Classification Engine ID is 3, and the Selector ID has the value 878 of 161. 880 Therefore the Application Tag is encoded as: 882 0 1 883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | 3 | 161 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 Flexible NetFlow creates a Template Record with a few 889 Information Elements: amongst other things, the Application Tag. 890 For example: 892 - sourceIPv4Address (key field) 893 - destinationIPv4Address (key field) 894 - protocol (key field) 895 - ipDiffServCodePoint (key field) 896 - applicationTag (key field) 897 - octetTotalCount (non key field) 899 For example, a Flow Record corresponding to the above Template 900 Record may contain: 902 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 903 protocol=17, ipDiffServCodePoint=0, 904 applicationTag='3..161', octetTotalCount=123456 } 906 The Collector has all the required information to determine that 907 the application is SNMP, because the Application Tag uses a 908 global and well know registry, ie the IANA L4 protocol number. 910 6.5. Example 4: Layer 7 Application 912 In this example, the Metering Process has observes some Citrix 913 traffic. 915 From the list of Classification Engine IDs in Table 1, we can 916 see that the L7 unique Engine ID is 13: 918 L7 13 The Selector ID represents the Cisco Systems 919 unique global ID for the layer 7 920 application. The Selector ID has a global 921 significance for all Cisco Systems devices. 923 Suppose that the Metering Process returns the ID 10000 for 924 Citrix traffic. 926 So, in the case of this Citrix application, the Classification 927 Engine ID is 13 and the Selector ID has the value of 10000. 929 Therefore the Application Tag is encoded as: 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | 13 | | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | 10000 | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 So the Application Tag has the value of '13..10000'. 941 Note that the figure shows that the Exporting Process exports 942 the value 10000 in 7 bytes: this is pure speculation. However, 943 it doesn't matter as the applicationTag would be exported in a 944 variable length Information Element. 946 Flexible NetFlow creates a Template Record with a few 947 Information Elements: amongst other things, the Application Tag. 948 For example: 950 - sourceIPv4Address (key field) 951 - destinationIPv4Address (key field) 952 - ipDiffServCodePoint (key field) 953 - applicationTag (key field) 954 - octetTotalCount (non key field) 956 For example, a Flow Record corresponding to the above Template 957 Record may contain: 959 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 960 ipDiffServCodePoint=0, applicationTag='13...10000', 961 octetTotalCount=123456 } 963 The 10000 value is globally unique within Cisco Systems, so the 964 Collector can determine which application is represented by the 965 Application Tag by loading the registry out of band. 967 Along with this Flow Record, a new Options Template Record would 968 be exported, as shown in Section 6.7. 970 6.6. Example: port Obfuscation 972 For example, a HTTP server might run a TCP port 23 (assigned to 973 telnet in [IANA-PORTS]). If the Metering Process is capable of 974 detecting HTTP in the same case, the Application Tag 975 representation must contain HTTP. However, if the reporting 976 application wants to determine whether or the default HTTP port 977 80 or 8080 was used, it must export the destination port 978 (destinationTransportPort at [IANA-IPFIX]) in the corresponding 979 NetFlow record. 981 In the case of a standardized IANA layer 4 port, the 982 Classification Engine ID is 2, and the Selector ID has the value 983 of 80 for HTTP (see [IANA-PORTS]). 985 Therefore the Application Tag is encoded as: 987 0 1 2 988 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | 3 | 80 | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 Flexible NetFlow creates a Template Record with a few 994 Information Elements: amongst other things, the Application Tag. 995 For example: 997 - sourceIPv4Address (key field) 998 - destinationIPv4Address (key field) 999 - protocol (key field) 1000 - destinationTransportPort (key field) 1001 - applicationTag (key field) 1002 - octetTotalCount (non key field) 1004 For example, a Flow Record corresponding to the above Template 1005 Record may contain: 1007 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 1008 protocol=17, destinationTransportPort=23, 1009 applicationTag='3..80', octetTotalCount=123456 } 1011 The Collector has all the required information to determine that 1012 the application is HTTP, but runs on port 23. 1014 6.7. Example: Application Mapping Options Template 1016 Along with the Flow Records shown in the above examples, a new 1017 Options Template Record would be exported to express the 1018 Application Name and Application Description associated with 1019 each Application Tag. 1021 The Options Template Record contains the following Information 1022 Elements: 1024 1. Scope = applicationTag. 1026 From RFC 5101: "The scope, which is only available in the 1027 Options Template Set, gives the context of the reported 1028 Information Elements in the Data Records." 1030 2. applicationName. 1032 3. applicationDescription. 1034 The Options Data Record associated with the examples above would 1035 contain, for example: 1037 { scope=applicationTag='2...90', 1038 applicationName="foo", 1039 applicationDescription="The Cisco foo protocol", 1041 scope=applicationTag='13...10000', 1042 applicationName="Citrix", 1043 applicationDescription="A Citrix application" } 1045 When combined with the example Flow Records above, these Options 1046 Template Records tell the NetFlow collector: 1048 1. A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 1049 to destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 1050 applicationTag of '12...90', which maps to the "foo" 1051 application. 1053 2. A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 1054 to destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 1055 Application Tag of '13...10000', which maps to the "Citrix" 1056 application. 1058 6.8. Example: Attributes Values Options Template Record 1060 Along with the Flow Records shown in the above examples, a new 1061 Options Template Record is exported to express the values of the 1062 different attributes related to the Application Tags. 1064 The Options Template Record would contain the following 1065 Information Elements: 1067 1. Scope = applicationTag. 1069 From RFC 5101: "The scope, which is only available in the 1070 Options Template Set, gives the context of the reported 1071 Information Elements in the Data Records." 1073 2. applicationCategoryName. 1075 3. applicationGroupName 1077 4. p2pTechnology 1079 5. tunnelTechnology 1081 6. encryptedTechnology 1083 The Options Data Record associated with the examples above would 1084 contain, for example: 1086 { scope=applicationTag='2...90', 1087 applicationCategoryName="foo-category", 1088 applicationGroupName="foo-group", 1089 p2pTechnology=NO 1090 tunnelTechnology=YES 1091 encryptedTechnology=NO 1093 When combined with the example Flow Records above, these Options 1094 Template Records tell the NetFlow collector: 1096 A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 to 1097 destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 1098 applicationTag of '12...90', which maps to the "foo" 1099 application. This application can be characterized by the 1100 relevant attributes values. 1102 7. IANA Considerations 1104 This document specifies 9 new IPFIX Information Elements: the 1105 applicationDescription, applicationTag, applicationName, 1106 classificationEngineId, applicationCategoryName, 1107 applicationGroupName, p2pTechnology, tunnelTechnology, and 1108 encryptedTechnology. 1110 New Information Elements to be added to the IPFIX Information 1111 Element registry at [IANA-IPFIX] are listed below. 1113 EDITOR'S NOTE: the XML specification in Appendix A must be updated 1114 with the elementID values allocated below. 1116 7.1. applicationDescription 1118 Name: applicationDescription 1119 Description: 1120 Specifies the description of an application. 1121 Abstract Data Type: string 1122 Data Type Semantics: 1123 ElementId: 94 1124 Status: current 1126 7.2. applicationTag 1128 Name: applicationTag 1129 Description: 1130 Specifies an Application Tag. 1131 Abstract Data Type: octetArray 1132 Data Type Semantics: identifier 1133 Reference: See section 4. of [EDITORS NOTE: this document] for the 1134 applicationTag Information Element Specification. 1135 ElementId: 95 1136 Status: current 1138 7.3. applicationName 1140 Name: applicationName 1141 Description: 1142 Specifies the name of an application. 1143 Abstract Data Type: string 1144 Data Type Semantics: 1145 ElementId: 96 1146 Status: current 1148 7.4. classificationEngineId 1150 Name: classificationEngineId 1151 Description: 1152 Specifies the classification engine according to Table 1 in 1153 [EDITORS NOTE: this document]. 1154 Abstract Data Type: unsigned8 1155 Data Type Semantics: identifier 1156 ElementId: 101 1157 Status: current 1159 7.5. applicationCategoryName 1161 Name: applicationCategoryName 1162 Description: 1163 An attribute that provides a first level categorization for each 1164 Application Tag. 1165 Abstract Data Type: string 1166 Data Type Semantics: 1167 ElementId: 1168 Status: current 1170 7.6. applicationGroupName 1172 Name: applicationGroupName 1173 Description: 1174 An attribute that groups multiple Application Tags that belong 1175 to the same networking application 1176 Abstract Data Type: string 1177 Data Type Semantics: 1178 ElementId: 1179 Status: current 1181 7.7. p2pTechnology 1183 Name: p2pTechnology 1184 Description: 1185 Specifies if the Application Tag is based on peer-to-peer 1186 technology. Possible values are: "yes", "no", and "unassigned" 1187 Abstract Data Type: string 1188 Data Type Semantics: 1189 ElementId: 288 1190 Status: current 1192 7.8. tunnelTechnology 1194 Name: tunnelTechnology 1195 Description: 1196 Specifies if the application tag is used as a tunnel technology. 1197 Possible values are: "yes", "no", and "unassigned" 1199 Abstract Data Type: string 1200 Data Type Semantics: 1201 ElementId: 289 1202 Status: current 1204 7.9. encryptedTechnology 1206 Name: encryptedTechnology 1207 Description: 1208 Specifies if the application tag is an encrypted networking 1209 protocol. Possible values are: "yes", "no", and "unassigned" 1210 Abstract Data Type: string 1211 Data Type Semantics: 1212 ElementId: 290 1213 Status: current 1215 8. Security Considerations 1217 The same security considerations as for the IPFIX Protocol 1218 [RFC5101] apply. 1220 9. References 1222 9.1. Normative References 1224 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1225 Requirement Levels, BCP 14, RFC 2119, March 1997. 1227 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 1228 Information Export (IPFIX) Protocol for the Exchange of 1229 IP Traffic Flow Information", RFC 5101, January 2008. 1231 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 1232 J. Meyer, "Information Model for IP Flow Information 1233 Export", RFC 5102, January 2008. 1235 9.2. Informative References 1237 [RFC792] J. Postel, Internet Control Message Protocol, RFC 792, 1238 September 1981. 1240 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1241 Requirements for IP Flow Information Export, RFC 3917, 1242 October 2004. 1244 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 1245 Export Using IP Flow Information Export (IPFIX)", RFC 1246 5103, January 2008. 1248 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 1249 Quittek, "Architecture for IP Flow Information Export", 1250 RFC 5470, March 2009. 1252 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 1253 for IP Flow Information Export (IPFIX) Testing", RFC 1254 5471, March 2009. 1256 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 1257 Redundancy in IP Flow Information Export (IPFIX) and 1258 Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. 1260 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol 1261 Specifications", RFC 5476, March 2009. 1263 [RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S. Yates, 1264 "Export of Structured Data in IP Flow Information 1265 Export (IPFIX)", RFC6313, July 20111 1267 [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xml 1269 [IANA-PORTS] http://www.iana.org/assignments/port-numbers 1271 [IANA-PROTO] http://www.iana.org/assignments/protocol-numbers 1273 [CISCO] http://www.cisco.com 1275 10. Acknowledgement 1277 The authors would like to thank their many colleagues across Cisco 1278 Systems who made this work possible. 1280 11. Authors' Addresses 1282 Benoit Claise 1283 Cisco Systems Inc. 1284 De Kleetlaan 6a b1 1285 Diegem 1813 1286 Belgium 1288 Phone: +32 2 704 5622 1289 EMail: bclaise@cisco.com 1291 Paul Aitken 1292 Cisco Systems (Scotland) Ltd. 1293 96 Commercial Quay 1294 Commercial Street 1295 Edinburgh, EH6 6LX, United Kingdom 1297 Phone: +44 131 561 3616 1298 EMail: paitken@cisco.com 1300 Nir Ben-Dvora 1301 Cisco Systems Inc. 1302 32 HaMelacha St., 1303 P.O.Box 8735, I.Z.Sapir 1304 South Netanya, 42504 1305 Israel 1307 Phone: +972 9 892 7187 1308 EMail: nirbd@cisco.com 1309 Appendix A. Additions to XML Specification of IPFIX Information 1310 Elements 1312 This appendix contains additions to the machine-readable 1313 description of the IPFIX information model coded in XML in 1314 Appendix A and Appendix B in [RFC5102]. Note that this appendix 1315 is of informational nature, while the text in Section 7. 1316 (generated from this appendix) is normative. 1318 The following field definitions are appended to the IPFIX 1319 information model in Appendix A of [RFC5102]. 1321 1325 1326 1327 Specifies the description of an application. 1328 1329 1330 1332 1337 1338 1339 Specifies an Application Tag. 1340 1341 1342 1343 1344 See section 4. of [EDITORS NOTE: this document] for the 1345 applicationTag Information Element Specification. 1346 1347 1348 1350 1354 1355 1356 Specifies the name of an application. 1357 1358 1359 1361 1366 1367 1368 Specifies the classification engine according to Table 1369 1 in [EDITORS NOTE: this document]. 1370 1371 1372 1374 1379 1380 1381 An attribute that provides a first level categorization 1382 for each Application Tag. 1383 1384 1385 1387 1392 1393 1394 An attribute that groups multiple Application Tags 1395 that belong to the same networking application. 1396 1397 1398 1400 1404 1405 1406 Specifies if the Application Tag is based on peer- 1407 to-peer technology. Possible values are: "yes", 1408 "no", and "unassigned". 1409 1410 1411 1413 1417 1418 1419 Specifies if the application tag is used as a 1420 tunnel technology. Possible values are: "yes", 1421 "no", and "unassigned". 1422 1423 1424 1426 1430 1431 1432 Specifies if the application tag is an encrypted 1433 networking protocol. Possible values are: "yes", 1434 "no", and "unassigned". 1435 1436 1437