idnits 2.17.1 draft-claise-export-application-info-in-ipfix-10.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines 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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1900 has weird spacing: '...512/tcp rem...' == Line 1905 has weird spacing: '...512/udp use...' == Line 1912 has weird spacing: '...513/tcp rem...' == Line 1921 has weird spacing: '...513/udp mai...' == Line 1927 has weird spacing: '...514/tcp cmd...' == (2 more instances...) -- The document date (August 8, 2012) is 4278 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 1998, but not defined == Missing Reference: 'RFC5353' is mentioned on line 2010, but not defined ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 3 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: February 8, 2013 Cisco Systems, Inc. 6 August 8, 2012 8 Cisco Systems Export of Application Information in IPFIX 9 draft-claise-export-application-info-in-ipfix-10 11 Status of this Memo 13 This document is not an Internet Standards Track 14 specification; it is published for informational purposes. 16 This document is a product of the Internet Engineering Task 17 Force (IETF). It represents the consensus of the IETF 18 community. It has received public review and has been 19 approved for publication by the Internet Engineering 20 Steering Group (IESG). Not all documents approved by the 21 IESG are a candidate for any level of Internet Standard; 22 see Section 2 of RFC 5741. 24 Information about the current status of this document, any 25 errata, and how to provide feedback on it may be obtained 26 at http://www.rfc-editor.org/info/rfc. 28 EDITOR NOTES: The above text is the consensus from the IESG 29 meeting regarding this document. Note that the 30 must be updated. The text below has been kept for 31 completeness. 33 This Internet-Draft is submitted to IETF in full 34 conformance with the provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet 37 Engineering Task Force (IETF), its areas, and its working 38 groups. Note that other groups may also distribute working 39 documents as Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of 42 six months and may be updated, replaced, or obsoleted by 43 other documents at any time. It is inappropriate to use 44 Internet-Drafts as reference material or to cite them other 45 than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be 51 accessed at http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on January 8, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as 57 the document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's 60 Legal Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the 62 date of publication of this document. Please review these 63 documents carefully, as they describe your rights and 64 restrictions with respect to this document. Code 65 Components extracted from this document must include 66 Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 Abstract 72 This document specifies an Cisco Systems extension to the 73 IPFIX information model specified in [RFC5102] to export 74 application information. 76 Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 79 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 80 and "OPTIONAL" in this document are to be interpreted as 81 described in RFC 2119 [RFC2119]. 83 Table of Contents 85 1. Introduction.......................................... 5 86 1.1. Application Information Use Cases................... 7 87 2. IPFIX Documents Overview.............................. 8 88 3. Terminology........................................... 8 89 3.1. New Terminology.................................. 9 90 4. applicationId Information Element Specification....... 9 91 4.1. Existing Classification Engine IDs.............. 10 92 4.2. Selector ID Length per Classification IDs....... 14 93 4.3. Application Name Options Template Record........ 15 94 4.4. Resolving IANA L4 Port Discrepancies............ 16 95 5. Grouping the Applications with the Attributes........ 16 96 5.1. Options Template Record for the Attribute Values 18 97 6. Application Id Examples.............................. 18 98 6.1. Example 1: Layer 2 Protocol..................... 18 99 6.2. Example 2: Standardized IANA Layer 3 Protocol... 20 100 6.3. Example 3: Proprietary Layer 3 Protocol......... 21 101 6.4. Example 4: Standardized IANA Layer 4 Port....... 22 102 6.5. Example 5: Layer 7 Application.................. 23 103 6.6. Example 6: Layer 7 Application with Private 104 Enterprise Number (PEN).............................. 24 105 6.7. Example: port Obfuscation....................... 26 106 6.8. Example: Application Name Mapping Options Template27 107 6.9. Example: Attributes Values Options Template Record28 108 7. IANA Considerations.................................. 29 109 7.1. New Information Elements........................ 29 110 7.1.1. applicationDescription........................ 30 111 7.1.2. applicationId................................. 30 112 7.1.3. applicationName............................... 30 113 7.1.5. applicationCategoryName....................... 33 114 7.1.6. applicationSubCategoryName.................... 33 115 7.1.7. applicationGroupName.......................... 33 116 7.1.8. p2pTechnology................................. 34 117 7.1.9. tunnelTechnology.............................. 34 118 7.1.10. encryptedTechnology.......................... 34 119 7.2. Classification Engine Ids Registry.............. 35 120 8. Security Considerations.............................. 35 121 9. References........................................... 36 122 9.1. Normative References............................ 36 123 9.2. Informative References.......................... 36 124 10. Acknowledgement..................................... 38 125 11. Authors' Addresses.................................. 39 126 Appendix A. Additions to XML Specification of IPFIX 127 Information Elements (non normative).................... 39 128 Appendix B. Port Collisions Tables (non normative)..... 45 129 Appendix C. Application Registry Example (non normative)49 131 List of Figures and Tables 133 Figure 1: applicationId Information Element ............. 9 134 Table 1: Existing Classification Engine IDs ............ 13 135 Table 2: Selector ID default length per Classification 136 Engine ID ........................................... 14 137 Table 3: Application Id Static Attributes .............. 17 138 Table 4: Different Protocols on UDP and TCP ............ 47 139 Table 5: Different Protocols on SCTP and TCP ........... 49 141 1. Introduction 143 Today service providers and network administrators are 144 looking for visibility into the packet content rather than 145 just the packet header. Some network devices Metering 146 Processes inspect the packet content and identify the 147 applications that are utilizing the network traffic. 148 Applications in this context are defined as networking 149 protocols used by networking processes that exchange 150 packets between them (such as web applications, peer to 151 peer applications, file transfer, e-mail applications, 152 etc.). Applications can be further characterized by other 153 criteria, some of which are application specific. 154 Examples include: web application to a specific domain, per 155 user specific traffic, a video application with a specific 156 codec, etc... 158 The application identification is based on several 159 different methods or even a combination of methods: 160 1. L2 (Layer 2) protocols (such as ARP (Address Resolution 161 Protocol), PPP (Point-to-Point Protocol), LLDP (Link 162 Layer Discovery Protocol)) 163 2. IP protocols (such as ICMP (Internet Control Message 164 Protocol), IGMP (Internet Group Management Protocol), 165 GRE (Generic Routing Encapsulation) 166 3. TCP or UDP ports (such as HTTP, Telnet, FTP) 167 4. Application layer header (of the application to be 168 identified) 169 5. Packet data content 170 6. Packets and traffic behavior 172 The exact application identification methods are part of 173 the Metering Process internals that aim to provide an 174 accurate identification and minimize false identification. 175 This task requires a sophisticated Metering Process since 176 the protocols do not behave in a standard manner. 178 1. Applications use port obfuscation where the 179 application runs on different port than the IANA 180 assigned one. For example an HTTP server might 181 run a TCP port 23 (assigned to telnet in [IANA- 182 PORTS]) 184 2. IANA port registries do not accurately reflect how 185 certain ports are "commonly" used today. Some 186 ports are reserved, but the application either 187 never became prevalent or is not in use today. 189 3. The application behavior and identification logic 190 become more and more complex 192 For that reason, such Metering Processes usually 193 detect applications based on multiple mechanisms in 194 parallel. Detection based only on port matching 195 might wrongly identify the application. If the 196 Metering Process is capable of detecting applications 197 more accurately, it is considered to be stronger and 198 more accurate. 200 Similarly, a reporting mechanism that uses L4 port based 201 applications only, such as L4:, would have 202 similar issues. The reporting system should be capable of 203 reporting the applications classified using all types of 204 mechanisms. In particular applications that do not have 205 any IANA port definition. While a mechanism to export 206 application information should be defined, the L4 port 207 being used must be exported using the destination port 208 (destinationTransportPort at [IANA-IPFIX]) in the 209 corresponding IPFIX record. 211 This document specifies the Cisco Systems application 212 information encoding (as described in section 4. ) to 213 export the application information with the IPFIX protocol 214 [RFC5101]. 216 Applications could be identified at different OSI layers, 217 from layer 2 to layer 7. For example: Link Layer 218 Distribution Protocol (LLDP) [LLDP] can be identified in 219 layer 2, ICMP can be identified in layer 3 [IANA-PROTO], 220 HTTP can be identified in layer 4 [IANA-PORTS], and Webex 221 can be identified in layer 7. 223 While an ideal solution would be an IANA registry for 224 applications above (or inside the payload of) the well- 225 known ports [IANA-PORTS], this solution is not always 226 possible. Indeed, the specifications for some applications 227 embedded in the payload are not available. Some reverse 228 engineering as well as a ubiquitous language for 229 application identification, would be required conditions to 230 be able to manage an IANA registry for these types of 231 applications. Clearly, these are blocking factors. 233 This document specifies the Cisco Systems application 234 information encoding. However, the layer 7 application 235 registry values are out of scope of this document. 237 1.1. Application Information Use Cases 239 There are several use cases for application information: 241 1. Application Visibility 243 This is one of the main cases for using the application 244 information. Network administrators are using 245 application visibility to understand the main network 246 consumers, network trends and user behavior. 248 2. Security Functions 250 Application knowledge is sometimes used in security 251 functions in order to provide comprehensive functions 252 such as Application based firewall, URL filtering, 253 parental control, intrusion detection, etc. 255 All of the above use cases require exporting application 256 information to provide the network function itself or to 257 log the network function operation. 259 2. IPFIX Documents Overview 261 The IPFIX Protocol [RFC5101] provides network administrators 262 with access to IP Flow information. 264 The architecture for the export of measured IP Flow 265 information out of an IPFIX Exporting Process to a Collecting 266 Process is defined in the IPFIX Architecture [RFC5470], per 267 the requirements defined in RFC 3917 [RFC3917]. 269 The IPFIX Architecture [RFC5470] specifies how IPFIX Data 270 Records and Templates are carried via a congestion-aware 271 transport protocol from IPFIX Exporting Processes to IPFIX 272 Collecting Processes. 274 IPFIX has a formal description of IPFIX Information Elements, 275 their name, type and additional semantic information, as 276 specified in the IPFIX information model [RFC5102]. 278 In order to gain a level of confidence in the IPFIX 279 implementation, probe the conformity and robustness, and 280 allow interoperability, the Guidelines for IPFIX Testing 281 [RFC5471] presents a list of tests for implementers of 282 compliant Exporting Processes and Collecting Processes. 284 The Bidirectional Flow Export [RFC5103] specifies a method 285 for exporting bidirectional flow (biflow) information using 286 the IP Flow Information Export (IPFIX) protocol, representing 287 each Biflow using a single Flow Record. 289 The "Reducing Redundancy in IP Flow Information Export 290 (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] 291 specifies a bandwidth saving method for exporting Flow or 292 packet information, by separating information common to 293 several Flow Records from information specific to an 294 individual Flow Record: common Flow information is exported 295 only once. 297 3. Terminology 299 IPFIX-specific terminology used in this document is defined 300 in Section 2 of the IPFIX protocol specification [RFC5101]. 301 As in [RFC5101], these IPFIX-specific terms have the first 302 letter of a word capitalized when used in this document. 304 3.1. New Terminology 306 Application Id 308 A unique identifier for an application. 310 When an application is detected, the most granular 311 application is encoded in the Application Id. 313 4. applicationId Information Element Specification 315 This document specifies the applicationId Information 316 Element, which is a single field composed of two parts: 318 1. 8 bits of Classification Engine ID. The 319 Classification Engine can be considered as a 320 specific registry for application assignments. 321 2. m bits of Selector ID. The Selector ID length 322 varies depending on the Classification Engine ID. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Class. Eng. ID| Selector ID ... | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | ... | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 1: applicationId Information Element 334 Classification Engine ID 336 A unique identifier for the engine which determined the 337 Selector ID. Thus the Classification Engine ID defines 338 the context for the Selector ID. 340 Selector ID 342 A unique identifier of the application for a specific 343 Classification Engine ID. Note that the Selector ID 344 length varies depending on the Classification Engine 345 ID. 347 The Selector ID term is similar in concepts with the 348 selectorId Information Element, specified in the PSAMP 349 Protocol [RFC5476][RFC5477]. 351 4.1. Existing Classification Engine IDs 353 The following Classification Engine IDs have been 354 allocated: 356 Name Value Description 358 0 Invalid. 360 IANA-L3 1 The Assigned Internet Protocol 361 Number (layer 3 (L3)) is exported 362 in the Selector ID. 363 See [IANA-PROTO]. 365 PANA-L3 2 Proprietary layer 3 definition. 366 An enterprise can export its own 367 layer 3 protocol numbers. The 368 Selector ID has a global 369 significance for all devices from 370 the same enterprise. 372 IANA-L4 3 The IANA layer 4 (L4) well-known 373 port number is exported in the 374 Selector ID. See [IANA-PORTS]. 375 Note: as an IPFIX flow is 376 unidirectional, it contains the 377 destination port in a flow from 378 the client to the server. 380 PANA-L4 4 Proprietary layer 4 definition. 381 An enterprise can export its own 382 layer 4 port numbers. The 383 Selector ID has global 384 significance for devices from the 385 same enterprise. Example: IPFIX 386 had the port 4739 pre-assigned in 387 the IETF draft for years. While 388 waiting for the RFC and its 389 associated IANA registration, the 390 Selector ID 4739 was used with 391 this PANA-L4. 393 5 Reserved. 395 USER- 6 The Selector ID represents 396 Defined applications defined by the user 397 (using CLI, GUI, etc.) based on 398 the methods described in section 399 1. The Selector ID has a local 400 significance per device. 402 7 Reserved. 404 8 Reserved. 406 9 Reserved. 408 10 Reserved. 410 11 Reserved. 412 PANA-L2 12 Proprietary layer 2 (L2) 413 definition. An enterprise can 414 export its own layer 2 415 identifiers. The Selector ID 416 represents the enterprise's 417 unique global layer 2 418 applications. The Selector ID has 419 a global significance for all 420 devices from the same enterprise. 421 Examples include Cisco Subnetwork 422 Access Protocol (SNAP). 424 PANA-L7 13 Proprietary layer 7 definition. 425 The Selector ID represents the 426 enterprise's unique global ID for 427 the layer 7 applications. The 428 Selector ID has a global 429 significance for all devices from 430 the same enterprise. This 431 Classification Engine Id is used 432 when the application registry is 433 owned by the Exporter 434 manufacturer (referred to as the 435 "enterprise" in this document). 437 14 Reserved. 439 15 Reserved. 441 16 Reserved. 443 17 Reserved. 445 ETHERTYPE 18 The Selector ID represents the 446 well-known Ethertype. See 447 [ETHERTYPE]. Note that the 448 Ethertype is usually expressed in 449 hexadecimal. However, the 450 corresponding decimal value is 451 used in this Selector ID. 453 LLC 19 The Selector ID represents the 454 well-known IEEE 802.2 Link Layer 455 Control (LLC) Destination Service 456 Access Point (DSAP). See [LLC]. 457 Note that LLC DSAP is usually 458 expressed in hexadecimal. 459 However, the corresponding 460 decimal value is used in this 461 Selector ID. 463 PANA-L7- 20 Proprietary layer 7 definition, 464 PEN including a Private Enterprise 465 Number (PEN) [PEN] to identify 466 that the application registry 467 being used is not owned by the 468 Exporter manufacturer (referred 469 to as the "enterprise" in this 470 document, and identified by the 471 PEN), or to identify the original 472 enterprise in the case of a 473 mediator or 3rd party device. The 474 Selector ID represents the 475 enterprise unique global ID for 476 the layer 7 applications. The 477 Selector ID has a global 478 significance for all devices from 479 the same enterprise. 481 21 to 482 255 Available (255 is the maximum 483 Engine ID) 485 Table 1: Existing Classification Engine IDs 487 "PANA = Proprietary Assigned Number Authority". In other 488 words, an enterprise specific version of IANA for 489 internal IDs. 491 The PANA-L7 Classification Engine ID SHOULD be used when 492 the application registry is owned by the Exporter 493 manufacturer, referred to as the "enterprise" in this 494 document, and identified by the PEN. Even if the 495 application registry is owned by the Exporter 496 manufacturer, the PANA-L7-PEN MAY be used, specifying the 497 manufacturer. 498 The mechanism for the Collector to know about Exporter 499 PEN is out of scope of this document. Possible tracks 500 are: SNMP polling, an Options Template export, hardcoded 501 value, etc. 503 An Exporter may classify the application according to 504 another vendor's application registry. E.g., an IPFIX 505 Mediator [RFC6183] may need to re-export applications 506 received from different Exporters using different PANA-L7 507 application registries. For example, X's IPFIX Mediator 508 aggregates traffic from some Exporters which report 509 enterprise Y applications and other Exporters which 510 report enterprise Z applications. Or, X's device 511 implements enterprise Y's application classifications. 512 In these cases, the PANA-L7-PEN Classification Engine 513 MUST be used, which allows the original enterprise ID to 514 be reported. The ID of the enterprise which defined the 515 application ID is identified by the enterprise's PEN. An 516 example is displayed in section 6.6. 518 Note that the the PANA-L7 Classification Engine ID is 519 also used for resolving IANA L4 port Discrepancies (see 520 Section 4.4) 522 The list in table 1 is maintained by IANA thanks to the 523 registry within the classificationEngineId Information 524 Element. See the "IANA Considerations" section. The 525 Classification Engine Id is part of the Application Id 526 encoding, so the classificationEngineId Information 527 Element is currently not required by the specifications 528 in this document. However, this Information Element was 529 created for completeness, as it was anticipated that this 530 Information Element will be required in the future. 532 4.2. Selector ID Length per Classification IDs 534 As the Selector Id part of the Application Id is variable 535 based on the Classification Engine ID value, the 536 applicationId SHOULD be encoded in a variable-length 537 Information Element [RFC5101] for the IPFIX export. 539 The following table displays the Selector ID default 540 length for the different Classification Engine IDs. 542 Classification Selector ID default 543 Engine ID Name length (in bytes) 545 IANA-L3 1 547 PANA-L3 1 549 IANA-L4 2 551 PANA-L4 2 553 USER-Defined 3 555 PANA-L2 5 557 PANA-L7 3 559 ETHERTYPE 2 561 LLC 1 563 PANA-L7-PEN 3 (*) 565 Table 2: Selector ID default length 566 per Classification Engine ID 568 (*) There is an extra 4 bytes for the PEN. However, the PEN 569 is not considered part of the Selector ID. 571 If a legacy protocol such as NetFlow version 9 [RFC3954] is 572 used, and this protocol doesn't support variable length 573 Information Elements, then either multiple Template Records 574 (one per applicationId length), or a single Template Record 575 corresponding to the maximum sized applicationId MUST be 576 used. 578 Application Ids MAY be encoded in a smaller number of 579 bytes, following the same rules as for the IPFIX Reduced 580 Size Encoding [RFC5101]. 582 Application Ids MAY be encoded with a larger length. 583 For example, a normal IANA L3 protocol encoding would take 584 2 bytes since the Selector ID represents the protocol field 585 from the IP header encoded in one byte. However, an IANA 586 L3 protocol encoding may be encoded with 3 bytes. In this 587 case, the Selector ID value MUST always be encoded in the 588 least significant bits as shown in Figure 2. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |Class. Eng. ID |zero-valued upper-bits ... Selector ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Figure 2: Selector ID encoding 598 4.3. Application Name Options Template Record 600 For Classification Engines which specify locally unique 601 Application Ids (which means unique per engine and per 602 router), an Options Template Record (see [RFC5101]) MUST 603 be used to export the correspondence between the 604 Application Id, the Application Name, and the Application 605 Description. 607 For Classification Engines which specify globally unique 608 Application Ids, an Options Template Record MAY be used 609 to export the correspondence between the Application Id, 610 the Application Name and the Application Description, 611 unless the mapping is hardcoded in the Collector, or 612 known out of band (for example, by polling a MIB). 614 An example Options Template is shown in section 6.8. 616 Enterprises may assign company-wide Application Id values 617 for the PANA-L7 Classification Engine. In this case, a 618 possible optimization for the Collector is to keep the 619 mappings between the Application Ids and the Application 620 Names per enterprise, as opposed to per Exporter. 622 4.4. Resolving IANA L4 Port Discrepancies 624 Even though the IANA L4 ports usually point to the same 625 protocols for both UDP, TCP or other transport types, there 626 are some exceptions, as mentioned in the Appendix B. 628 Instead of imposing the transport protocol 629 (UDP/TCP/SCTP/etc.) in the scope of the "Application Name 630 Options Template Record" (section 6.8. ) for all 631 applications (on top of having the transport protocol as 632 key-field in the Flow Record definition), the convention is 633 that the L4 application is always TCP related. So, 634 whenever the Collector has a conflict in looking up IANA, 635 it would choose the TCP choice. As a result, the UDP L4 636 applications from Table 3 and the SCTP L4 applications from 637 Table 4 are assigned in the PANA_L7 Application Id range, 638 i.e. under Classification Engine ID 13. 640 Currently, there are no discrepancies between the well 641 known ports for TCP and DCCP. 643 5. Grouping the Applications with the Attributes 645 Due to the high number of different Application Ids, 646 Application Ids MAY be categorized into groups. This offers 647 the benefits of easier reporting and action, such as QoS 648 policies. Indeed, most applications with the same 649 characteristics should be treated the same way; for example, 650 all video traffic. 652 Attributes are statically assigned per Application Id and are 653 independent of the traffic. The attributes are listed below: 655 Name Description 657 Category An attribute that provides a first 658 level categorization for each 659 Application Id. Examples include: 660 browsing, email, file-sharing, 661 gaming, instant messaging, voice- 662 and-video, etc... 663 The category attribute is encoded by 664 the ApplicationCategoryName 665 Information Element. 667 Sub-Category An attribute that provides a second 668 level categorization for each 669 Application Id. Examples include: 670 backup-systems, client-server, 671 database, routing-protocol, etc... 672 The sub-category attribute is 673 encoded by the 674 ApplicationSubCategoryName 675 Information Element. 677 Application- An attribute that groups multiple 678 Group Application Ids that belong to the 679 same networking application. For 680 example, the ftp-group contain the 681 ftp-data (port 20), ftp (port 20), 682 ni-ftp (port 47), sftp (port 115), 683 bftp (port 152), ftp-agent(port 684 574), ftps-data (port 989). The 685 application-group attribute is 686 encoded by the ApplicationGroupName 687 Information Element. 689 P2P-Technology Specifies if the Application Id is 690 based on peer-to-peer technology. 691 The P2P-technology attribute is 692 encoded by the p2pTechnology 693 Information Element. 695 Tunnel- Specifies if the Application Id is 696 Technology used as a tunnel technology. The 697 tunnel-technology attribute is 698 encoded by the tunnelTechnology 699 Information Element. 701 Encrypted Specifies if the Application Id is 702 an encrypted networking protocol. 703 The encrypted attribute is encoded 704 by the encryptedTechnology 705 Information Element. 707 Table 3: Application Id Static Attributes 709 Every application is assigned to one 710 ApplicationCategoryName, one ApplicationSubCategoryName, 711 one ApplicationGroupName, has one p2pTechnology, one 712 tunnelTechnology, and one encryptedTechnology. These new 713 Information Elements are specified in the IANA 714 Consideration Section 7.1. 7.1. 716 Maintaining the attribute values in IANA seems impossible 717 to realize. Therefore the attribute values per application 718 are enterprise specific. 720 5.1. Options Template Record for the Attribute Values 722 An Options Template Record (see [RFC5101]) SHOULD be used 723 to export the correspondence between each Application Id 724 and its related Attribute values. An alternative way for 725 the Collecting Process to learn the correspondence is to 726 populate these mappings out of band, for example, by 727 loading a CSV file containing the correspondence table. 729 The Attributes Option Template contains the ApplicationId 730 as a scope field, followed by the ApplicationCategoryName, 731 the ApplicationSubCategoryName, the ApplicationGroupName, 732 the p2pTechnology, the tunnelTechnology, and the 733 encryptedTechnology Information Elements. 735 A list of attributes may conveniently be exported using a 736 subTemplateList per [RFC6313]. 738 An example is given in section 6.9. 740 6. Application Id Examples 742 The following examples are created solely for the purpose 743 of illustrating how the extensions proposed in this 744 document are encoded. 746 6.1. Example 1: Layer 2 Protocol 748 The list of Classification Engine IDs in Table 1 shows that 749 the layer 2 Classification Engine IDs are 12 (PANA-L2), 18, 750 (Ethertype) and 19 (LLC). 752 From the Ethertype list, LLDP [LLDP] has the Selector ID 753 value 0x88CC, so 35020 in decimal: 755 NAME Selector ID 756 LLDP 35020 758 So, in the case of LLDP, the Classification Engine ID is 18 759 (LLC) while the Selector ID has the value 35020. 761 Per section 4. , the applicationId Information Element, 762 is a single field composed of 8 bits of Classification 763 Engine ID, followed by m bits of Selector ID. 765 Therefore the Application Id is encoded as: 767 0 1 2 768 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | 18 | 35020 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 So the Application Id has the decimal value of 1214668. 774 The format '18..35020' is used for simplicity in the 775 examples below, to clearly express that two components of 776 the Application ID. 778 The Exporting Process creates a Template Record with a few 779 Information Elements: amongst other things, the Application 780 Id. For example: 782 - applicationId (key field) 783 - octetTotalCount (non key field) 785 For example, a Flow Record corresponding to the above 786 Template Record may contain: 788 { applicationId='18..35020', 789 octetTotalCount=123456 } 791 The Collector has all the required information to determine 792 that the application is LLDP, because the Application Id 793 uses a global and well known registry, i.e. the Ethertype. 794 The Collector can determine which application is 795 represented by the Application Id by loading the registry 796 out of band. 798 6.2. Example 2: Standardized IANA Layer 3 Protocol 800 From the list of Classification Engine IDs in Table 1, the 801 IANA layer 3 Classification Engine ID (IANA-L3) is 1. 803 From the list of IANA layer 3 protocols (see [IANA-PROTO]), 804 ICMP has the value 1: 806 Decimal Keyword Protocol Reference 807 1 ICMP Internet Control [RFC792] 808 Message 810 So in the case of the standardized IANA layer 3 protocol 811 ICMP, the Classification Engine ID is 1, and the Selector 812 ID has the value of 1. 814 Therefore the Application Id is encoded as: 816 0 1 817 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | 1 | 1 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 So the Application Id has the value of 257. The format 823 '1..1' is used for simplicity in the examples below. 825 The Exporting Process creates a Template Record with a few 826 Information Elements: amongst other things, the Application 827 Id. For example: 829 - sourceIPv4Address (key field) 830 - destinationIPv4Address (key field) 831 - ipDiffServCodePoint (key field) 832 - applicationId (key field) 833 - octetTotalCount (non key field) 835 For example, a Flow Record corresponding to the above 836 Template Record may contain: 838 { sourceIPv4Address=192.0.2.1, 839 destinationIPv4Address=192.0.2.2, 840 ipDiffServCodePoint=0, 841 applicationId='1..1', 842 octetTotalCount=123456 } 844 The Collector has all the required information to determine 845 that the application is ICMP, because the Application Id 846 uses a global and well know registry, ie the IANA L3 847 protocol number. 849 6.3. Example 3: Proprietary Layer 3 Protocol 851 Assume that a enterprise has specified a new layer 3 852 protocol called "foo". 854 From the list of Classification Engine IDs in Table 1, the 855 proprietary layer 3 Classification Engine ID (PANA-L3) is 856 2. 858 A global registry within the enterprise specifies that the 859 "foo" protocol has the value 90: 861 Protocol Protocol Id 862 foo 90 864 So, in the case of the layer 3 protocol foo specified by 865 this enterprise, the Classification Engine ID is 2, and the 866 Selector ID has the value of 90. 868 Therefore the Application Id is encoded as: 870 0 1 871 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | 2 | 90 | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 So the Application Id has the value of 602. The format 877 '2..90' is used for simplicity in the examples below. 879 The Exporting Process creates a Template Record with a few 880 Information Elements: amongst other things, the Application 881 Id. For example: 883 - sourceIPv4Address (key field) 884 - destinationIPv4Address (key field) 885 - ipDiffServCodePoint (key field) 886 - applicationId (key field) 887 - octetTotalCount (non key field) 889 For example, a Flow Record corresponding to the above 890 Template Record may contain: 892 { sourceIPv4Address=192.0.2.1, 893 destinationIPv4Address=192.0.2.2, 894 ipDiffServCodePoint=0, 895 applicationId='2..90', 896 octetTotalCount=123456 } 898 Along with this Flow Record, a new Options Template Record 899 would be exported, as shown in Section 6.8. 901 6.4. Example 4: Standardized IANA Layer 4 Port 903 From the list of Classification Engine IDs in Table 1, the 904 IANA layer 4 Classification Engine ID (PANA-L3) is 3. 906 From the list of IANA layer 4 ports (see [IANA-PORTS]), 907 SNMP has the value 161: 909 Keyword Decimal Description 910 snmp 161/tcp SNMP 911 snmp 161/udp SNMP 913 So in the case of the standardized IANA layer 4 SNMP port, 914 the Classification Engine ID is 3, and the Selector ID has 915 the value of 161. 917 Therefore the Application Id is encoded as: 919 0 1 920 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | 3 | 161 | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 So the Application Id has the value of 196769. The format 926 '3..161' is used for simplicity in the examples below. 928 The Exporting Process creates a Template Record with a few 929 Information Elements: amongst other things, the Application 930 Id. For example: 932 - sourceIPv4Address (key field) 933 - destinationIPv4Address (key field) 934 - protocol (key field) 935 - ipDiffServCodePoint (key field) 936 - applicationId (key field) 937 - octetTotalCount (non key field) 939 For example, a Flow Record corresponding to the above 940 Template Record may contain: 942 { sourceIPv4Address=192.0.2.1, 943 destinationIPv4Address=192.0.2.2, 944 protocol=17, ipDiffServCodePoint=0, 945 applicationId='3..161', 946 octetTotalCount=123456 } 948 The Collector has all the required information to determine 949 that the application is SNMP, because the Application Id 950 uses a global and well know registry, ie the IANA L4 951 protocol number. 953 6.5. Example 5: Layer 7 Application 955 In this example, the Metering Process has observed some 956 Webex traffic. 958 From the list of Classification Engine IDs in Table 1, the 959 layer 7 unique Classification Engine ID (PANA-L7) is 13. 961 Suppose that the Metering Process returns the ID 10000 for 962 Webex traffic. 964 So, in the case of this Webex application, the 965 Classification Engine ID is 13 and the Selector ID has the 966 value of 10000. 968 Therefore the Application Id is encoded as: 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | 13 | 10000 | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 So the Application Id has the value of 218113808. The 976 format '13..10000' is used for simplicity in the examples 977 below. 979 The Exporting Process creates a Template Record with a few 980 Information Elements: amongst other things, the Application 981 Id. For example: 983 - sourceIPv4Address (key field) 984 - destinationIPv4Address (key field) 985 - ipDiffServCodePoint (key field) 986 - applicationId (key field) 987 - octetTotalCount (non key field) 989 For example, a Flow Record corresponding to the above 990 Template Record may contain: 992 { sourceIPv4Address=192.0.2.1, 993 destinationIPv4Address=192.0.2.2, 994 ipDiffServCodePoint=0, 995 applicationId='13..10000', 996 octetTotalCount=123456 } 998 The 10000 value is globally unique for the enterprise, so 999 that the Collector can determine which application is 1000 represented by the Application Id by loading the registry 1001 out of band. 1003 Along with this Flow Record, a new Options Template Record 1004 would be exported, as shown in Section 6.8. 1006 6.6. Example 6: Layer 7 Application with Private Enterprise 1007 Number (PEN) 1009 In this example, the layer 7 Webex traffic from Example 5 1010 above have been classified by enterprise X. The exported 1011 records have been received by enterprise Y's mediation 1012 device, which wishes to forward them to a top level 1013 Collector. 1015 In order for the top level Collector to know that the 1016 records were classified by enterprise X, the enterprise Y 1017 mediation device must report the records using the 1018 PANA-L7-PEN Classification Engine ID with enterprise X's 1019 Private Enterprise Number. 1021 The PANA-L7-PEN Classification Engine ID is 20, and 1022 enterprise X's Selector ID for Webex traffic has the value 1023 of 10000. 1025 Therefore the Application Id is encoded as: 1027 0 1 2 3 1028 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 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | 20 | enterprise ID = X ...| 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 |...Ent.ID.contd| 10000 | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 The format '20..X..10000' is used for simplicity in the 1036 examples below. 1038 The Exporting Process creates a Template Record with a few 1039 Information Elements: amongst other things, the Application 1040 Id. For example: 1042 - sourceIPv4Address (key field) 1043 - destinationIPv4Address (key field) 1044 - ipDiffServCodePoint (key field) 1045 - applicationId (key field) 1046 - octetTotalCount (non key field) 1048 For example, a Flow Record corresponding to the above 1049 Template Record may contain: 1051 { sourceIPv4Address=192.0.2.1, 1052 destinationIPv4Address=192.0.2.2, 1053 ipDiffServCodePoint=0, 1054 applicationId='20..X..10000', 1055 octetTotalCount=123456 } 1057 The 10000 value is globally unique for enterprise X, so 1058 that the Collector can determine which application is 1059 represented by the Application Id by loading the registry 1060 out of band. 1062 Along with this Flow Record, a new Options Template Record 1063 would be exported, as shown in Section 6.8. 1065 6.7. Example: port Obfuscation 1067 For example, an HTTP server might run on a TCP port 23 1068 (assigned to telnet in [IANA-PORTS]). If the Metering 1069 Process is capable of detecting HTTP in the same case, the 1070 Application Id representation must contain HTTP. However, 1071 if the reporting application wants to determine whether the 1072 default HTTP port 80 or 8080 was used, the destination port 1073 (destinationTransportPort at [IANA-IPFIX]) must also be 1074 exported in the corresponding IPFIX record. 1076 In the case of a standardized IANA layer 4 port, the 1077 Classification Engine ID (PANA-L4) is 3, and the Selector 1078 ID has the value of 80 for HTTP (see [IANA-PORTS]). 1079 Therefore the Application Id is encoded as: 1081 0 1 2 1082 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | 3 | 80 | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 The Exporting Process creates a Template Record with a few 1088 Information Elements: amongst other things, the Application 1089 Id. For example: 1091 - sourceIPv4Address (key field) 1092 - destinationIPv4Address (key field) 1093 - protocol (key field) 1094 - destinationTransportPort (key field) 1095 - applicationId (key field) 1096 - octetTotalCount (non key field) 1098 For example, a Flow Record corresponding to the above 1099 Template Record may contain: 1101 { sourceIPv4Address=192.0.2.1, 1102 destinationIPv4Address=192.0.2.2, 1103 protocol=17, 1104 destinationTransportPort=23, 1105 applicationId='3..80', 1106 octetTotalCount=123456 } 1108 The Collector has all the required information to determine 1109 that the application is HTTP, but runs on port 23. 1111 6.8. Example: Application Name Mapping Options Template 1113 Along with the Flow Records shown in the above examples, a 1114 new Options Template Record should be exported to express 1115 the Application Name and Application Description associated 1116 with each Application Id. 1118 The Options Template Record contains the following 1119 Information Elements: 1121 1. Scope = applicationId. 1123 From RFC 5101: "The scope, which is only available 1124 in the Options Template Set, gives the context of 1125 the reported Information Elements in the Data 1126 Records." 1128 2. applicationName. 1130 3. applicationDescription. 1132 The Options Data Record associated with the examples above 1133 would contain, for example: 1135 { scope=applicationId='2..90', 1136 applicationName="foo", 1137 applicationDescription="The foo protocol", 1139 scope=applicationId='13..10000', 1140 applicationName="webex", 1141 applicationDescription="Webex application" } 1143 scope=applicationId='20..X..10000', 1144 applicationName="webex", 1145 applicationDescription="Webex application" } 1147 When combined with the example Flow Records above, these 1148 Options Template Records tell the Collector: 1150 1. A flow of 123456 bytes exists from sourceIPv4Address 1151 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1152 applicationId of '12..90', which maps to the "foo" 1153 application. 1155 2. A flow of 123456 bytes exists from sourceIPv4Address 1156 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1157 Application Id of '13..10000', which maps to the "Webex" 1158 application. 1160 3. A flow of 123456 bytes exists from sourceIPv4Address 1161 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1162 Application Id of '20..PEN..10000', which maps to the 1163 "Webex" application, according to the application registry 1164 from the entrerprise X. 1166 6.9. Example: Attributes Values Options Template Record 1168 Along with the Flow Records shown in the above examples, a 1169 new Options Template Record is exported to express the 1170 values of the different attributes related to the 1171 Application Ids. 1173 The Options Template Record would contain the following 1174 Information Elements: 1176 1. Scope = applicationId. 1178 From RFC 5101: "The scope, which is only available 1179 in the Options Template Set, gives the context of 1180 the reported Information Elements in the Data 1181 Records." 1183 2. applicationCategoryName. 1185 3. applicationSubCategoryName. 1187 4. applicationGroupName 1189 5. p2pTechnology 1191 6. tunnelTechnology 1193 7. encryptedTechnology 1195 The Options Data Record associated with the examples above 1196 would contain, for example: 1198 { scope=applicationId='2..90', 1199 applicationCategoryName="foo-category", 1200 applicationSubCategoryName="foo-subcategory", 1201 applicationGroupName="foo-group", 1202 p2pTechnology=NO 1203 tunnelTechnology=YES 1204 encryptedTechnology=NO 1206 When combined with the example Flow Records above, these 1207 Options Template Records tell the Collector: 1209 A flow of 123456 bytes exists from sourceIPv4Address 1210 192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP 1211 value of 0 and an applicationId of '12..90', which maps to 1212 the "foo" application. This application can be 1213 characterized by the relevant attributes values. 1215 7. IANA Considerations 1217 7.1. New Information Elements 1219 This document specifies 10 new IPFIX Information Elements: 1220 the applicationDescription, applicationId, applicationName, 1221 classificationEngineId, applicationCategoryName, 1222 applicationSubCategoryName, applicationGroupName, 1223 p2pTechnology, tunnelTechnology, and encryptedTechnology. 1225 New Information Elements to be added to the IPFIX Information 1226 Element registry at [IANA-IPFIX] are listed below. 1228 EDITOR'S NOTE: RFC5102, which explains the IANA 1229 considerations for assigning new Information Elements 1230 mentions. "The value of these identifiers is in the range of 1231 1-32767. Within this range, Information Element identifier 1232 values in the sub-range of 1-127 are compatible with field 1233 types used by NetFlow version 9 [RFC3954].". This is the 1234 reason why some Information Elements have already an assigned 1235 ElementId in the range 1-127, instead of . These 1236 Information Elements should anyway follow the IANA 1237 Considerations from RFC5102, i.e. " New assignments for IPFIX 1238 Information Elements will be administered by IANA through 1239 Expert Review review". The reviewer is Nevil Brownlee. 1240 EDITOR'S NOTE: the XML specification in Appendix A must be 1241 updated with the elementID values allocated below. 1243 RFC-EDITOR/IANA-EDITOR: some entries are already present in 1244 IPFIX-IANA. However, those must be updated with the current 1245 content. 1247 7.1.1. applicationDescription 1249 Name: applicationDescription 1250 Description: 1251 Specifies the description of an application. 1252 Abstract Data Type: string 1253 Data Type Semantics: 1254 ElementId: 94 1255 Status: current 1257 7.1.2. applicationId 1259 Name: applicationId 1260 Description: 1261 Specifies an Application Id. 1262 Abstract Data Type: octetArray 1263 Data Type Semantics: identifier 1264 Reference: See section 4. of [EDITORS NOTE: this document] 1265 for the applicationId Information Element Specification. 1266 ElementId: 95 1267 Status: current 1269 7.1.3. applicationName 1271 Name: applicationName 1272 Description: 1273 Specifies the name of an application. 1274 Abstract Data Type: string 1275 Data Type Semantics: 1276 ElementId: 96 1277 Status: current 1279 7.1.4. classificationEngineId 1281 Name: classificationEngineId 1282 Description: 1283 A unique identifier for the engine which determined the 1284 Selector ID. Thus the Classification Engine ID defines 1285 the context for the Selector ID. The Classification 1286 Engine can be considered as a specific registry for 1287 application assignments. 1289 Initial values for this field are listed below. Further 1290 values may be assigned by IANA in the Classification 1291 Engine Ids registry. 1293 0 Invalid. 1295 1 IANA-L3: The Assigned Internet Protocol Number 1296 (layer 3 (L3)) is exported in the Selector ID. See 1297 http://www.iana.org/assignments/protocol-numbers. 1299 2 PANA-L3: Proprietary layer 3 definition. An 1300 enterprise can export its own layer 3 protocol 1301 numbers. The Selector ID has a global significance 1302 for all devices from the same enterprise. 1304 3 IANA-L4: The IANA layer 4 (L4) well-known port 1305 number is exported in the Selector ID. See [IANA- 1306 PORTS]. Note: as an IPFIX flow is unidirectional, 1307 it contains the destination port in a flow from 1308 the client to the server. 1310 4 PANA-L4: Proprietary layer 4 definition. An 1311 enterprise can export its own layer 4 port 1312 numbers. The Selector ID has global significance 1313 for devices from the same enterprise. Example: 1314 IPFIX had the port 4739 pre-assigned in the IETF 1315 draft for years. While waiting for the RFC and its 1316 associated IANA registration, the Selector ID 4739 1317 was used with this PANA-L4. 1319 5 Reserved 1321 6 USER-Defined: The Selector ID represents 1322 applications defined by the user (using CLI, GUI, 1323 etc.) based on the methods described in section 2. 1324 The Selector ID has a local significance per 1325 device. 1327 7 Reserved 1329 8 Reserved 1331 9 Reserved 1333 10 Reserved 1335 11 Reserved 1337 12 PANA-L2: Proprietary layer 2 (L2) definition. An 1338 enterprise can export its own layer 2 identifiers. 1339 The Selector ID represents the enterprise's unique 1340 global layer 2 applications. The Selector ID has a 1341 global significance for all devices from the same 1342 enterprise. Examples include Cisco Subnetwork 1343 Access Protocol (SNAP). 1345 13 PANA-L7: Proprietary layer 7 definition. The 1346 Selector ID represents the enterprise's unique 1347 global ID for the layer 7 applications. The 1348 Selector ID has a global significance for all 1349 devices from the same enterprise. This 1350 Classification Engine Id is used when the 1351 application registry is owned by the Exporter 1352 manufacturer (referred to as the "enterprise" in 1353 this document). 1355 14 Reserved 1357 15 Reserved 1359 16 Reserved 1361 17 Reserved 1363 18 ETHERTYPE: The Selector ID represents the well- 1364 known Ethertype. See [ETHERTYPE]. Note that the 1365 Ethertype is usually expressed in hexadecimal. 1366 However, the corresponding decimal value is used 1367 in this Selector ID. 1369 19 LLC: The Selector ID represents the well-known 1370 IEEE 802.2 Link Layer Control (LLC) Destination 1371 Service Access Point (DSAP). See [LLC]. Note that 1372 LLC DSAP is usually expressed in hexadecimal. 1373 However, the corresponding decimal value is used 1374 in this Selector ID. 1376 20 PANA-L7-PEN: Proprietary layer 7 definition, 1377 including a Private Enterprise Number (PEN) [PEN] 1378 to identify that the application registry being 1379 used is not owned by the Exporter manufacturer 1380 (referred to as the "enterprise" in this document, 1381 and identified by the PEN), or to identify the 1382 original enterprise in the case of a mediator or 1383 3rd party device. The Selector ID represents the 1384 enterprise unique global ID for the layer 7 1385 applications. The Selector ID has a global 1386 significance for all devices from the same 1387 enterprise. 1389 Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17), 1390 are reserved to be compliant with existing 1391 implementations already using the 1392 classificationEngineId. 1394 Abstract Data Type: unsigned8 1395 Data Type Semantics: identifier 1396 ElementId: 101 1397 Status: current 1399 7.1.5. applicationCategoryName 1401 Name: applicationCategoryName 1402 Description: 1403 An attribute that provides a first level categorization for 1404 each Application Id. 1405 Abstract Data Type: string 1406 Data Type Semantics: 1407 ElementId: 1408 Status: current 1410 7.1.6. applicationSubCategoryName 1412 Name: applicationSubCategoryName 1413 Description: 1414 An attribute that provides a second level categorization 1415 for each Application Id. 1416 Abstract Data Type: string 1417 Data Type Semantics: 1418 ElementId: 1419 Status: current 1421 7.1.7. applicationGroupName 1423 Name: applicationGroupName 1424 Description: 1425 An attribute that groups multiple Application Ids that 1426 belong to the same networking application. 1427 Abstract Data Type: string 1428 Data Type Semantics: 1429 ElementId: 1430 Status: current 1432 7.1.8. p2pTechnology 1434 Name: p2pTechnology 1435 Description: 1436 Specifies if the Application Id is based on peer-to-peer 1437 technology. Possible values are: { "yes", "y", 1 }, 1438 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1439 Abstract Data Type: string 1440 Data Type Semantics: 1441 ElementId: 288 1442 Status: current 1444 7.1.9. tunnelTechnology 1446 Name: tunnelTechnology 1447 Description: 1448 Specifies if the Application Id is used as a tunnel 1449 technology. 1450 Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } 1451 and 1452 { "unassigned" , "u", 0 }. 1453 Abstract Data Type: string 1454 Data Type Semantics: 1455 ElementId: 289 1456 Status: current 1458 7.1.10. encryptedTechnology 1460 Name: encryptedTechnology 1461 Description: 1462 Specifies if the Application Id is an encrypted networking 1463 protocol. Possible values are: { "yes", "y", 1 }, 1464 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1465 Abstract Data Type: string 1466 Data Type Semantics: 1468 ElementId: 290 1469 Status: current 1471 7.2. Classification Engine Ids Registry 1473 The Information Element #101, named classificationEngineId, 1474 carries information about the context for the Selector ID, 1475 and can be considered as a specific registry for application 1476 assignments. For ensuring extensibility of this information, 1477 IANA has created a new registry for Classification Engine Ids 1478 and filled it with the initial list from the description 1479 Information Element #101, classificationEngineId. 1481 New assignments for Classification Engine Ids will be 1482 administered by IANA through Expert Review [RFC5226], i.e., 1483 review by one of a group of experts designated by an IETF 1484 Area Director. The group of experts must double check the 1485 new definitions with already defined Classification Engine 1486 Ids for completeness, accuracy, and redundancy. The 1487 specification of Classification Engine Ids MUST be published 1488 using a well-established and persistent publication medium. 1490 RFC-EDITOR: this should be assigned similarly to 1491 mplsTopLabelType subregistry at 1492 http://www.iana.org/assignments/ipfix/ipfix.xml 1494 8. Security Considerations 1496 The same security considerations as for the IPFIX Protocol 1497 [RFC5101] apply. The IPFIX extension specified in this memo 1498 allows to identify what applications are used on the network. 1499 Consequently, it is possible to identify what applications 1500 are being used by the users, potentially threatening the 1501 privacy of those users, if not handled with great care. 1503 As mentioned in Section 1.1. , the application knowledge is 1504 useful in security based applications. Security applications 1505 may impose supplementary requirements on the export of 1506 application information, and these need to be examined on a 1507 case by case basis. 1509 9. References 1511 9.1. Normative References 1513 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1514 Requirement Levels, BCP 14, RFC 2119, March 1997. 1516 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 1517 Information Export (IPFIX) Protocol for the 1518 Exchange of IP Traffic Flow Information", RFC 5101, 1519 January 2008. 1521 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., 1522 and J. Meyer, "Information Model for IP Flow 1523 Information Export", RFC 5102, January 2008. 1525 [RFC5226] Narten, T., and H. Alverstrand, "Guidelines for 1526 Writing an IANA Considerations Section in RFCs", 1527 RFC 5226, May 2008 1529 [ETHERTYPE] 1530 http://standards.ieee.org/develop/regauth/ethertype 1531 /eth.txt 1533 [IANA-PORTS] http://www.iana.org/assignments/port-numbers 1535 [IANA-PROTO] http://www.iana.org/assignments/protocol- 1536 numbers 1538 [LLC] 1539 http://standards.ieee.org/develop/regauth/llc/publi 1540 c.html. 1542 [PEN] http://www.iana.org/assignments/enterprise-numbers 1544 9.2. Informative References 1546 [RFC792] J. Postel, Internet Control Message Protocol, RFC 1547 792, September 1981. 1549 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. 1550 Zander, Requirements for IP Flow Information 1551 Export, RFC 3917, October 2004. 1553 [RFC3954] B. Claise, "Cisco Systems NetFlow Services Export 1554 Version 9", RFC 3954, October 2004. 1556 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 1557 Export Using IP Flow Information Export (IPFIX)", 1558 RFC 5103, January 2008. 1560 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 1561 Quittek, "Architecture for IP Flow Information 1562 Export", RFC 5470, March 2009. 1564 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, 1565 "Guidelines for IP Flow Information Export (IPFIX) 1566 Testing", RFC 5471, March 2009. 1568 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 1569 Redundancy in IP Flow Information Export (IPFIX) 1570 and Packet Sampling (PSAMP) Reports", RFC 5473, 1571 March 2009. 1573 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) 1574 Protocol Specifications", RFC 5476, March 2009. 1576 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dresslet F., 1577 and G. Carle, "Information Model for Packet 1578 Sampling Exports", RFC 5477, March 2009. 1580 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. 1581 Ishibashi, "IP Flow Information Export (IPFIX) 1582 Mediation: Framework", RFC6183, April 2011 1584 [RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S. 1585 Yates, "Export of Structured Data in IP Flow 1586 Information Export (IPFIX)", RFC6313, July 2011 1588 [LLDP] "IEEE Std 802.1AB-2005, Standard for Local and 1589 metropolitan area networks - Station and Media 1590 Access Control Connectivity Discovery", IEEE Std 1591 802.1AB-2005 IEEE Std, 2005. 1593 [IANA-IPFIX] 1594 http://www.iana.org/assignments/ipfix/ipfix.xml 1596 [CISCO-APPLICATION-REGISTRY] 1597 http://www.cisco.com/go/application_registry 1599 10. Acknowledgement 1601 The authors would like to thank their many colleagues across 1602 Cisco Systems who made this work possible. Specifically 1603 Patrick Wildi for his time and expertise. 1605 11. Authors' Addresses 1607 Benoit Claise 1608 Cisco Systems, Inc. 1609 De Kleetlaan 6a b1 1610 Diegem 1813 1611 Belgium 1613 Phone: +32 2 704 5622 1614 EMail: bclaise@cisco.com 1616 Paul Aitken 1617 Cisco Systems, Inc. 1618 96 Commercial Quay 1619 Commercial Street 1620 Edinburgh, EH6 6LX, United Kingdom 1622 Phone: +44 131 561 3616 1623 EMail: paitken@cisco.com 1625 Nir Ben-Dvora 1626 Cisco Systems, Inc. 1627 32 HaMelacha St., 1628 P.O.Box 8735, I.Z.Sapir 1629 South Netanya, 42504 1630 Israel 1632 Phone: +972 9 892 7187 1633 EMail: nirbd@cisco.com 1635 Appendix A. Additions to XML Specification of IPFIX 1636 Information Elements (non normative) 1638 This appendix A contains additions to the machine-readable 1639 description of the IPFIX information model coded in XML in 1640 Appendix A and Appendix B in [RFC5102]. Note that this 1641 appendix is of informational nature, while the text in 1642 Section 7. (generated from this appendix) is normative. 1644 The following field definitions are appended to the IPFIX 1645 information model in Appendix A of [RFC5102]. 1647 1652 1653 1654 Specifies the description of an application. 1655 1656 1657 1659 1665 1666 1667 Specifies an Application Id. 1668 1669 1670 1671 1672 See section 4. of [EDITORS NOTE: this document] 1673 for the applicationId Information Element 1674 Specification. 1675 1676 1677 1679 1684 1685 1686 Specifies the name of an application. 1687 1688 1689 1691 1697 1698 1699 0 Invalid. 1701 1 IANA-L3: The Assigned Internet Protocol Number 1702 (layer 3 (L3)) is exported in the Selector ID. 1703 See http://www.iana.org/assignments/protocol- 1704 numbers. 1706 2 PANA-L3: Proprietary layer 3 definition. An 1707 enterprise can export its own layer 3 protocol 1708 numbers. The Selector ID has a global 1709 significance for all devices from the same 1710 enterprise. 1712 3 IANA-L4: The IANA layer 4 (L4) well-known port 1713 number is exported in the Selector ID. See 1714 [IANA-PORTS]. Note: as an IPFIX flow is 1715 unidirectional, it contains the destination 1716 port in a flow from the client to the server. 1718 4 PANA-L4: Proprietary layer 4 definition. An 1719 enterprise can export its own layer 4 port 1720 numbers. The Selector ID has global 1721 significance for devices from the same 1722 enterprise. Example: IPFIX had the port 4739 1723 pre-assigned in the IETF draft for years. 1724 While waiting for the RFC and its associated 1725 IANA registration, the Selector ID 4739 was 1726 used with this PANA-L4. 1728 5 Reserved 1730 6 USER-Defined: The Selector ID represents 1731 applications defined by the user (using CLI, 1732 GUI, etc.) based on the methods described in 1733 section 2. The Selector ID has a local 1734 significance per device. 1736 7 Reserved 1738 8 Reserved 1740 9 Reserved 1742 10 Reserved 1744 11 Reserved 1746 12 PANA-L2: Proprietary layer 2 (L2) definition. 1747 An enterprise can export its own layer 2 1748 identifiers. The Selector ID represents the 1749 enterprise's unique global layer 2 1750 applications. The Selector ID has a global 1751 significance for all devices from the same 1752 enterprise. Examples include Cisco Subnetwork 1753 Access Protocol (SNAP). 1755 13 PANA-L7: Proprietary layer 7 definition. The 1756 Selector ID represents the enterprise's unique 1757 global ID for the layer 7 applications. The 1758 Selector ID has a global significance for all 1759 devices from the same enterprise. This 1760 Classification Engine Id is used when the 1761 application registry is owned by the Exporter 1762 manufacturer (referred to as the "enterprise" 1763 in this document). 1765 14 Reserved 1767 15 Reserved 1769 16 Reserved 1771 17 Reserved 1773 18 ETHERTYPE: The Selector ID represents the 1774 well-known Ethertype. See [ETHERTYPE]. Note 1775 that the Ethertype is usually expressed in 1776 hexadecimal. However, the corresponding 1777 decimal value is used in this Selector ID. 1779 19 LLC: The Selector ID represents the well-known 1780 IEEE 802.2 Link Layer Control (LLC) 1781 Destination Service Access Point (DSAP). See 1782 [LLC]. Note that LLC DSAP is usually expressed 1783 in hexadecimal. However, the corresponding 1784 decimal value is used in this Selector ID. 1786 20 PANA-L7-PEN: Proprietary layer 7 definition, 1787 including a Private Enterprise Number (PEN) 1788 [PEN] to identify that the application 1789 registry being used is not owned by the 1790 Exporter manufacturer (referred to as the 1791 "enterprise" in this document, and identified 1792 by the PEN), or to identify the original 1793 enterprise in the case of a mediator or 3rd 1794 party device. The Selector ID represents the 1795 enterprise unique global ID for the layer 7 1796 applications. The Selector ID has a global 1797 significance for all devices from the same 1798 enterprise. 1799 1800 1801 1803 1809 1810 1811 An attribute that provides a first level 1812 categorization 1813 for each Application Id. 1814 1815 1816 1818 1824 1825 1826 An attribute that provides a second level 1827 categorization for each Application Id. 1828 1829 1830 1832 1838 1839 1840 An attribute that groups multiple Application Ids 1841 that belong to the same networking application. 1842 1843 1844 1846 1852 1853 1854 Specifies if the Application Id is based on peer- 1855 to-peer technology. Possible values are: 1856 { "yes", "y", 1 }, { "no", "n", 2 } and 1857 { "unassigned" , "u", 0 }. 1858 1859 1860 1862 1868 1869 1870 Specifies if the Application Id is used as a 1871 tunnel technology. Possible values are: 1872 { "yes", "y", 1 }, { "no", "n", 2 } and 1873 { "unassigned" , "u", 0 }. 1874 1875 1876 1878 1884 1885 1886 Specifies if the Application Id is an encrypted 1887 networking protocol. Possible values are: 1888 { "yes", "y", 1 }, { "no", "n", 2 } and 1889 { "unassigned" , "u", 0 }. 1890 1891 1892 1894 Appendix B. Port Collisions Tables (non normative) 1896 The following table lists the 10 ports that have different 1897 protocols assigned for TCP and UDP (at the time of writing 1898 this document): 1900 exec 512/tcp remote process execution; 1901 authentication performed 1902 using passwords and UNIX 1903 login names 1905 comsat/biff 512/udp used by mail system to 1906 notify users of new mail 1907 received; currently 1908 receives messages only from 1909 processes on the same 1910 machine 1912 login 513/tcp remote login a la 1913 telnet; automatic 1914 authentication 1915 performed based on 1916 priviledged port numbers 1917 and distributed data bases 1918 which identify 1920 "authentication domains" 1921 who 513/udp maintains data bases 1922 showing who's logged in to 1923 machines on a local 1924 net and the load average of 1925 the machine 1927 shell 514/tcp cmd 1928 like exec, but automatic 1929 authentication is performed 1930 as for login server 1932 syslog 514/udp 1934 oob-ws-https 664/tcp DMTF out-of-band secure web 1935 services management 1936 protocol 1937 Jim Davis 1939 1940 June 2007 1942 asf-secure-rmcp 664/udp ASF Secure Remote 1943 Management and Control 1944 Protocol 1946 rfile 750/tcp 1947 kerberos-iv 750/udp kerberos version iv 1949 submit 773/tcp 1950 notify 773/udp 1952 rpasswd 774/tcp 1953 acmaint_dbd 774/udp 1955 entomb 775/tcp 1956 acmaint_transd 775/udp 1958 busboy 998/tcp 1959 puparp 998/udp 1961 garcon 999/tcp 1962 applix 999/udp Applix ac 1964 Table 4: Different Protocols on UDP and TCP 1966 The following table lists the 19 ports that have different 1967 protocols assigned for TCP and SCTP (at the time of writing 1968 this document): 1970 # 3097/tcp Reserved 1972 itu-bicc-stc 3097/sctp ITU-T Q.1902.1/Q.2150.3 1973 Greg Sidebottom 1974 1976 # 5090/tcp 1978 car 5090/sctp Candidate AR 1980 # 5091/tcp 1982 cxtp 5091/sctp Context Transfer Protocol 1983 RFC 4065 - July 2005 1985 # 6704/tcp Reserved 1987 frc-hp 6704/sctp ForCES HP (High Priority) 1988 channel [RFC5811] 1990 # 6705/tcp Reserved 1992 frc-mp 6705/sctp ForCES MP (Medium 1993 Priority) channel 1994 [RFC5811] 1996 # 6706/tcp Reserved 1997 frc-lp 6706/sctp ForCES LP (Low priority) 1998 channel [RFC5811] 2000 # 9082/tcp 2002 lcs-ap 9082/sctp LCS Application Protocol 2003 Kimmo Kymalainen 2004 kimmo.kymalainen&etsi.org> 2005 04 June 2010 2007 # 9902/tcp 2009 enrp-sctp-tls 9902/sctp enrp/tls server channel 2010 [RFC5353] 2012 # 11997/tcp 2013 # 11998/tcp 2014 # 11999/tcp 2016 Wmereceiving 11997/sctp WorldMailExpress 2017 wmedistribution 11998/sctp WorldMailExpress 2018 wmereporting 11999/sctp WorldMailExpress 2019 Greg Foutz 2020 2021 March 2006 2023 # 25471/tcp 2025 rna 25471/sctp RNSAP User Adaptation for 2026 Iurh 2027 Dario S. Tonesi 2028 2029 07 February 2011 2031 # 29118/tcp Reserved 2033 sgsap 29118/sctp SGsAP in 3GPP 2035 # 29168/tcp Reserved 2037 sbcap 29168/sctp SBcAP in 3GPP 2039 # 29169/tcp 2040 iuhsctpassoc 29169/sctp HNBAP and RUA Common 2041 Association 2042 John Meredith 2043 2044 08 September 2009 2046 # 36412/tcp 2048 s1-control 36412/sctp S1-Control Plane (3GPP) 2049 KimmoKymalainen 2050 2051 01 September 2009 2053 # 36422/tcp 2055 x2-control 36422/sctp X2-Control Plane (3GPP) 2056 Kimmo Kymalainen 2057 2058 01 September 2009 2060 # 36443/tcp 2062 m2ap 36443/sctp M2 Application Part 2063 Dario S. Tonesi 2064 2065 07 February 2011 2067 # 36444/tcp 2069 m3ap 36444/sctp M3 Application Part 2070 Dario S. Tonesi 2071 2072 07 February 2011 2074 Table 5: Different Protocols on SCTP and TCP 2076 Appendix C. Application Registry Example (non normative) 2078 A reference to the Cisco Systems assigned numbers for the 2079 Application Id and the different attribute assignments can 2080 be found at [CISCO-APPLICATION-REGISTRY]. 2082 RFC-EDITOR NOTE: at the time of publication, if [CISCO- 2083 APPLICATION-REGISTRY] is not available, this appendix, and 2084 the [CISCO-APPLICATION-REGISTRY] reference must be removed.