idnits 2.17.1 draft-claise-export-application-info-in-ipfix-09.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. -- 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 1902 has weird spacing: '...512/tcp rem...' == Line 1907 has weird spacing: '...512/udp use...' == Line 1914 has weird spacing: '...513/tcp rem...' == Line 1923 has weird spacing: '...513/udp mai...' == Line 1929 has weird spacing: '...514/tcp cmd...' == (2 more instances...) -- The document date (July 9, 2012) is 4309 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 2000, but not defined == Missing Reference: 'RFC5353' is mentioned on line 2012, 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 (~~), 9 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: January 8, 2013 Cisco Systems, Inc. 6 July 9, 2012 8 Cisco Systems Export of Application Information in IPFIX 9 draft-claise-export-application-info-in-ipfix-09 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. Overview................................................. 5 86 1.1. IPFIX Documents Overview............................ 5 87 2. Introduction............................................. 6 88 2.1. Application Information Use Cases...................... 8 89 3. Terminology.............................................. 8 90 3.1. New Terminology..................................... 9 91 4. applicationId Information Element Specification.......... 9 92 4.1. Existing Classification Engine IDs................. 10 93 4.2. Selector ID Length per Classification IDs.......... 14 94 4.3. Application Name Options Template Record........... 15 95 4.4. Resolving IANA L4 Port Discrepancies............... 16 96 5. Grouping the Applications with the Attributes........... 16 97 5.1. Options Template Record for the Attribute Values... 18 98 6. Application Id Examples................................. 18 99 6.1. Example 1: Layer 2 Protocol........................ 19 100 6.2. Example 2: Standardized IANA Layer 3 Protocol...... 20 101 6.3. Example 3: Proprietary Layer 3 Protocol............ 21 102 6.4. Example 4: Standardized IANA Layer 4 Port.......... 22 103 6.5. Example 5: Layer 7 Application..................... 23 104 6.6. Example 6: Layer 7 Application with Private 105 Enterprise Number (PEN)................................. 24 106 6.7. Example: port Obfuscation.......................... 26 107 6.8. Example: Application Name Mapping Options Template. 27 108 6.9. Example: Attributes Values Options Template Record. 28 109 7. IANA Considerations..................................... 29 110 7.1. New Information Elements........................... 29 111 7.1.1. applicationDescription........................... 30 112 7.1.2. applicationId.................................... 30 113 7.1.3. applicationName.................................. 30 114 7.1.4. classificationEngineId........................... 30 115 7.1.5. applicationCategoryName.......................... 33 116 7.1.6. applicationSubCategoryName....................... 33 117 7.1.7. applicationGroupName............................. 34 118 7.1.8. p2pTechnology.................................... 34 119 7.1.9. tunnelTechnology................................. 34 120 7.1.10. encryptedTechnology............................. 34 121 7.2. Classification Engine Ids Registry................. 35 122 8. Security Considerations................................. 35 123 9. References.............................................. 36 124 9.1. Normative References............................... 36 125 9.2. Informative References............................. 36 126 10. Acknowledgement........................................ 38 127 11. Authors' Addresses..................................... 39 128 Appendix A. Additions to XML Specification of IPFIX 129 Information Elements (non normative)....................... 39 130 Appendix B. Port Collisions Tables (non normative)........ 45 131 Appendix C. Application Registry Example (non 132 normative)................................................. 49 134 List of Figures and Tables 136 Figure 1: applicationId Information Element .............. 9 137 Table 1: Existing Classification Engine IDs ............. 13 138 Table 2: Selector ID default length per Classification 139 Engine ID ............................................ 14 140 Table 3: Application Id Static Attributes ............... 18 141 Table 4: Different Protocols on UDP and TCP ............. 47 142 Table 5: Different Protocols on SCTP and TCP ............ 49 144 1. Overview 146 1.1. IPFIX Documents Overview 148 The IPFIX Protocol [RFC5101] provides network administrators 149 with access to IP Flow information. 151 The architecture for the export of measured IP Flow 152 information out of an IPFIX Exporting Process to a Collecting 153 Process is defined in the IPFIX Architecture [RFC5470], per 154 the requirements defined in RFC 3917 [RFC3917]. 156 The IPFIX Architecture [RFC5470] specifies how IPFIX Data 157 Records and Templates are carried via a congestion-aware 158 transport protocol from IPFIX Exporting Processes to IPFIX 159 Collecting Processes. 161 IPFIX has a formal description of IPFIX Information Elements, 162 their name, type and additional semantic information, as 163 specified in the IPFIX information model [RFC5102]. 165 In order to gain a level of confidence in the IPFIX 166 implementation, probe the conformity and robustness, and 167 allow interoperability, the Guidelines for IPFIX Testing 169 [RFC5471] presents a list of tests for implementers of 170 compliant Exporting Processes and Collecting Processes. 172 The Bidirectional Flow Export [RFC5103] specifies a method 173 for exporting bidirectional flow (biflow) information using 174 the IP Flow Information Export (IPFIX) protocol, representing 175 each Biflow using a single Flow Record. 177 The "Reducing Redundancy in IP Flow Information Export 178 (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] 179 specifies a bandwidth saving method for exporting Flow or 180 packet information, by separating information common to 181 several Flow Records from information specific to an 182 individual Flow Record: common Flow information is exported 183 only once. 185 2. Introduction 187 Today service providers and network administrators are 188 looking for visibility into the packet content rather than 189 just the packet header. Some network devices Metering 190 Processes inspect the packet content and identify the 191 applications that are utilizing the network traffic. 192 Applications in this context are defined as networking 193 protocols used by networking processes that exchange 194 packets between them (such as web applications, peer to 195 peer applications, file transfer, e-mail applications, 196 etc.). Applications can be further characterized by other 197 criteria, some of which are application specific. 198 Examples include: web application to a specific domain, per 199 user specific traffic, a video application with a specific 200 codec, etc... 202 The application identification is based on several 203 different methods or even a combination of methods: 204 1. L2 (Layer 2) protocols (such as ARP (Address Resolution 205 Protocol), PPP (Point-to-Point Protocol), LLDP (Link 206 Layer Discovery Protocol)) 207 2. IP protocols (such as ICMP (Internet Control Message 208 Protocol), IGMP (Internet Group Management Protocol), 209 GRE (Generic Routing Encapsulation) 210 3. TCP or UDP ports (such as HTTP, Telnet, FTP) 211 4. Application layer header (of the application to be 212 identified) 213 5. Packet data content 214 6. Packets and traffic behavior 215 The exact application identification methods are part of 216 the Metering Process internals that aim to provide an 217 accurate identification and minimize false identification. 218 This task requires a sophisticated Metering Process since 219 the protocols do not behave in a standard manner. 221 1. Applications use port obfuscation where the 222 application runs on different port than the IANA 223 assigned one. For example an HTTP server might 224 run a TCP port 23 (assigned to telnet in [IANA- 225 PORTS]) 227 2. IANA port registries do not accurately reflect how 228 certain ports are "commonly" used today. Some 229 ports are reserved, but the application either 230 never became prevalent or is not in use today. 232 3. The application behavior and identification logic 233 become more and more complex 235 For that reason, such Metering Processes usually detect 236 applications based on multiple mechanisms in parallel. 237 Detection based only on port matching might wrongly identify 238 the application. If the Metering Process is capable of 239 detecting applications more accurately, it is considered to 240 be stronger and more accurate. 242 Similarly, a reporting mechanism that uses L4 port based 243 applications only, such as L4:, would have 244 similar issues. The reporting system should be capable of 245 reporting the applications classified using all types of 246 mechanisms. In particular applications that do not have 247 any IANA port definition. While a mechanism to export 248 application information should be defined, the L4 port 249 being used must be exported using the destination port 250 (destinationTransportPort at [IANA-IPFIX]) in the 251 corresponding IPFIX record. 253 This document specifies the Cisco Systems application 254 information encoding (as described in section 4. ) to 255 export the application information with the IPFIX protocol 256 [RFC5101]. 258 Applications could be identified at different OSI layers, 259 from layer 2 to layer 7. For example: Link Layer 260 Distribution Protocol (LLDP) [LLDP] can be identified in 261 layer 2, ICMP can be identified in layer 3 [IANA-PROTO], 262 HTTP can be identified in layer 4 [IANA-PORTS], and Webex 263 can be identified in layer 7. 265 While an ideal solution would be an IANA registry for 266 applications above (or inside the payload of) the well- 267 known ports [IANA-PORTS], this solution is not always 268 possible. Indeed, the specifications for some applications 269 embedded in the payload are not available. Some reverse 270 engineering as well as a ubiquitous language for 271 application identification, would be required conditions to 272 be able to manage an IANA registry for these types of 273 applications. Clearly, these are blocking factors. 275 This document specifies the Cisco Systems application 276 information encoding. However, the layer 7 application 277 registry values are out of scope of this document. 279 2.1. Application Information Use Cases 281 There are several use cases for application information: 283 1. Application Visibility 285 This is one of the main cases for using the application 286 information. Network administrators are using 287 application visibility to understand the main network 288 consumers, network trends and user behavior. 290 2. Security Functions 292 Application knowledge is sometimes used in security 293 functions in order to provide comprehensive functions 294 such as Application based firewall, URL filtering, 295 parental control, intrusion detection, etc. 297 All of the above use cases require exporting application 298 information to provide the network function itself or to 299 log the network function operation. 301 3. Terminology 303 IPFIX-specific terminology used in this document is defined 304 in Section 2 of the IPFIX protocol specification [RFC5101]. 306 As in [RFC5101], these IPFIX-specific terms have the first 307 letter of a word capitalized when used in this document. 309 3.1. New Terminology 311 Application Id 313 A unique identifier for an application. 315 When an application is detected, the most granular 316 application is encoded in the Application Id. 318 4. applicationId Information Element Specification 320 This document specifies the applicationId Information 321 Element, which is a single field composed of two parts: 323 1. 8 bits of Classification Engine ID. The 324 Classification Engine can be considered as a 325 specific registry for application assignments. 326 2. m bits of Selector ID. The Selector ID length 327 varies depending on the Classification Engine ID. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Class. Eng. ID| Selector ID ... | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | ... | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 1: applicationId Information Element 339 Classification Engine ID 341 A unique identifier for the engine which determined the 342 Selector ID. Thus the Classification Engine ID defines 343 the context for the Selector ID. 345 Selector ID 347 A unique identifier of the application for a specific 348 Classification Engine ID. Note that the Selector ID 349 length varies depending on the Classification Engine 350 ID. 352 The Selector ID term is similar in concepts with the 353 selectorId Information Element, specified in the PSAMP 354 Protocol [RFC5476][RFC5477]. 356 4.1. Existing Classification Engine IDs 358 The following Classification Engine IDs have been 359 allocated: 361 Name Value Description 363 0 Invalid. 365 IANA-L3 1 The Assigned Internet Protocol 366 Number (layer 3 (L3)) is exported 367 in the Selector ID. 368 See [IANA-PROTO]. 370 PANA-L3 2 Proprietary layer 3 definition. 371 An enterprise can export its own 372 layer 3 protocol numbers. The 373 Selector ID has a global 374 significance for all devices from 375 the same enterprise. 377 IANA-L4 3 The IANA layer 4 (L4) well-known 378 port number is exported in the 379 Selector ID. See [IANA-PORTS]. 380 Note: as an IPFIX flow is 381 unidirectional, it contains the 382 destination port in a flow from 383 the client to the server. 385 PANA-L4 4 Proprietary layer 4 definition. 386 An enterprise can export its own 387 layer 4 port numbers. The 388 Selector ID has global 389 significance for devices from the 390 same enterprise. Example: IPFIX 391 had the port 4739 pre-assigned in 392 the IETF draft for years. While 393 waiting for the RFC and its 394 associated IANA registration, the 395 Selector ID 4739 was used with 396 this PANA-L4. 398 5 Reserved. 400 USER- 6 The Selector ID represents 401 Defined applications defined by the user 402 (using CLI, GUI, etc.) based on 403 the methods described in section 404 2. The Selector ID has a local 405 significance per device. 407 7 Reserved. 409 8 Reserved. 411 9 Reserved. 413 10 Reserved. 415 11 Reserved. 417 PANA-L2 12 Proprietary layer 2 (L2) 418 definition. An enterprise can 419 export its own layer 2 420 identifiers. The Selector ID 421 represents the enterprise's 422 unique global layer 2 423 applications. The Selector ID has 424 a global significance for all 425 devices from the same enterprise. 426 Examples include Cisco Subnetwork 427 Access Protocol (SNAP). 429 PANA-L7 13 Proprietary layer 7 definition. 430 The Selector ID represents the 431 enterprise's unique global ID for 432 the layer 7 applications. The 433 Selector ID has a global 434 significance for all devices from 435 the same enterprise. This 436 Classification Engine Id is used 437 when the application registry is 438 owned by the Exporter 439 manufacturer (referred to as the 440 "enterprise" in this document). 442 14 Reserved. 444 15 Reserved. 446 16 Reserved. 448 17 Reserved. 450 ETHERTYPE 18 The Selector ID represents the 451 well-known Ethertype. See 452 [ETHERTYPE]. Note that the 453 Ethertype is usually expressed in 454 hexadecimal. However, the 455 corresponding decimal value is 456 used in this Selector ID. 458 LLC 19 The Selector ID represents the 459 well-known IEEE 802.2 Link Layer 460 Control (LLC) Destination Service 461 Access Point (DSAP). See [LLC]. 462 Note that LLC DSAP is usually 463 expressed in hexadecimal. 464 However, the corresponding 465 decimal value is used in this 466 Selector ID. 468 PANA-L7- 20 Proprietary layer 7 definition, 469 PEN including a Private Enterprise 470 Number (PEN) [PEN] to identify 471 that the application registry 472 being used is not owned by the 473 Exporter manufacturer (referred 474 to as the "enterprise" in this 475 document, and identified by the 476 PEN), or to identify the original 477 enterprise in the case of a 478 mediator or 3rd party device. The 479 Selector ID represents the 480 enterprise unique global ID for 481 the layer 7 applications. The 482 Selector ID has a global 483 significance for all devices from 484 the same enterprise. 486 21 to 487 255 Available (255 is the maximum 488 Engine ID) 490 Table 1: Existing Classification Engine IDs 492 "PANA = Proprietary Assigned Number Authority". In other 493 words, an enterprise specific version of IANA for 494 internal IDs. 496 The PANA-L7 Classification Engine ID SHOULD be used when 497 the application registry is owned by the Exporter 498 manufacturer, referred to as the "enterprise" in this 499 document, and identified by the PEN. Even if the 500 application registry is owned by the Exporter 501 manufacturer, the PANA-L7-PEN MAY be used, specifying the 502 manufacturer. 503 The mechanism for the Collector to know about Exporter 504 PEN is out of scope of this document. Possible tracks 505 are: SNMP polling, an Options Template export, hardcoded 506 value, etc. 508 An Exporter may classify the application according to 509 another vendor's application registry. E.g., an IPFIX 510 Mediator [RFC6183] may need to re-export applications 511 received from different Exporters using different PANA-L7 512 application registries. For example, X's IPFIX Mediator 513 aggregates traffic from some Exporters which report 514 enterprise Y applications and other Exporters which 515 report enterprise Z applications. Or, X's device 516 implements enterprise Y's application classifications. 517 In these cases, the PANA-L7-PEN Classification Engine 518 MUST be used, which allows the original enterprise ID to 519 be reported. The ID of the enterprise which defined the 520 application ID is identified by the enterprise's PEN. An 521 example is displayed in section 6.6. 523 Note that the the PANA-L7 Classification Engine ID is 524 also used for resolving IANA L4 port Discrepancies (see 525 Section 4.4) 527 The list in table 1 is maintained by IANA thanks to the 528 registry within the classificationEngineId Information 529 Element. See the "IANA Considerations" section. The 530 Classification Engine Id is part of the Application Id 531 encoding, so the classificationEngineId Information 532 Element is currently not required by the specifications 533 in this document. However, this Information Element was 534 created for completeness, as it was anticipated that this 535 Information Element will be required in the future. 537 4.2. Selector ID Length per Classification IDs 539 As the Selector Id part of the Application Id is variable 540 based on the Classification Engine ID value, the 541 applicationId SHOULD be encoded in a variable-length 542 Information Element [RFC5101] for the IPFIX export. 544 The following table displays the Selector ID default 545 length for the different Classification Engine IDs. 547 Classification Selector ID default 548 Engine ID Name length (in bytes) 550 IANA-L3 1 552 PANA-L3 1 554 IANA-L4 2 556 PANA-L4 2 558 USER-Defined 3 560 PANA-L2 5 562 PANA-L7 3 564 ETHERTYPE 2 566 LLC 1 568 PANA-L7-PEN 3 (*) 570 Table 2: Selector ID default length 571 per Classification Engine ID 573 (*) There is an extra 4 bytes for the PEN. However, the PEN 574 is not considered part of the Selector ID. 576 If a legacy protocol such as NetFlow version 9 [RFC3954] is 577 used, and this protocol doesn't support variable length 578 Information Elements, then either multiple Template Records 579 (one per applicationId length), or a single Template Record 580 corresponding to the maximum sized applicationId MUST be 581 used. 583 Application Ids MAY be encoded in a smaller number of 584 bytes, following the same rules as for the IPFIX Reduced 585 Size Encoding [RFC5101]. 587 Application Ids MAY be encoded with a larger length. 588 For example, a normal IANA L3 protocol encoding would take 589 2 bytes since the Selector ID represents the protocol field 590 from the IP header encoded in one byte. However, an IANA 591 L3 protocol encoding may be encoded with 3 bytes. In this 592 case, the Selector ID value MUST always be encoded in the 593 least significant bits as shown in Figure 2. 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |Class. Eng. ID |zero-valued upper-bits ... Selector ID | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 2: Selector ID encoding 603 4.3. Application Name Options Template Record 605 For Classification Engines which specify locally unique 606 Application Ids (which means unique per engine and per 607 router), an Options Template Record (see [RFC5101]) MUST 608 be used to export the correspondence between the 609 Application Id, the Application Name, and the Application 610 Description. 612 For Classification Engines which specify globally unique 613 Application Ids, an Options Template Record MAY be used 614 to export the correspondence between the Application Id, 615 the Application Name and the Application Description, 616 unless the mapping is hardcoded in the Collector, or 617 known out of band (for example, by polling a MIB). 619 An example Options Template is shown in section 6.8. 621 Enterprises may assign company-wide Application Id values 622 for the PANA-L7 Classification Engine. In this case, a 623 possible optimization for the Collector is to keep the 624 mappings between the Application Ids and the Application 625 Names per enterprise, as opposed to per Exporter. 627 4.4. Resolving IANA L4 Port Discrepancies 629 Even though the IANA L4 ports usually point to the same 630 protocols for both UDP, TCP or other transport types, there 631 are some exceptions, as mentioned in the Appendix B. 633 Instead of imposing the transport protocol 634 (UDP/TCP/SCTP/etc.) in the scope of the "Application Name 635 Options Template Record" (section 6.8. ) for all 636 applications (on top of having the transport protocol as 637 key-field in the Flow Record definition), the convention is 638 that the L4 application is always TCP related. So, 639 whenever the Collector has a conflict in looking up IANA, 640 it would choose the TCP choice. As a result, the UDP L4 641 applications from Table 3 and the SCTP L4 applications from 642 Table 4 are assigned in the PANA_L7 Application Id range, 643 i.e. under Classification Engine ID 13. 645 Currently, there are no discrepancies between the well 646 known ports for TCP and DCCP. 648 5. Grouping the Applications with the Attributes 650 Due to the high number of different Application Ids, 651 Application Ids MAY be categorized into groups. This offers 652 the benefits of easier reporting and action, such as QoS 653 policies. Indeed, most applications with the same 654 characteristics should be treated the same way; for example, 655 all video traffic. 657 Attributes are statically assigned per Application Id and are 658 independent of the traffic. The attributes are listed below: 660 Name Description 662 Category An attribute that provides a first 663 level categorization for each 664 Application Id. Examples include: 666 browsing, email, file-sharing, 667 gaming, instant messaging, voice- 668 and-video, etc... 669 The category attribute is encoded by 670 the ApplicationCategoryName 671 Information Element. 673 Sub-Category An attribute that provides a second 674 level categorization for each 675 Application Id. Examples include: 676 backup-systems, client-server, 677 database, routing-protocol, etc... 678 The sub-category attribute is 679 encoded by the 680 ApplicationSubCategoryName 681 Information Element. 683 Application- An attribute that groups multiple 684 Group Application Ids that belong to the 685 same networking application. For 686 example, the ftp-group contain the 687 ftp-data (port 20), ftp (port 20), 688 ni-ftp (port 47), sftp (port 115), 689 bftp (port 152), ftp-agent(port 690 574), ftps-data (port 989). The 691 application-group attribute is 692 encoded by the ApplicationGroupName 693 Information Element. 695 P2P-Technology Specifies if the Application Id is 696 based on peer-to-peer technology. 697 The P2P-technology attribute is 698 encoded by the p2pTechnology 699 Information Element. 701 Tunnel- Specifies if the Application Id is 702 Technology used as a tunnel technology. The 703 tunnel-technology attribute is 704 encoded by the tunnelTechnology 705 Information Element. 707 Encrypted Specifies if the Application Id is 708 an encrypted networking protocol. 709 The encrypted attribute is encoded 710 by the encryptedTechnology 711 Information Element. 713 Table 3: Application Id Static Attributes 715 Every application is assigned to one 716 ApplicationCategoryName, one ApplicationSubCategoryName, 717 one ApplicationGroupName, has one p2pTechnology, one 718 tunnelTechnology, and one encryptedTechnology. These new 719 Information Elements are specified in the IANA 720 Consideration Section 7.1. 7.1. 722 Maintaining the attribute values in IANA seems impossible 723 to realize. Therefore the attribute values per application 724 are enterprise specific. 726 5.1. Options Template Record for the Attribute Values 728 An Options Template Record (see [RFC5101]) SHOULD be used 729 to export the correspondence between each Application Id 730 and its related Attribute values. An alternative way for 731 the Collecting Process to learn the correspondence is to 732 populate these mappings out of band, for example, by 733 loading a CSV file containing the correspondence table. 735 The Attributes Option Template contains the ApplicationId 736 as a scope field, followed by the ApplicationCategoryName, 737 the ApplicationSubCategoryName, the ApplicationGroupName, 738 the p2pTechnology, the tunnelTechnology, and the 739 encryptedTechnology Information Elements. 741 A list of attributes may conveniently be exported using a 742 subTemplateList per [RFC6313]. 744 An example is given in section 6.9. 746 6. Application Id Examples 748 The following examples are created solely for the purpose 749 of illustrating how the extensions proposed in this 750 document are encoded. 752 6.1. Example 1: Layer 2 Protocol 754 The list of Classification Engine IDs in Table 1 shows that 755 the layer 2 Classification Engine IDs are 12 (PANA-L2), 18, 756 (Ethertype) and 19 (LLC). 758 From the Ethertype list, LLDP [LLDP] has the Selector ID 759 value 0x88CC, so 35020 in decimal: 761 NAME Selector ID 762 LLDP 35020 764 So, in the case of LLDP, the Classification Engine ID is 18 765 (LLC) while the Selector ID has the value 35020. 767 Per section 4. , the applicationId Information Element, 768 is a single field composed of 8 bits of Classification 769 Engine ID, followed by m bits of Selector ID. 771 Therefore the Application Id is encoded as: 773 0 1 2 774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | 18 | 35020 | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 So the Application Id has the decimal value of 1214668. 780 The format '18..35020' is used for simplicity in the 781 examples below, to clearly express that two components of 782 the Application ID. 784 The Exporting Process creates a Template Record with a few 785 Information Elements: amongst other things, the Application 786 Id. For example: 788 - applicationId (key field) 789 - octetTotalCount (non key field) 791 For example, a Flow Record corresponding to the above 792 Template Record may contain: 794 { applicationId='18..35020', 795 octetTotalCount=123456 } 797 The Collector has all the required information to determine 798 that the application is LLDP, because the Application Id 799 uses a global and well known registry, i.e. the Ethertype. 800 The Collector can determine which application is 801 represented by the Application Id by loading the registry 802 out of band. 804 6.2. Example 2: Standardized IANA Layer 3 Protocol 806 From the list of Classification Engine IDs in Table 1, the 807 IANA layer 3 Classification Engine ID (IANA-L3) is 1. 809 From the list of IANA layer 3 protocols (see [IANA-PROTO]), 810 ICMP has the value 1: 812 Decimal Keyword Protocol Reference 813 1 ICMP Internet Control [RFC792] 814 Message 816 So in the case of the standardized IANA layer 3 protocol 817 ICMP, the Classification Engine ID is 1, and the Selector 818 ID has the value of 1. 820 Therefore the Application Id is encoded as: 822 0 1 823 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | 1 | 1 | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 So the Application Id has the value of 257. The format 829 '1..1' is used for simplicity in the examples below. 831 The Exporting Process creates a Template Record with a few 832 Information Elements: amongst other things, the Application 833 Id. For example: 835 - sourceIPv4Address (key field) 836 - destinationIPv4Address (key field) 837 - ipDiffServCodePoint (key field) 838 - applicationId (key field) 839 - octetTotalCount (non key field) 840 For example, a Flow Record corresponding to the above 841 Template Record may contain: 843 { sourceIPv4Address=192.0.2.1, 844 destinationIPv4Address=192.0.2.2, 845 ipDiffServCodePoint=0, 846 applicationId='1..1', 847 octetTotalCount=123456 } 849 The Collector has all the required information to determine 850 that the application is ICMP, because the Application Id 851 uses a global and well know registry, ie the IANA L3 852 protocol number. 854 6.3. Example 3: Proprietary Layer 3 Protocol 856 Assume that a enterprise has specified a new layer 3 857 protocol called "foo". 859 From the list of Classification Engine IDs in Table 1, the 860 proprietary layer 3 Classification Engine ID (PANA-L3) is 861 2. 863 A global registry within the enterprise specifies that the 864 "foo" protocol has the value 90: 866 Protocol Protocol Id 867 foo 90 869 So, in the case of the layer 3 protocol foo specified by 870 this enterprise, the Classification Engine ID is 2, and the 871 Selector ID has the value of 90. 873 Therefore the Application Id is encoded as: 875 0 1 876 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | 2 | 90 | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 So the Application Id has the value of 602. The format 882 '2..90' is used for simplicity in the examples below. 884 The Exporting Process creates a Template Record with a few 885 Information Elements: amongst other things, the Application 886 Id. For example: 888 - sourceIPv4Address (key field) 889 - destinationIPv4Address (key field) 890 - ipDiffServCodePoint (key field) 891 - applicationId (key field) 892 - octetTotalCount (non key field) 894 For example, a Flow Record corresponding to the above 895 Template Record may contain: 897 { sourceIPv4Address=192.0.2.1, 898 destinationIPv4Address=192.0.2.2, 899 ipDiffServCodePoint=0, 900 applicationId='2..90', 901 octetTotalCount=123456 } 903 Along with this Flow Record, a new Options Template Record 904 would be exported, as shown in Section 6.8. 906 6.4. Example 4: Standardized IANA Layer 4 Port 908 From the list of Classification Engine IDs in Table 1, the 909 IANA layer 4 Classification Engine ID (PANA-L3) is 3. 911 From the list of IANA layer 4 ports (see [IANA-PORTS]), 912 SNMP has the value 161: 914 Keyword Decimal Description 915 snmp 161/tcp SNMP 916 snmp 161/udp SNMP 918 So in the case of the standardized IANA layer 4 SNMP port, 919 the Classification Engine ID is 3, and the Selector ID has 920 the value of 161. 922 Therefore the Application Id is encoded as: 924 0 1 925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | 3 | 161 | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 So the Application Id has the value of 196769. The format 931 '3..161' is used for simplicity in the examples below. 933 The Exporting Process creates a Template Record with a few 934 Information Elements: amongst other things, the Application 935 Id. For example: 937 - sourceIPv4Address (key field) 938 - destinationIPv4Address (key field) 939 - protocol (key field) 940 - ipDiffServCodePoint (key field) 941 - applicationId (key field) 942 - octetTotalCount (non key field) 944 For example, a Flow Record corresponding to the above 945 Template Record may contain: 947 { sourceIPv4Address=192.0.2.1, 948 destinationIPv4Address=192.0.2.2, 949 protocol=17, ipDiffServCodePoint=0, 950 applicationId='3..161', 951 octetTotalCount=123456 } 953 The Collector has all the required information to determine 954 that the application is SNMP, because the Application Id 955 uses a global and well know registry, ie the IANA L4 956 protocol number. 958 6.5. Example 5: Layer 7 Application 960 In this example, the Metering Process has observed some 961 Webex traffic. 963 From the list of Classification Engine IDs in Table 1, the 964 layer 7 unique Classification Engine ID (PANA-L7) is 13. 966 Suppose that the Metering Process returns the ID 10000 for 967 Webex traffic. 969 So, in the case of this Webex application, the 970 Classification Engine ID is 13 and the Selector ID has the 971 value of 10000. 973 Therefore the Application Id is encoded as: 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | 13 | 10000 | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 So the Application Id has the value of 218113808. The 982 format '13..10000' is used for simplicity in the examples 983 below. 985 The Exporting Process creates a Template Record with a few 986 Information Elements: amongst other things, the Application 987 Id. For example: 989 - sourceIPv4Address (key field) 990 - destinationIPv4Address (key field) 991 - ipDiffServCodePoint (key field) 992 - applicationId (key field) 993 - octetTotalCount (non key field) 995 For example, a Flow Record corresponding to the above 996 Template Record may contain: 998 { sourceIPv4Address=192.0.2.1, 999 destinationIPv4Address=192.0.2.2, 1000 ipDiffServCodePoint=0, 1001 applicationId='13..10000', 1002 octetTotalCount=123456 } 1004 The 10000 value is globally unique for the enterprise, so 1005 that the Collector can determine which application is 1006 represented by the Application Id by loading the registry 1007 out of band. 1009 Along with this Flow Record, a new Options Template Record 1010 would be exported, as shown in Section 6.8. 1012 6.6. Example 6: Layer 7 Application with Private Enterprise 1013 Number (PEN) 1015 In this example, the layer 7 Webex traffic from Example 5 1016 above have been classified by enterprise X. The exported 1017 records have been received by enterprise Y's mediation 1018 device, which wishes to forward them to a top level 1019 Collector. 1021 In order for the top level Collector to know that the 1022 records were classified by enterprise X, the enterprise Y 1023 mediation device must report the records using the 1024 PANA-L7-PEN Classification Engine ID with enterprise X's 1025 Private Enterprise Number. 1027 The PANA-L7-PEN Classification Engine ID is 20, and 1028 enterprise X's Selector ID for Webex traffic has the value 1029 of 10000. 1031 Therefore the Application Id is encoded as: 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | 20 | enterprise ID = X ...| 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 |...Ent.ID.contd| 10000 | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 The format '20..X..10000' is used for simplicity in the 1042 examples below. 1044 The Exporting Process creates a Template Record with a few 1045 Information Elements: amongst other things, the Application 1046 Id. For example: 1048 - sourceIPv4Address (key field) 1049 - destinationIPv4Address (key field) 1050 - ipDiffServCodePoint (key field) 1051 - applicationId (key field) 1052 - octetTotalCount (non key field) 1054 For example, a Flow Record corresponding to the above 1055 Template Record may contain: 1057 { sourceIPv4Address=192.0.2.1, 1058 destinationIPv4Address=192.0.2.2, 1059 ipDiffServCodePoint=0, 1060 applicationId='20..X..10000', 1061 octetTotalCount=123456 } 1063 The 10000 value is globally unique for enterprise X, so 1064 that the Collector can determine which application is 1065 represented by the Application Id by loading the registry 1066 out of band. 1068 Along with this Flow Record, a new Options Template Record 1069 would be exported, as shown in Section 6.8. 1071 6.7. Example: port Obfuscation 1073 For example, an HTTP server might run on a TCP port 23 1074 (assigned to telnet in [IANA-PORTS]). If the Metering 1075 Process is capable of detecting HTTP in the same case, the 1076 Application Id representation must contain HTTP. However, 1077 if the reporting application wants to determine whether the 1078 default HTTP port 80 or 8080 was used, the destination port 1079 (destinationTransportPort at [IANA-IPFIX]) must also be 1080 exported in the corresponding IPFIX record. 1082 In the case of a standardized IANA layer 4 port, the 1083 Classification Engine ID (PANA-L4) is 3, and the Selector 1084 ID has the value of 80 for HTTP (see [IANA-PORTS]). 1085 Therefore the Application Id is encoded as: 1087 0 1 2 1088 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | 3 | 80 | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 The Exporting Process creates a Template Record with a few 1094 Information Elements: amongst other things, the Application 1095 Id. For example: 1097 - sourceIPv4Address (key field) 1098 - destinationIPv4Address (key field) 1099 - protocol (key field) 1100 - destinationTransportPort (key field) 1101 - applicationId (key field) 1102 - octetTotalCount (non key field) 1104 For example, a Flow Record corresponding to the above 1105 Template Record may contain: 1107 { sourceIPv4Address=192.0.2.1, 1108 destinationIPv4Address=192.0.2.2, 1109 protocol=17, 1110 destinationTransportPort=23, 1111 applicationId='3..80', 1112 octetTotalCount=123456 } 1114 The Collector has all the required information to determine 1115 that the application is HTTP, but runs on port 23. 1117 6.8. Example: Application Name Mapping Options Template 1119 Along with the Flow Records shown in the above examples, a 1120 new Options Template Record should be exported to express 1121 the Application Name and Application Description associated 1122 with each Application Id. 1124 The Options Template Record contains the following 1125 Information Elements: 1127 1. Scope = applicationId. 1129 From RFC 5101: "The scope, which is only available 1130 in the Options Template Set, gives the context of 1131 the reported Information Elements in the Data 1132 Records." 1134 2. applicationName. 1136 3. applicationDescription. 1138 The Options Data Record associated with the examples above 1139 would contain, for example: 1141 { scope=applicationId='2..90', 1142 applicationName="foo", 1143 applicationDescription="The foo protocol", 1145 scope=applicationId='13..10000', 1146 applicationName="webex", 1147 applicationDescription="Webex application" } 1149 scope=applicationId='20..X..10000', 1150 applicationName="webex", 1151 applicationDescription="Webex application" } 1153 When combined with the example Flow Records above, these 1154 Options Template Records tell the Collector: 1156 1. A flow of 123456 bytes exists from sourceIPv4Address 1157 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1158 applicationId of '12..90', which maps to the "foo" 1159 application. 1161 2. A flow of 123456 bytes exists from sourceIPv4Address 1162 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1163 Application Id of '13..10000', which maps to the "Webex" 1164 application. 1166 3. A flow of 123456 bytes exists from sourceIPv4Address 1167 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1168 Application Id of '20..PEN..10000', which maps to the 1169 "Webex" application, according to the application registry 1170 from the entrerprise X. 1172 6.9. Example: Attributes Values Options Template Record 1174 Along with the Flow Records shown in the above examples, a 1175 new Options Template Record is exported to express the 1176 values of the different attributes related to the 1177 Application Ids. 1179 The Options Template Record would contain the following 1180 Information Elements: 1182 1. Scope = applicationId. 1184 From RFC 5101: "The scope, which is only available 1185 in the Options Template Set, gives the context of 1186 the reported Information Elements in the Data 1187 Records." 1189 2. applicationCategoryName. 1191 3. applicationSubCategoryName. 1193 4. applicationGroupName 1195 5. p2pTechnology 1197 6. tunnelTechnology 1199 7. encryptedTechnology 1201 The Options Data Record associated with the examples above 1202 would contain, for example: 1204 { scope=applicationId='2..90', 1205 applicationCategoryName="foo-category", 1206 applicationSubCategoryName="foo-subcategory", 1207 applicationGroupName="foo-group", 1208 p2pTechnology=NO 1209 tunnelTechnology=YES 1210 encryptedTechnology=NO 1212 When combined with the example Flow Records above, these 1213 Options Template Records tell the Collector: 1215 A flow of 123456 bytes exists from sourceIPv4Address 1216 192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP 1217 value of 0 and an applicationId of '12..90', which maps to 1218 the "foo" application. This application can be 1219 characterized by the relevant attributes values. 1221 7. IANA Considerations 1223 7.1. New Information Elements 1225 This document specifies 10 new IPFIX Information Elements: 1226 the applicationDescription, applicationId, applicationName, 1227 classificationEngineId, applicationCategoryName, 1228 applicationSubCategoryName, applicationGroupName, 1229 p2pTechnology, tunnelTechnology, and encryptedTechnology. 1231 New Information Elements to be added to the IPFIX Information 1232 Element registry at [IANA-IPFIX] are listed below. 1234 EDITOR'S NOTE: RFC5102, which explains the IANA 1235 considerations for assigning new Information Elements 1236 mentions. "The value of these identifiers is in the range of 1237 1-32767. Within this range, Information Element identifier 1238 values in the sub-range of 1-127 are compatible with field 1239 types used by NetFlow version 9 [RFC3954].". This is the 1240 reason why some Information Elements have already an assigned 1241 ElementId in the range 1-127, instead of . These 1242 Information Elements should anyway follow the IANA 1243 Considerations from RFC5102, i.e. " New assignments for IPFIX 1244 Information Elements will be administered by IANA through 1245 Expert Review review". The reviewer is Nevil Brownlee. 1247 EDITOR'S NOTE: the XML specification in Appendix A must be 1248 updated with the elementID values allocated below. 1250 RFC-EDITOR/IANA-EDITOR: some entries are already present in 1251 IPFIX-IANA. However, those must be updated with the current 1252 content. 1254 7.1.1. applicationDescription 1256 Name: applicationDescription 1257 Description: 1258 Specifies the description of an application. 1259 Abstract Data Type: string 1260 Data Type Semantics: 1261 ElementId: 94 1262 Status: current 1264 7.1.2. applicationId 1266 Name: applicationId 1267 Description: 1268 Specifies an Application Id. 1269 Abstract Data Type: octetArray 1270 Data Type Semantics: identifier 1271 Reference: See section 4. of [EDITORS NOTE: this document] 1272 for the applicationId Information Element Specification. 1273 ElementId: 95 1274 Status: current 1276 7.1.3. applicationName 1278 Name: applicationName 1279 Description: 1280 Specifies the name of an application. 1281 Abstract Data Type: string 1282 Data Type Semantics: 1283 ElementId: 96 1284 Status: current 1286 7.1.4. classificationEngineId 1288 Name: classificationEngineId 1289 Description: 1291 A unique identifier for the engine which determined the 1292 Selector ID. Thus the Classification Engine ID defines 1293 the context for the Selector ID. The Classification 1294 Engine can be considered as a specific registry for 1295 application assignments. 1297 Initial values for this field are listed below. Further 1298 values may be assigned by IANA in the Classification 1299 Engine Ids registry. 1301 0 Invalid. 1303 1 IANA-L3: The Assigned Internet Protocol Number 1304 (layer 3 (L3)) is exported in the Selector ID. See 1305 http://www.iana.org/assignments/protocol-numbers. 1307 2 PANA-L3: Proprietary layer 3 definition. An 1308 enterprise can export its own layer 3 protocol 1309 numbers. The Selector ID has a global significance 1310 for all devices from the same enterprise. 1312 3 IANA-L4: The IANA layer 4 (L4) well-known port 1313 number is exported in the Selector ID. See [IANA- 1314 PORTS]. Note: as an IPFIX flow is unidirectional, 1315 it contains the destination port in a flow from 1316 the client to the server. 1318 4 PANA-L4: Proprietary layer 4 definition. An 1319 enterprise can export its own layer 4 port 1320 numbers. The Selector ID has global significance 1321 for devices from the same enterprise. Example: 1322 IPFIX had the port 4739 pre-assigned in the IETF 1323 draft for years. While waiting for the RFC and its 1324 associated IANA registration, the Selector ID 4739 1325 was used with this PANA-L4. 1327 5 Reserved 1329 6 USER-Defined: The Selector ID represents 1330 applications defined by the user (using CLI, GUI, 1331 etc.) based on the methods described in section 2. 1332 The Selector ID has a local significance per 1333 device. 1335 7 Reserved 1337 8 Reserved 1338 9 Reserved 1340 10 Reserved 1342 11 Reserved 1344 12 PANA-L2: Proprietary layer 2 (L2) definition. An 1345 enterprise can export its own layer 2 identifiers. 1346 The Selector ID represents the enterprise's unique 1347 global layer 2 applications. The Selector ID has a 1348 global significance for all devices from the same 1349 enterprise. Examples include Cisco Subnetwork 1350 Access Protocol (SNAP). 1352 13 PANA-L7: Proprietary layer 7 definition. The 1353 Selector ID represents the enterprise's unique 1354 global ID for the layer 7 applications. The 1355 Selector ID has a global significance for all 1356 devices from the same enterprise. This 1357 Classification Engine Id is used when the 1358 application registry is owned by the Exporter 1359 manufacturer (referred to as the "enterprise" in 1360 this document). 1362 14 Reserved 1364 15 Reserved 1366 16 Reserved 1368 17 Reserved 1370 18 ETHERTYPE: The Selector ID represents the well- 1371 known Ethertype. See [ETHERTYPE]. Note that the 1372 Ethertype is usually expressed in hexadecimal. 1373 However, the corresponding decimal value is used 1374 in this Selector ID. 1376 19 LLC: The Selector ID represents the well-known 1377 IEEE 802.2 Link Layer Control (LLC) Destination 1378 Service Access Point (DSAP). See [LLC]. Note that 1379 LLC DSAP is usually expressed in hexadecimal. 1380 However, the corresponding decimal value is used 1381 in this Selector ID. 1383 20 PANA-L7-PEN: Proprietary layer 7 definition, 1384 including a Private Enterprise Number (PEN) [PEN] 1385 to identify that the application registry being 1386 used is not owned by the Exporter manufacturer 1387 (referred to as the "enterprise" in this document, 1388 and identified by the PEN), or to identify the 1389 original enterprise in the case of a mediator or 1390 3rd party device. The Selector ID represents the 1391 enterprise unique global ID for the layer 7 1392 applications. The Selector ID has a global 1393 significance for all devices from the same 1394 enterprise. 1396 Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17), 1397 are reserved to be compliant with existing 1398 implementations already using the 1399 classificationEngineId. 1401 Abstract Data Type: unsigned8 1402 Data Type Semantics: identifier 1403 ElementId: 101 1404 Status: current 1406 7.1.5. applicationCategoryName 1408 Name: applicationCategoryName 1409 Description: 1410 An attribute that provides a first level categorization for 1411 each Application Id. 1412 Abstract Data Type: string 1413 Data Type Semantics: 1414 ElementId: 1415 Status: current 1417 7.1.6. applicationSubCategoryName 1419 Name: applicationSubCategoryName 1420 Description: 1421 An attribute that provides a second level categorization 1422 for each Application Id. 1423 Abstract Data Type: string 1424 Data Type Semantics: 1425 ElementId: 1426 Status: current 1428 7.1.7. applicationGroupName 1430 Name: applicationGroupName 1431 Description: 1432 An attribute that groups multiple Application Ids that 1433 belong to the same networking application. 1434 Abstract Data Type: string 1435 Data Type Semantics: 1436 ElementId: 1437 Status: current 1439 7.1.8. p2pTechnology 1441 Name: p2pTechnology 1442 Description: 1443 Specifies if the Application Id is based on peer-to-peer 1444 technology. Possible values are: { "yes", "y", 1 }, 1445 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1446 Abstract Data Type: string 1447 Data Type Semantics: 1448 ElementId: 288 1449 Status: current 1451 7.1.9. tunnelTechnology 1453 Name: tunnelTechnology 1454 Description: 1455 Specifies if the Application Id is used as a tunnel 1456 technology. 1457 Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } 1458 and 1459 { "unassigned" , "u", 0 }. 1460 Abstract Data Type: string 1461 Data Type Semantics: 1462 ElementId: 289 1463 Status: current 1465 7.1.10. encryptedTechnology 1467 Name: encryptedTechnology 1468 Description: 1469 Specifies if the Application Id is an encrypted networking 1470 protocol. Possible values are: { "yes", "y", 1 }, 1471 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1472 Abstract Data Type: string 1473 Data Type Semantics: 1474 ElementId: 290 1475 Status: current 1477 7.2. Classification Engine Ids Registry 1479 The Information Element #101, named classificationEngineId, 1480 carries information about the context for the Selector ID, 1481 and can be considered as a specific registry for application 1482 assignments. For ensuring extensibility of this information, 1483 IANA has created a new registry for Classification Engine Ids 1484 and filled it with the initial list from the description 1485 Information Element #101, classificationEngineId. 1487 New assignments for Classification Engine Ids will be 1488 administered by IANA through Expert Review [RFC5226], i.e., 1489 review by one of a group of experts designated by an IETF 1490 Area Director. The group of experts must double check the 1491 new definitions with already defined Classification Engine 1492 Ids for completeness, accuracy, and redundancy. The 1493 specification of Classification Engine Ids MUST be published 1494 using a well-established and persistent publication medium. 1496 RFC-EDITOR: this should be assigned similarly to 1497 mplsTopLabelType subregistry at 1498 http://www.iana.org/assignments/ipfix/ipfix.xml 1500 8. Security Considerations 1502 The same security considerations as for the IPFIX Protocol 1503 [RFC5101] apply. 1505 As mentioned in Section 2.1. , the application knowledge is 1506 useful in security based applications. Security applications 1507 may impose supplementary requirements on the export of 1508 application information, and these need to be examined on a 1509 case by case basis. 1511 9. References 1513 9.1. Normative References 1515 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1516 Requirement Levels, BCP 14, RFC 2119, March 1997. 1518 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 1519 Information Export (IPFIX) Protocol for the 1520 Exchange of IP Traffic Flow Information", RFC 5101, 1521 January 2008. 1523 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., 1524 and J. Meyer, "Information Model for IP Flow 1525 Information Export", RFC 5102, January 2008. 1527 [RFC5226] Narten, T., and H. Alverstrand, "Guidelines for 1528 Writing an IANA Considerations Section in RFCs", 1529 RFC 5226, May 2008 1531 [ETHERTYPE] 1532 http://standards.ieee.org/develop/regauth/ethertype 1533 /eth.txt 1535 [IANA-PORTS] http://www.iana.org/assignments/port-numbers 1537 [IANA-PROTO] http://www.iana.org/assignments/protocol- 1538 numbers 1540 [LLC] 1541 http://standards.ieee.org/develop/regauth/llc/publi 1542 c.html. 1544 [PEN] http://www.iana.org/assignments/enterprise-numbers 1546 9.2. Informative References 1548 [RFC792] J. Postel, Internet Control Message Protocol, RFC 1549 792, September 1981. 1551 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. 1552 Zander, Requirements for IP Flow Information 1553 Export, RFC 3917, October 2004. 1555 [RFC3954] B. Claise, "Cisco Systems NetFlow Services Export 1556 Version 9", RFC 3954, October 2004. 1558 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 1559 Export Using IP Flow Information Export (IPFIX)", 1560 RFC 5103, January 2008. 1562 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 1563 Quittek, "Architecture for IP Flow Information 1564 Export", RFC 5470, March 2009. 1566 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, 1567 "Guidelines for IP Flow Information Export (IPFIX) 1568 Testing", RFC 5471, March 2009. 1570 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 1571 Redundancy in IP Flow Information Export (IPFIX) 1572 and Packet Sampling (PSAMP) Reports", RFC 5473, 1573 March 2009. 1575 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) 1576 Protocol Specifications", RFC 5476, March 2009. 1578 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dresslet F., 1579 and G. Carle, "Information Model for Packet 1580 Sampling Exports", RFC 5477, March 2009. 1582 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. 1583 Ishibashi, "IP Flow Information Export (IPFIX) 1584 Mediation: Framework", RFC6183, April 2011 1586 [RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S. 1587 Yates, "Export of Structured Data in IP Flow 1588 Information Export (IPFIX)", RFC6313, July 2011 1590 [LLDP] "IEEE Std 802.1AB-2005, Standard for Local and 1591 metropolitan area networks - Station and Media 1592 Access Control Connectivity Discovery", IEEE Std 1593 802.1AB-2005 IEEE Std, 2005. 1595 [IANA-IPFIX] 1596 http://www.iana.org/assignments/ipfix/ipfix.xml 1598 [CISCO-APPLICATION-REGISTRY] 1599 http://www.cisco.com/go/application_registry 1601 10. Acknowledgement 1603 The authors would like to thank their many colleagues across 1604 Cisco Systems who made this work possible. Specifically 1605 Patrick Wildi for his time and expertise. 1607 11. Authors' Addresses 1609 Benoit Claise 1610 Cisco Systems, Inc. 1611 De Kleetlaan 6a b1 1612 Diegem 1813 1613 Belgium 1615 Phone: +32 2 704 5622 1616 EMail: bclaise@cisco.com 1618 Paul Aitken 1619 Cisco Systems, Inc. 1620 96 Commercial Quay 1621 Commercial Street 1622 Edinburgh, EH6 6LX, United Kingdom 1624 Phone: +44 131 561 3616 1625 EMail: paitken@cisco.com 1627 Nir Ben-Dvora 1628 Cisco Systems, Inc. 1629 32 HaMelacha St., 1630 P.O.Box 8735, I.Z.Sapir 1631 South Netanya, 42504 1632 Israel 1634 Phone: +972 9 892 7187 1635 EMail: nirbd@cisco.com 1637 Appendix A. Additions to XML Specification of IPFIX 1638 Information Elements (non normative) 1640 This appendix A contains additions to the machine-readable 1641 description of the IPFIX information model coded in XML in 1642 Appendix A and Appendix B in [RFC5102]. Note that this 1643 appendix is of informational nature, while the text in 1644 Section 7. (generated from this appendix) is normative. 1646 The following field definitions are appended to the IPFIX 1647 information model in Appendix A of [RFC5102]. 1649 1654 1655 1656 Specifies the description of an application. 1657 1658 1659 1661 1667 1668 1669 Specifies an Application Id. 1670 1671 1672 1673 1674 See section 4. of [EDITORS NOTE: this document] 1675 for the applicationId Information Element 1676 Specification. 1677 1678 1679 1681 1686 1687 1688 Specifies the name of an application. 1689 1690 1691 1693 1699 1700 1701 0 Invalid. 1703 1 IANA-L3: The Assigned Internet Protocol Number 1704 (layer 3 (L3)) is exported in the Selector ID. 1705 See http://www.iana.org/assignments/protocol- 1706 numbers. 1708 2 PANA-L3: Proprietary layer 3 definition. An 1709 enterprise can export its own layer 3 protocol 1710 numbers. The Selector ID has a global 1711 significance for all devices from the same 1712 enterprise. 1714 3 IANA-L4: The IANA layer 4 (L4) well-known port 1715 number is exported in the Selector ID. See 1716 [IANA-PORTS]. Note: as an IPFIX flow is 1717 unidirectional, it contains the destination 1718 port in a flow from the client to the server. 1720 4 PANA-L4: Proprietary layer 4 definition. An 1721 enterprise can export its own layer 4 port 1722 numbers. The Selector ID has global 1723 significance for devices from the same 1724 enterprise. Example: IPFIX had the port 4739 1725 pre-assigned in the IETF draft for years. 1726 While waiting for the RFC and its associated 1727 IANA registration, the Selector ID 4739 was 1728 used with this PANA-L4. 1730 5 Reserved 1732 6 USER-Defined: The Selector ID represents 1733 applications defined by the user (using CLI, 1734 GUI, etc.) based on the methods described in 1735 section 2. The Selector ID has a local 1736 significance per device. 1738 7 Reserved 1740 8 Reserved 1742 9 Reserved 1744 10 Reserved 1746 11 Reserved 1748 12 PANA-L2: Proprietary layer 2 (L2) definition. 1749 An enterprise can export its own layer 2 1750 identifiers. The Selector ID represents the 1751 enterprise's unique global layer 2 1752 applications. The Selector ID has a global 1753 significance for all devices from the same 1754 enterprise. Examples include Cisco Subnetwork 1755 Access Protocol (SNAP). 1757 13 PANA-L7: Proprietary layer 7 definition. The 1758 Selector ID represents the enterprise's unique 1759 global ID for the layer 7 applications. The 1760 Selector ID has a global significance for all 1761 devices from the same enterprise. This 1762 Classification Engine Id is used when the 1763 application registry is owned by the Exporter 1764 manufacturer (referred to as the "enterprise" 1765 in this document). 1767 14 Reserved 1769 15 Reserved 1771 16 Reserved 1773 17 Reserved 1775 18 ETHERTYPE: The Selector ID represents the 1776 well-known Ethertype. See [ETHERTYPE]. Note 1777 that the Ethertype is usually expressed in 1778 hexadecimal. However, the corresponding 1779 decimal value is used in this Selector ID. 1781 19 LLC: The Selector ID represents the well-known 1782 IEEE 802.2 Link Layer Control (LLC) 1783 Destination Service Access Point (DSAP). See 1784 [LLC]. Note that LLC DSAP is usually expressed 1785 in hexadecimal. However, the corresponding 1786 decimal value is used in this Selector ID. 1788 20 PANA-L7-PEN: Proprietary layer 7 definition, 1789 including a Private Enterprise Number (PEN) 1790 [PEN] to identify that the application 1791 registry being used is not owned by the 1792 Exporter manufacturer (referred to as the 1793 "enterprise" in this document, and identified 1794 by the PEN), or to identify the original 1795 enterprise in the case of a mediator or 3rd 1796 party device. The Selector ID represents the 1797 enterprise unique global ID for the layer 7 1798 applications. The Selector ID has a global 1799 significance for all devices from the same 1800 enterprise. 1801 1802 1803 1805 1811 1812 1813 An attribute that provides a first level 1814 categorization 1815 for each Application Id. 1816 1817 1818 1820 1826 1827 1828 An attribute that provides a second level 1829 categorization for each Application Id. 1830 1831 1832 1834 1840 1841 1842 An attribute that groups multiple Application Ids 1843 that belong to the same networking application. 1844 1845 1846 1848 1854 1855 1856 Specifies if the Application Id is based on peer- 1857 to-peer technology. Possible values are: 1858 { "yes", "y", 1 }, { "no", "n", 2 } and 1859 { "unassigned" , "u", 0 }. 1860 1861 1862 1864 1870 1871 1872 Specifies if the Application Id is used as a 1873 tunnel technology. Possible values are: 1874 { "yes", "y", 1 }, { "no", "n", 2 } and 1875 { "unassigned" , "u", 0 }. 1876 1877 1878 1880 1886 1887 1888 Specifies if the Application Id is an encrypted 1889 networking protocol. Possible values are: 1890 { "yes", "y", 1 }, { "no", "n", 2 } and 1891 { "unassigned" , "u", 0 }. 1892 1893 1894 1896 Appendix B. Port Collisions Tables (non normative) 1898 The following table lists the 10 ports that have different 1899 protocols assigned for TCP and UDP (at the time of writing 1900 this document): 1902 exec 512/tcp remote process execution; 1903 authentication performed 1904 using passwords and UNIX 1905 login names 1907 comsat/biff 512/udp used by mail system to 1908 notify users of new mail 1909 received; currently 1910 receives messages only from 1911 processes on the same 1912 machine 1914 login 513/tcp remote login a la 1915 telnet; automatic 1916 authentication 1917 performed based on 1918 priviledged port numbers 1919 and distributed data bases 1920 which identify 1922 "authentication domains" 1923 who 513/udp maintains data bases 1924 showing who's logged in to 1925 machines on a local 1926 net and the load average of 1927 the machine 1929 shell 514/tcp cmd 1930 like exec, but automatic 1931 authentication is performed 1932 as for login server 1934 syslog 514/udp 1936 oob-ws-https 664/tcp DMTF out-of-band secure web 1937 services management 1938 protocol 1939 Jim Davis 1941 1942 June 2007 1944 asf-secure-rmcp 664/udp ASF Secure Remote 1945 Management and Control 1946 Protocol 1948 rfile 750/tcp 1949 kerberos-iv 750/udp kerberos version iv 1951 submit 773/tcp 1952 notify 773/udp 1954 rpasswd 774/tcp 1955 acmaint_dbd 774/udp 1957 entomb 775/tcp 1958 acmaint_transd 775/udp 1960 busboy 998/tcp 1961 puparp 998/udp 1963 garcon 999/tcp 1964 applix 999/udp Applix ac 1966 Table 4: Different Protocols on UDP and TCP 1968 The following table lists the 19 ports that have different 1969 protocols assigned for TCP and SCTP (at the time of writing 1970 this document): 1972 # 3097/tcp Reserved 1974 itu-bicc-stc 3097/sctp ITU-T Q.1902.1/Q.2150.3 1975 Greg Sidebottom 1976 1978 # 5090/tcp 1980 car 5090/sctp Candidate AR 1982 # 5091/tcp 1984 cxtp 5091/sctp Context Transfer Protocol 1985 RFC 4065 - July 2005 1987 # 6704/tcp Reserved 1989 frc-hp 6704/sctp ForCES HP (High Priority) 1990 channel [RFC5811] 1992 # 6705/tcp Reserved 1994 frc-mp 6705/sctp ForCES MP (Medium 1995 Priority) channel 1996 [RFC5811] 1998 # 6706/tcp Reserved 1999 frc-lp 6706/sctp ForCES LP (Low priority) 2000 channel [RFC5811] 2002 # 9082/tcp 2004 lcs-ap 9082/sctp LCS Application Protocol 2005 Kimmo Kymalainen 2006 kimmo.kymalainen&etsi.org> 2007 04 June 2010 2009 # 9902/tcp 2011 enrp-sctp-tls 9902/sctp enrp/tls server channel 2012 [RFC5353] 2014 # 11997/tcp 2015 # 11998/tcp 2016 # 11999/tcp 2018 Wmereceiving 11997/sctp WorldMailExpress 2019 wmedistribution 11998/sctp WorldMailExpress 2020 wmereporting 11999/sctp WorldMailExpress 2021 Greg Foutz 2022 2023 March 2006 2025 # 25471/tcp 2027 rna 25471/sctp RNSAP User Adaptation for 2028 Iurh 2029 Dario S. Tonesi 2030 2031 07 February 2011 2033 # 29118/tcp Reserved 2035 sgsap 29118/sctp SGsAP in 3GPP 2037 # 29168/tcp Reserved 2039 sbcap 29168/sctp SBcAP in 3GPP 2041 # 29169/tcp 2042 iuhsctpassoc 29169/sctp HNBAP and RUA Common 2043 Association 2044 John Meredith 2045 2046 08 September 2009 2048 # 36412/tcp 2050 s1-control 36412/sctp S1-Control Plane (3GPP) 2051 KimmoKymalainen 2052 2053 01 September 2009 2055 # 36422/tcp 2057 x2-control 36422/sctp X2-Control Plane (3GPP) 2058 Kimmo Kymalainen 2059 2060 01 September 2009 2062 # 36443/tcp 2064 m2ap 36443/sctp M2 Application Part 2065 Dario S. Tonesi 2066 2067 07 February 2011 2069 # 36444/tcp 2071 m3ap 36444/sctp M3 Application Part 2072 Dario S. Tonesi 2073 2074 07 February 2011 2076 Table 5: Different Protocols on SCTP and TCP 2078 Appendix C. Application Registry Example (non normative) 2080 A reference to the Cisco Systems assigned numbers for the 2081 Application Id and the different attribute assignments can 2082 be found at [CISCO-APPLICATION-REGISTRY]. 2084 RFC-EDITOR NOTE: at the time of publication, if [CISCO- 2085 APPLICATION-REGISTRY] is not available, this appendix, and 2086 the [CISCO-APPLICATION-REGISTRY] reference must be removed.