idnits 2.17.1 draft-claise-export-application-info-in-ipfix-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 : ---------------------------------------------------------------------------- ** 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 465 has weird spacing: '...512/tcp rem...' == Line 468 has weird spacing: '...512/udp use...' == Line 472 has weird spacing: '...513/tcp rem...' == Line 477 has weird spacing: '...513/udp mai...' == Line 481 has weird spacing: '...514/tcp cmd...' == (2 more instances...) -- The document date (March 9, 2011) is 4797 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 527, but not defined == Missing Reference: 'RFC5353' is mentioned on line 535, but not defined ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) == Outdated reference: A later version (-06) exists of draft-ietf-ipfix-structured-data-05 Summary: 3 errors (**), 0 flaws (~~), 11 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: September 9, 2011 Cisco Systems, Inc. 6 March 9, 2011 8 Export of Application Information in IPFIX 9 draft-claise-export-application-info-in-ipfix-01 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.................. 9 72 4.2. Options Template Record for the Application Name... 11 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 Protocol19 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. applicationCategoryName............................ 27 90 7.5. applicationSubCategoryName......................... 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 9.1. Normative References............................... 29 98 9.2. Informative References............................. 29 99 10. Acknowledgement........................................ 30 100 11. Authors' Addresses..................................... 31 101 Appendix A. Additions to XML Specification of IPFIX 102 Information Elements....................................... 32 104 List of Figures and Tables 106 Figure 1: applicationTag Information Element ............... 8 107 Figure 2: Selector ID encoding ............................. 9 108 Table 1: Existing Classification Engine IDs ............... 11 109 Table 2: IANA layer 4 port collisions between UDP and TCP . 13 110 Table 3: IANA layer 4 port collisions between SCTP and TCP 14 111 Table 4: Existing Application Tag Static Attributes ....... 16 113 1. Overview 115 1.1. IPFIX Documents Overview 117 The IPFIX Protocol [RFC5101] provides network administrators with 118 access to IP Flow information. 120 The architecture for the export of measured IP Flow information 121 out of an IPFIX Exporting Process to a Collecting Process is 122 defined in the IPFIX Architecture [RFC5470], per the requirements 123 defined in RFC 3917 [RFC3917]. 125 The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records 126 and Templates are carried via a congestion-aware transport 127 protocol from IPFIX Exporting Processes to IPFIX Collecting 128 Processes. 130 IPFIX has a formal description of IPFIX Information Elements, 131 their name, type and additional semantic information, as specified 132 in the IPFIX information model [RFC5102]. 134 In order to gain a level of confidence in the IPFIX 135 implementation, probe the conformity and robustness, and allow 136 interoperability, the Guidelines for IPFIX Testing [RFC5471] 137 presents a list of tests for implementers of compliant Exporting 138 Processes and Collecting Processes. 140 The Bidirectional Flow Export [RFC5103] specifies a method for 141 exporting bidirectional flow (biflow) information using the IP 142 Flow Information Export (IPFIX) protocol, representing each Biflow 143 using a single Flow Record. 145 The "Reducing Redundancy in IP Flow Information Export (IPFIX) and 146 Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth 147 saving method for exporting Flow or packet information, by 148 separating information common to several Flow Records from 149 information specific to an individual Flow Record: common Flow 150 information is exported only once. 152 2. Introduction 154 Today service providers and network administrators are looking for 155 visibility into the packet content rather than just the packet 156 header. Some network devices Metering Processes inspect the 157 packet content and identify the applications that are utilizing 158 the network traffic. Applications in this context are defined as 159 networking protocols used by networking processes that exchange 160 packets between them (such as the web applications, peer to peer 161 applications, file transfer, e-mail applications, etc.). Combined 162 with other information elements, some of which being application 163 specific, the applications can be further characterized. 164 Examples include: web application to a specific domain, per user 165 specific traffic, a video application with a specific codec, 166 etc... 168 The application identification is based on different kind of 169 methods or even a combination of such methods: 170 1. L2 protocols (such as ARP, PPP, LLDP) 171 2. IP protocols (such as ICMP, IGMP, GRE) 172 3. TCP or UDP ports (such as HTTP, Telnet, FTP) 173 4. Application layer header (of the application to be 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 do 181 not behave in a standard manner. 182 1. Applications use port obfuscation where the application run on 183 different port than the IANA assigned one. For example a HTTP 184 server might run a TCP port 23 (assigned to telnet in [IANA- 185 PORTS]) 186 2. IANA does not accurately reflect how certain ports are 187 "commonly" used today. Some ports are reserved, but the 188 application either never became prevalent or is not in use 189 today. 190 3. The application behavior and identification logic become more 191 and more complex 193 For that reason, such Metering Processes usually detect 194 application based on multiple mechanisms in parallel. Detecting 195 applications based only on port matching might wrongly identify 196 the traffic. Note that this example stresses the need for the 197 engine strength. If the Metering Process is capable of detecting 198 applications more accurately it is considered as stronger and more 199 accurate. 201 Similarly, a reporting mechanism that uses L4 port based 202 applications only, such as L4:, would have a similar 203 issues. The reporting system should be capable of reporting the 204 applications classified using all types for mechanisms. In 205 particular applications that does not have any IANA port 206 definition. While a mechanism to export application information 207 should be defined, the L4 port being in use must be exported using 208 the destination port (destinationTransportPort at [IANA-IPFIX]) in 209 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 applications 221 above (or inside the payload of) the well known ports [IANA- 222 PORTS], this solution is not always possible as the some 223 applications require well known specifications. Therefore, some 224 reverse engineering is required, as well as a ubiquitous language 225 for application identification. Clearly not realistic. 227 As this specification focuses on the application information 228 encoding, this document doesn't contain an application registry 229 for non IANA applications. However, a reference to the Cisco 230 assigned numbers for the Application Tag and the different 231 attribute assignments can be found at [CISCO]. 233 2.1. Application Information Use Cases 235 There are several use cases on which the application information 236 is used: 238 1. Network Visibility 240 This is one of the main use cases for using the application 241 information. This use case is also called application 242 visibility. Network administrators are using such application 243 visibility to understand the main network consumers, network 244 trends and user behavior. 246 2. Billing Services 248 In some cases, network providers are willing to bill different 249 applications differently. For example, provide different 250 billing for VoIP and Web browsing. 252 3. Congestion Control 254 While the traffic demand is increasing (mainly due to the high 255 usage of peer to peer applications, video applications and web 256 download applications), the providers revenue doesn't grow. 257 Providers are looking at a more efficient way to control and 258 prioritize the network utilization. An application aware 259 bandwidth control system is used to prioritize the traffic based 260 on the applications, giving the critical applications priority 261 over the non-critical applications. 263 4. Security Functions 265 Application knowledge is sometimes used in security functions in 266 order to provide comprehensive functions such as Application 267 based firewall, URL filtering, Parental control, Intrusion 268 detection, etc. 270 All of the above use cases require exporting of application 271 information to provide the network function itself or to log the 272 network function operation. 274 3. Terminology 276 IPFIX-specific terminology used in this document is defined in 277 Section 2 of the IPFIX protocol specification [RFC5101]. As in 279 [RFC5101], these IPFIX-specific terms have the first letter of a 280 word capitalized when used in this document. 282 3.1. New Terminology 284 Application Tag 286 A unique identifier for an application. 288 4. applicationTag Information Element Specification 290 This document specifies the applicationTag Information Element, 291 which is composed of two parts: 293 1. 8 bits of Classification Engine ID. The Classification 294 Engine can be considered as a specific registry for 295 application assignment. 296 2. m bits of Selector ID. The Selector ID length varies 297 depending on the engine. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Class. Eng. ID| Selector ID ... | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | ... | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 1: applicationTag Information Element 309 Classification Engine ID 311 A unique identifier for the engine which determined the 312 Selector ID. Thus the Classification Engine ID defines the 313 context for the Selector ID. 315 Selector ID 317 A unique identifier of the application for a specific 318 Classification Engine ID. 320 Note that the Selector ID term is in sync with the PSAMP 321 terminology. See [RFC5476], Packet Sampling (PSAMP) Protocol 322 Specifications. 324 When an application is detected, the most granular application 325 is encoded in the Application Tag: for example, ICMP would be 326 encoded as layer 3 value 1, SNMP as layer 4 value 161, bittorent 327 as layer 7 value 69. 329 The overall length of the applicationTag Information Element may 330 be specified either in the IPFIX Template Record or by using an 331 IPFIX Variable-Length Information Element. The receiver / 332 decoder must respect this length rather than using the 333 Classification Engine ID to make an assumption about the 334 Selector ID size. 336 When exporting applicationTag information in IPFIX, the 337 applicationTag SHOULD be encoded in a variable-length 338 Information Element [RFC5101]. However, if a legacy protocol 339 such as NetFlow version 9 is used, and this protocol doesn't 340 support variable length Information Elements, then either 341 multiple templates (one per applicationTag length), or a single 342 template corresponding to the maximum sized applicationTag MUST 343 be used. This avoids the need for multiple Template Records with 344 different applicationTag lengths when the IPFIX variable length 345 encoding [RFC5101] is not available. 347 As a consequence, although some Application Tags can be encoded 348 in a smaller number of bytes (eg, an IANA L3 protocol encoding 349 would take 2 bytes, while an IANA L4 port encoding would take 3 350 bytes), nothing prevents an Exporting Process from exporting all 351 Application Tags with a larger fixed length. 353 Note that the Selector ID value is always encoded in the least 354 significant bits as shown: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 |Class. Eng. ID | zero-valued upper-bits ... | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | ... Selector ID | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 2: Selector ID encoding 366 4.1. Existing Classification Engine IDs 367 The following Engine IDs have been allocated by Cisco Systems. 369 Name Value Description 370 0 Invalid. 371 IANA-L3 1 The IANA protocol (layer 3) number is 372 exported in the Selector ID. 373 See 374 http://www.iana.org/assignments/protoc 375 ol-numbers. 376 CANA-L3 2 Cisco Systems proprietary layer 3 377 definition. Cisco Systems can still 378 export its own layer 3 protocol 379 numbers, while waiting for IANA to 380 assign it. The Selector ID has a 381 global significance for all Cisco 382 Systems devices under CANA governance. 383 Hopefully the same IDs will be 384 maintained after the IANA 385 standardization. 386 IANA-L4 3 IANA layer 4 well-known port number is 387 exported in the Selector ID. 388 See 389 http://www.iana.org/assignments/port- 390 numbers. 391 Note: as a flow is unidirectional, it 392 contains the destination port in a 393 flow from the client to the server. 394 CANA-L4 4 Cisco Systems proprietary layer 4 395 definition. Cisco Systems can still 396 export its own layer 4 port numbers, 397 while waiting for IANA to assign it. 398 The Selector ID has global 399 significance for all Cisco Systems 400 devices under CANA governance. 401 Hopefully the same ID will be 402 maintained after the IANA 403 standardization. Example: IPFIX had 404 the port 4739 pre-assigned in the IETF 405 draft for years. While waiting for the 406 IANA registration, we could use this 407 Selector ID. 408 5 Reserved. 409 USER- 6 The Selector ID represents 410 Defined applications defined by the user 411 (using CLI or GUI) based on the 412 methods described in section 2. 413 7 Reserved. 415 8 Reserved. 416 9 Reserved. 417 10 Reserved. 418 11 Reserved. 419 CANA-L2 12 The Selector ID represents the Cisco 420 Systems unique global layer 2 421 applications. The Selector ID has a 422 global significance. 423 CANA-L7 13 The Selector ID represents the Cisco 424 Systems unique global ID for the layer 425 7 applications. The Selector ID has 426 global significance for all Cisco 427 Systems devices. 428 14 Reserved. 429 15 Reserved. 430 16 Reserved. 431 17 to 432 254 Available. 433 MAX 255 255 is the maximum Engine ID. 435 Table 1: Existing Classification Engine IDs 437 Note 1: "CANA = Cisco Systems Assigned Number Authority", Cisco 438 Systems's version of IANA for internal IDs. 440 Note 2: This is an extensible list, and new Classification 441 Engine IDs may be allocated at any time. See [CISCO] for the 442 latest version. 444 4.2. Options Template Record for the Application Name 446 For engines which specify locally unique Application Tags (which 447 means unique per engine and per router), an Options Template 448 Record (see [RFC5101]) MUST be used to export the correspondence 449 between the Application Tag, the Application Name, and the 450 Application Description. This is called the "options 451 application-table". For engines which specify globally unique 452 Application Tags, an Options Template Record SHOULD be used to 453 export the correspondence between the Application Tag, the 454 Application Name and the Application Description, unless the 455 mapping is hardcoded in the NetFlow Collector, or known out of 456 band (for example, by polling a MIB). 458 4.3. Resolving IANA L4 port collisions 460 Even if the IANA L4 ports usually point to the same protocols 461 for both UDP, TCP or other transport types, there are some 462 exceptions. The following table lists 10 ports that have 463 different protocols assigned for TCP and UDP: 465 exec 512/tcp remote process execution; 466 # authentication performed using 467 # passwords and UNIX login names 468 comsat/biff 512/udp used by mail system to notify users 469 # of new mail received; currently 470 # receives messages only from 471 # processes on the same machine 472 login 513/tcp remote login a la telnet; 473 # automatic authentication performed 474 # based on priviledged port numbers 475 # and distributed data bases which 476 # identify "authentication domains" 477 who 513/udp maintains data bases showing who's 478 # logged in to machines on a local 479 # net and the load average of the 480 # machine 481 shell 514/tcp cmd 482 # like exec, but automatic 483 authentication 484 # is performed as for login server 485 syslog 514/udp 486 oob-ws-https 664/tcp DMTF out-of-band secure web services 487 # management protocol 488 # Jim Davis 489 490 # June 2007 491 asf-secure-rmcp 664/udp ASF Secure Remote Management 492 # and Control Protocol 493 rfile 750/tcp 494 kerberos-iv 750/udp kerberos version iv 495 submit 773/tcp 496 notify 773/udp 497 rpasswd 774/tcp 498 acmaint_dbd 774/udp 499 entomb 775/tcp 500 acmaint_transd 775/udp 501 busboy 998/tcp 502 puparp 998/udp 503 garcon 999/tcp 504 applix 999/udp Applix ac 506 Table 2: IANA layer 4 port collisions between UDP and TCP 508 The following table lists 19 ports that have different 509 protocols assigned for TCP and SCTP: 511 # 3097/tcp Reserved 512 itu-bicc-stc 3097/sctp ITU-T Q.1902.1/Q.2150.3 513 Greg Sidebottom 514 # 5090/tcp 515 car 5090/sctp Candidate AR 516 # 5091/tcp 517 cxtp 5091/sctp Context Transfer Protocol 518 RFC 4065 - July 2005 519 # 6704/tcp Reserved 520 frc-hp 6704/sctp ForCES HP (High Priority) channel 521 # [RFC5811] 522 # 6705/tcp Reserved 523 frc-mp 6705/sctp ForCES MP (Medium Priority) channel 524 # [RFC5811] 525 # 6706/tcp Reserved 526 frc-lp 6706/sctp ForCES LP (Low priority) channel 527 # [RFC5811] 528 # 9082/tcp 529 lcs-ap 9082/sctp LCS Application Protocol 530 # Kimmo Kymalainen 531 532 04 June 2010 533 # 9902/tcp 534 enrp-sctp-tls 9902/sctp enrp/tls server channel 535 # [RFC5353] 536 # 11997/tcp 537 # 11998/tcp 538 # 11999/tcp 539 wmereceiving 11997/sctp WorldMailExpress 540 wmedistribution 11998/sctp WorldMailExpress 541 wmereporting 11999/sctp WorldMailExpress 542 Greg Foutz 543 March 2006 544 # 25471/tcp 545 rna 25471/sctp RNSAP User Adaptation for Iurh 546 # Dario S. Tonesi 547 548 07 February 2011 549 # 29118/tcp Reserved 550 sgsap 29118/sctp SGsAP in 3GPP 551 # 29168/tcp Reserved 552 sbcap 29168/sctp SBcAP in 3GPP 553 # 29169/tcp 554 iuhsctpassoc 29169/sctp HNBAP and RUA Common Association 555 John 556 Meredith 557 08 September 2009 558 # 36412/tcp 559 s1-control 36412/sctp S1-Control Plane (3GPP) 560 # KimmoKymalainen 561 562 01 September 2009 563 # 36422/tcp 564 x2-control 36422/sctp X2-Control Plane (3GPP) 565 # Kimmo Kymalainen 566 567 01 September 2009 568 # 36443/tcp 569 m2ap 36443/sctp M2 Application Part 570 # Dario S. Tonesi 571 572 07 February 2011 573 # 36444/tcp 574 m3ap 36444/sctp M3 Application Part 575 # Dario S. Tonesi 576 577 07 February 2011 579 Table 3: IANA layer 4 port collisions between SCTP and TCP 581 Instead of imposing the transport protocol (UDP/TCP/SCTP/etc.) 582 in the scope of the "options application-table" Options Template 583 for all applications (on top of having the transport protocol as 584 key-field in the Flow Record definition), we define that the L4 585 application is always TCP related, by convention. So, whenever 586 the Collector has a conflict in looking up IANA, it would choose 587 the TCP choice. As a result, the UDP L4 applications from Table 588 2 and the SCTP L4 applications from table 3 are assigned in the 589 Cisco L7 Application Tag range (ie, under Classification Engine 590 ID 13): 592 Currently, there are no discrepancies between the well known 593 ports for TCP and DCCP. 595 5. Grouping the Applications with the Attributes 597 Due to the high number of different application tags, 598 categorizing them into groups offers the benefits of easier 599 reporting and action, such as QoS policies. Indeed, most 600 applications with the same characteristics should be treated the 601 same way; for example, all video traffic. 603 Attributes are statically assigned per application tag and are 604 independent of the traffic. The attributes are listed below: 606 Name Description 608 Category An attribute that provides a first 609 level categorization for each 610 application tag. Examples include: 611 browsing, email, file-sharing, 612 gaming, instant messaging, voice- 613 and-video, etc... 614 The category attribute is encoded by 615 the ApplicationCategoryName 616 Information Element. 618 Sub-Category An attribute that provides a second 619 level categorization for each 620 application tag. Examples include: 621 backup-systems, client-server, 622 database, routing-protocol, etc... 623 The sub-category attribute is 624 encoded by the 625 ApplicationSubCategoryName 626 Information Element. 628 Application- An attribute that groups multiple 629 Group application tags that belong to the 630 same networking application. For 631 example, the ftp-group contain the 632 ftp-data (port 20), ftp (port 20), 633 ni-ftp (port 47), sftp (port 115), 634 bftp (port 152), ftp-agent(port 635 574), ftps-data (port 989). The 636 application-group attribute is 637 encoded by the ApplicationGroupName 638 Information Element. 640 P2P-Technology Specifies if the application tag is 641 based on peer-to-peer technology. 642 The P2P-technology attribute is 643 encoded by the p2pTechnology 644 Information Element. 646 Tunnel- Specifies if the application tag is 647 Technology used as a tunnel technology. The 648 tunnel-technology attribute is 649 encoded by the tunnelTechnolgoy 650 Information Element. 652 Encrypted Specifies if the application tag is 653 an encrypted networking protocol. 654 The encrypted attribute is encoded 655 by the encryptedTechnology 656 Information Element. 658 Table 4: Existing Application Tag Static Attributes 660 Every application is assigned to one ApplicationCategoryName, 661 one ApplicationSubCategoryName, one ApplicationGroupName, has 662 one p2pTechnology, one tunnelTechnolgoy, and one 663 encryptedTechnology. 664 5.1. Options Template Record for the Attribute Values 666 An Options Template Record (see [RFC5101]) is used to export the 667 correspondence between each Application Tag and its related 668 Attribute values. An alternative way for the Collecting Process 669 to learn the correspondence is to populate these mappings out of 670 band, for example, by loading a CSV file containing the 671 correspondence table. 673 The Attributes Option Template contains the ApplicationTag as a 674 scope field, followed by the ApplicationCategoryName, the 675 ApplicationSubCategoryName, the ApplicationGroupName, the 676 p2pTechnology, the tunnelTechnolgoy, and the 677 encryptedTechnology Information Elements. 679 A list of attributes may conveniently be exported using a 680 subTemplateList per [IPFIX-STRUCT]. 682 An example is given in section 6.8 below. 684 6. Application Tag Examples 686 The following examples are created solely for the purpose of 687 illustrating how the extensions proposed in this document are 688 encoded. 690 6.1. Example 1: Layer 2 Protocol 692 From the list of Classification Engine IDs in Table 1, we can 693 see that the layer 2 Classification Engine ID is 12: 695 L2 12 The Selector ID represents the layer 2 696 applications. The Selector ID has a global 697 significance. 699 From the list of layer 2 protocols at [cisco], we can see that 700 PPP has the value 24: 702 NAME Selector ID 703 ppp 24 705 So, in the case of layer 2 protocol PPP, the Classification 706 Engine ID is 12 while the Selector ID has the value 24. 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 | 12 | 24 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 So the Application Tag has the value of 3097. Instead of 717 representing the Application Tag in hexadecimal format, the 718 format '12...24' is used for simplicity in the examples below. 720 Flexible NetFlow creates a Template Record with a few 721 Information Elements: amongst other things, the Application Tag. 722 For example: 724 - sourceIPv4Address (key field) 725 - destinationIPv4Address (key field) 726 - ipDiffServCodePoint (key field) 727 - applicationTag (key field) 728 - octetTotalCount (non key field) 730 For example, a Flow Record corresponding to the above Template 731 Record may contain: 733 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 734 ipDiffServCodePoint=0, applicationTag='12...24', 735 octetTotalCount=123456 } 737 The Collector has all the required information to determine that 738 the application is PPP, because the Application Tag uses a 739 global and well know registry, ie the IANA protocol number. 740 The 24 value is globally unique within Cisco Systems for 741 Classification Engine ID 12, so the Collector can determine 742 which application is represented by the Application Tag by 743 loading the registry out of band. 745 6.2. Example 2: Standardized IANA Layer 3 Protocol 747 From the list of Classification Engine IDs in Table 1, we can 748 see that the IANA layer 3 Classification Engine ID is 1: 750 IANA- 1 The IANA protocol (layer 3) number is 751 L3 exported in the Selector ID. 752 See 753 http://www.iana.org/assignments/protocol- 754 numbers.. 756 From the list of IANA layer 3 protocols (see [IANA-PROTO]), we 757 can see that ICMP has the value 1: 759 Decimal Keyword Protocol Reference 760 1 ICMP Internet Control Message [RFC792] 762 So in the case of the standardized IANA layer 3 protocol ICMP, 763 the Classification Engine ID is 1, and the Selector ID has the 764 value of 1. 766 Therefore the Application Tag is encoded as: 768 0 1 769 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | 1 | 1 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 So the Application Tag has the value of 257. Instead of 775 representing the Application Tag in hexadecimal format, the 776 format '1...1' is used for simplicity in the examples below. 778 Flexible NetFlow creates a Template Record with a few 779 Information Elements: amongst other things, the Application Tag. 780 For example: 782 - sourceIPv4Address (key field) 783 - destinationIPv4Address (key field) 784 - ipDiffServCodePoint (key field) 785 - applicationTag (key field) 786 - octetTotalCount (non key field) 788 For example, a Flow Record corresponding to the above Template 789 Record may contain: 791 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 792 ipDiffServCodePoint=0, applicationTag='1...1', 793 octetTotalCount=123456 } 795 The Collector has all the required information to determine that 796 the application is ICMP, because the Application Tag uses a 797 global and well know registry, ie the IANA L3 protocol number. 799 6.3. Example 3: Cisco Systems Proprietary Layer 3 Protocol 801 Assume that Cisco Systems has specified a new layer 3 protocol 802 called "foo". 804 From the list of Classification Engine IDs in Table 1, we can 805 see that the Cisco Systems layer 3 Classification Engine ID is 806 2: 808 CANA- 2 Cisco Systems proprietary layer 3 809 L3 definition. Cisco Systems can still export 810 its own layer 3 protocol numbers, while 811 waiting for IANA to assign it. The 812 Selector ID has a global significance for 813 all Cisco Systems devices under CANA 814 governance. Hopefully the same IDs will be 815 maintained after the IANA standardization. 817 A global registry within Cisco Systems specifies that the "foo" 818 protocol has the value 90: 820 Protocol Protocol Id 821 foo 90 823 So in the case of Cisco Systems layer 3 protocol foo, the 824 Classification Engine ID is 2, and the Selector ID has the value 825 of 90. 827 Therefore the Application Tag is encoded as: 829 0 1 830 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | 2 | 90 | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 So the Application Tag has the value of 602. Instead of 836 representing the Application Tag in hexadecimal format, the 837 format '2..90' is used for simplicity in the examples below. 839 Flexible NetFlow creates a Template Record with a few 840 Information Elements: amongst other things, the Application Tag. 841 For example: 843 - sourceIPv4Address (key field) 844 - destinationIPv4Address (key field) 845 - ipDiffServCodePoint (key field) 846 - applicationTag (key field) 847 - octetTotalCount (non key field) 849 For example, a Flow Record corresponding to the above Template 850 Record may contain: 852 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 853 ipDiffServCodePoint=0, applicationTag='2...90', 854 octetTotalCount=123456 } 856 Along with this Flow Record, a new Options Template Record would 857 be exported, as shown in Section 6.7. 859 6.4. Example 4: Standardized IANA Layer 4 Port 861 From the list of Classification Engine IDs in Table 1, we can 862 see that the IANA layer 4 Classification Engine ID is 3: 864 IANA- 3 IANA layer 4 well-known port number is 865 L4 exported in the selector ID. 866 See http://www.iana.org/assignments/port- 867 numbers. 869 Note: as a flow is unidirectional, it 870 contains the destination port in a flow 871 from the client to the server. 873 From the list of IANA layer 4 ports (see [IANA-PORTS]), we can 874 see that SNMP has the value 161: 876 Keyword Decimal Description 877 snmp 161/tcp SNMP 878 snmp 161/udp SNMP 880 So in the case of the standardized IANA layer 4 SNMP port, the 881 Classification Engine ID is 3, and the Selector ID has the value 882 of 161. 884 Therefore the Application Tag is encoded as: 886 0 1 887 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | 3 | 161 | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Flexible NetFlow creates a Template Record with a few 893 Information Elements: amongst other things, the Application Tag. 894 For example: 896 - sourceIPv4Address (key field) 897 - destinationIPv4Address (key field) 898 - protocol (key field) 899 - ipDiffServCodePoint (key field) 900 - applicationTag (key field) 901 - octetTotalCount (non key field) 903 For example, a Flow Record corresponding to the above Template 904 Record may contain: 906 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 907 protocol=17, ipDiffServCodePoint=0, 908 applicationTag='3..161', octetTotalCount=123456 } 910 The Collector has all the required information to determine that 911 the application is SNMP, because the Application Tag uses a 912 global and well know registry, ie the IANA L4 protocol number. 914 6.5. Example 4: Layer 7 Application 916 In this example, the Metering Process has observes some Citrix 917 traffic. 919 From the list of Classification Engine IDs in Table 1, we can 920 see that the L7 unique Engine ID is 13: 922 L7 13 The Selector ID represents the Cisco Systems 923 unique global ID for the layer 7 924 application. The Selector ID has a global 925 significance for all Cisco Systems devices. 927 Suppose that the Metering Process returns the ID 10000 for 928 Citrix traffic. 930 So, in the case of this Citrix application, the Classification 931 Engine ID is 13 and the Selector ID has the value of 10000. 933 Therefore the Application Tag is encoded as: 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | 13 | | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | 10000 | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 So the Application Tag has the value of '13..10000'. 944 Note that the figure shows that the Exporting Process exports 945 the value 10000 in 7 bytes: this is pure speculation. However, 946 it doesn't matter as the applicationTag would be exported in a 947 variable length Information Element. 949 Flexible NetFlow creates a Template Record with a few 950 Information Elements: amongst other things, the Application Tag. 951 For example: 953 - sourceIPv4Address (key field) 954 - destinationIPv4Address (key field) 955 - ipDiffServCodePoint (key field) 956 - applicationTag (key field) 957 - octetTotalCount (non key field) 959 For example, a Flow Record corresponding to the above Template 960 Record may contain: 962 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 963 ipDiffServCodePoint=0, applicationTag='13...10000', 964 octetTotalCount=123456 } 966 The 10000 value is globally unique within Cisco Systems, so the 967 Collector can determine which application is represented by the 968 Application Tag by loading the registry out of band. 970 Along with this Flow Record, a new Options Template Record would 971 be exported, as shown in Section 6.7. 973 6.6. Example: port Obfuscation 975 For example, a HTTP server might run a TCP port 23 (assigned to 976 telnet in [IANA-PORTS]). If the Metering Process is capable of 977 detecting HTTP in the same case, the Application Tag 978 representation must contain HTTP. However, if the reporting 979 application wants to determine whether or the default HTTP port 980 80 or 8080 was used, it must export the destination port 981 (destinationTransportPort at [IANA-IPFIX]) in the corresponding 982 NetFlow record. 984 In the case of a standardized IANA layer 4 port, the 985 Classification Engine ID is 2, and the Selector ID has the value 986 of 80 for HTTP (see [IANA-PORTS]). 988 Therefore the Application Tag is encoded as: 990 0 1 2 991 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | 3 | 80 | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Flexible NetFlow creates a Template Record with a few 997 Information Elements: amongst other things, the Application Tag. 998 For example: 1000 - sourceIPv4Address (key field) 1001 - destinationIPv4Address (key field) 1002 - protocol (key field) 1003 - destinationTransportPort (key field) 1004 - applicationTag (key field) 1005 - octetTotalCount (non key field) 1007 For example, a Flow Record corresponding to the above Template 1008 Record may contain: 1010 { sourceIPv4Address=1.1.1.1, destinationIPv4Address=2.2.2.2, 1011 protocol=17, destinationTransportPort=23, 1012 applicationTag='3..80', octetTotalCount=123456 } 1014 The Collector has all the required information to determine that 1015 the application is HTTP, but runs on port 23. 1017 6.7. Example: Application Mapping Options Template 1019 Along with the Flow Records shown in the above examples, a new 1020 Options Template Record would be exported to express the 1021 Application Name and Application Description associated with 1022 each Application Tag. 1024 The Options Template Record contains the following Information 1025 Elements: 1027 1. Scope = applicationTag. 1029 From RFC 5101: "The scope, which is only available in the 1030 Options Template Set, gives the context of the reported 1031 Information Elements in the Data Records." 1033 2. applicationName. 1035 3. applicationDescription. 1037 The Options Data Record associated with the examples above would 1038 contain, for example: 1040 { scope=applicationTag='2...90', 1041 applicationName="foo", 1042 applicationDescription="The Cisco foo protocol", 1044 scope=applicationTag='13...10000', 1045 applicationName="Citrix", 1046 applicationDescription="A Citrix application" } 1048 When combined with the example Flow Records above, these Options 1049 Template Records tell the NetFlow collector: 1051 1. A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 1052 to destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 1053 applicationTag of '12...90', which maps to the "foo" 1054 application. 1056 2. A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 1057 to destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 1058 Application Tag of '13...10000', which maps to the "Citrix" 1059 application. 1061 6.8. Example: Attributes Values Options Template Record 1063 Along with the Flow Records shown in the above examples, a new 1064 Options Template Record is exported to express the values of the 1065 different attributes related to the Application Tags. 1067 The Options Template Record would contain the following 1068 Information Elements: 1070 1. Scope = applicationTag. 1072 From RFC 5101: "The scope, which is only available in the 1073 Options Template Set, gives the context of the reported 1074 Information Elements in the Data Records." 1076 2. applicationCategoryName. 1078 3. applicationSubCategoryName. 1080 4. applicationGroupName 1082 5. p2pTechnology 1084 6. tunnelTechnology 1086 7. encryptedTechnology 1088 The Options Data Record associated with the examples above would 1089 contain, for example: 1091 { scope=applicationTag='2...90', 1092 applicationCategoryName="foo-category", 1093 applicationSubCategoryName="foo-subcategory", 1094 applicationGroupName="foo-group", 1095 p2pTechnology=NO 1096 tunnelTechnology=YES 1097 encryptedTechnology=NO 1099 When combined with the example Flow Records above, these Options 1100 Template Records tell the NetFlow collector: 1102 A flow of 123456 bytes exists from sourceIPv4Address 1.1.1.1 to 1103 destinationIPv4address 2.2.2.2 with a DSCP value of 0 and an 1104 applicationTag of '12...90', which maps to the "foo" 1105 application. This application can be characterized by the 1106 relevant attributes values. 1108 7. IANA Considerations 1110 This document specifies three new IPFIX Information Elements: the 1111 applicationDescription, applicationTag and the applicationName. 1113 New Information Elements to be added to the IPFIX Information 1114 Element registry at [IANA-IPFIX] are listed below. 1116 EDITOR'S NOTE: the XML specification in Appendix A must be updated 1117 with the elementID values allocated below. 1119 7.1. applicationDescription 1121 Name: applicationDescription 1122 Description: 1123 Specifies the description of an application. 1124 Abstract Data Type: string 1125 Data Type Semantics: 1126 ElementId: 94 1127 Status: current 1129 7.2. applicationTag 1131 Name: applicationTag 1132 Description: 1133 Specifies an Application Tag. 1134 (EDITOR'S NOTE: reference this document). 1135 Abstract Data Type: octetArray 1136 Data Type Semantics: identifer 1137 ElementId: 95 1138 Status: current 1140 7.3. applicationName 1142 Name: applicationName 1143 Description: 1144 Specifies the name of an application. 1145 Abstract Data Type: string 1146 Data Type Semantics: 1147 ElementId: 96 1148 Status: current 1150 7.4. applicationCategoryName 1152 Name: applicationCategoryName 1153 Description: 1154 An attribute that provides a first level categorization for each 1155 Application Tag. 1156 Abstract Data Type: string 1157 Data Type Semantics: 1158 ElementId: 1159 Status: current 1161 7.5. applicationSubCategoryName 1163 Name: applicationSubCategoryName 1164 Description: 1165 An attribute that provides a second level categorization for 1166 each Application Tag 1167 Abstract Data Type: string 1168 Data Type Semantics: 1169 ElementId: 1170 Status: current 1172 7.6. applicationGroupName 1174 Name: applicationGroupName 1175 Description: 1176 An attribute that groups multiple Application Tags that belong 1177 to the same networking application 1178 Abstract Data Type: string 1179 Data Type Semantics: 1180 ElementId: 1181 Status: current 1183 7.7. p2pTechnology 1185 Name: p2pTechnology 1186 Description: 1187 Specifies if the Application Tag is based on peer-to-peer 1188 technology. Possible values are: "yes", "no", and "unassigned" 1189 Abstract Data Type: string 1190 Data Type Semantics: 1191 ElementId: 1192 Status: current 1194 7.8. tunnelTechnology 1196 Name: tunnelTechnology 1197 Description: 1198 Specifies if the application tag is used as a tunnel technology. 1199 Possible values are: "yes", "no", and "unassigned" 1200 Abstract Data Type: string 1201 Data Type Semantics: 1202 ElementId: 1203 Status: current 1205 7.9. encryptedTechnology 1207 Name: encryptedTechnology 1208 Description: 1209 Specifies if the application tag is an encrypted networking 1210 protocol. Possible values are: "yes", "no", and "unassigned" 1211 Abstract Data Type: string 1212 Data Type Semantics: 1213 ElementId: 1214 Status: current 1216 8. Security Considerations 1218 The same security considerations as for the IPFIX Protocol 1219 [RFC5101] apply. 1221 9. References 1223 9.1. Normative References 1225 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1226 Requirement Levels, BCP 14, RFC 2119, March 1997. 1228 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 1229 Information Export (IPFIX) Protocol for the Exchange of 1230 IP Traffic Flow Information", RFC 5101, January 2008. 1232 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 1233 J. Meyer, "Information Model for IP Flow Information 1234 Export", RFC 5102, January 2008. 1236 9.2. Informative References 1238 [RFC792] J. Postel, Internet Control Message Protocol, RFC 792, 1239 September 1981. 1241 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1242 Requirements for IP Flow Information Export, RFC 3917, 1243 October 2004. 1245 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 1246 Export Using IP Flow Information Export (IPFIX)", RFC 1247 5103, January 2008. 1249 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 1250 Quittek, "Architecture for IP Flow Information Export", 1251 RFC 5470, March 2009. 1253 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 1254 for IP Flow Information Export (IPFIX) Testing", RFC 1255 5471, March 2009. 1257 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 1258 Redundancy in IP Flow Information Export (IPFIX) and 1259 Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. 1261 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol 1262 Specifications", RFC 5476, March 2009. 1264 [IPFIX-STRUCT] Claise, B., Dhandapani, G. Aitken, P., and S. 1265 Yates, "Export of Structured Data in IPFIX", draft- 1266 ietf-ipfix-structured-data-05.txt, work in progress, 1267 March 20111 1269 [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml 1271 [IANA-PORTS] http://www.iana.org/assignments/port-numbers 1273 [IANA-PROTO] http://www.iana.org/assignments/protocol-numbers 1275 [CISCO] http://www.cisco.com 1277 10. Acknowledgement 1279 The authors would like to thank their many colleagues across Cisco 1280 Systems who made this work possible. 1282 11. Authors' Addresses 1284 Benoit Claise 1285 Cisco Systems, Inc. 1286 De Kleetlaan 6a b1 1287 Diegem 1813 1288 Belgium 1290 Phone: +32 2 704 5622 1291 EMail: bclaise@cisco.com 1293 Paul Aitken 1294 Cisco Systems, Inc. 1295 96 Commercial Quay 1296 Commercial Street 1297 Edinburgh, EH6 6LX, United Kingdom 1299 Phone: +44 131 561 3616 1300 EMail: paitken@cisco.com 1302 Nir Ben-Dvora 1303 Cisco Systems, Inc. 1304 32 HaMelacha St., 1305 P.O.Box 8735, I.Z.Sapir 1306 South Netanya, 42504 1307 Israel 1309 Phone: +972 9 892 7187 1310 EMail: nirbd@cisco.com 1311 Appendix A. Additions to XML Specification of IPFIX Information 1312 Elements 1314 This appendix contains additions to the machine-readable 1315 description of the IPFIX information model coded in XML in 1316 Appendix A and Appendix B in [RFC5102]. Note that this appendix 1317 is of informational nature, while the text in Section 7. 1318 (generated from this appendix) is normative. 1320 The following field definitions are appended to the IPFIX 1321 information model in Appendix A of [RFC5102]. 1323 1327 1328 1329 Specifies the description of an application. 1330 1331 1332 1334 1339 1340 1341 Specifies an Application Tag. 1342 1343 1344 1346 1350 1351 1352 Specifies the name of an application. 1353 1354 1355 1356 1361 1362 1363 An attribute that provides a first level categorization 1364 for each Application Tag. 1365 1366 1367 1369 1374 1375 1376 An attribute that provides a second level 1377 categorization for each Application Tag. 1378 1379 1380 1382 1387 1388 1389 An attribute that groups multiple Application Tags 1390 that belong to the same networking application. 1391 1392 1393 1395 1400 1401 1402 Specifies if the Application Tag is based on peer- 1403 to-peer technology. Possible values are: "yes", 1404 "no", and "unassigned". 1405 1406 1407 1409 1414 1415 1416 Specifies if the application tag is used as a 1417 tunnel technology. Possible values are: "yes", 1418 "no", and "unassigned". 1419 1420 1421 1423 1428 1429 1430 Specifies if the application tag is an encrypted 1431 networking protocol. Possible values are: "yes", 1432 "no", and "unassigned". 1433 1434 1435