idnits 2.17.1 draft-claise-export-application-info-in-ipfix-08.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 1985 has weird spacing: '...512/tcp rem...' == Line 1990 has weird spacing: '...512/udp use...' == Line 1997 has weird spacing: '...513/tcp rem...' == Line 2005 has weird spacing: '...513/udp mai...' == Line 2011 has weird spacing: '...514/tcp cmd...' == (2 more instances...) -- The document date (May 28, 2012) is 4351 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 2087, but not defined == Missing Reference: 'RFC5353' is mentioned on line 2099, 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: November 28, 2012 Cisco Systems, Inc. 6 May 28, 2012 8 Export of Application Information in IPFIX 9 draft-claise-export-application-info-in-ipfix-08 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full 14 conformance with the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by 23 other documents at any time. It is inappropriate to use 24 Internet-Drafts as reference material or to cite them other 25 than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be 31 accessed at http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 20, 2012. 35 2012 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as 40 the document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's 43 Legal Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the 45 date of publication of this document. Please review these 46 documents carefully, as they describe your rights and 47 restrictions with respect to this document. Code 48 Components extracted from this document must include 49 Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document specifies an extension to the IPFIX 56 information model specified in [RFC5102] to export 57 application information. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 62 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 63 and "OPTIONAL" in this document are to be interpreted as 64 described in RFC 2119 [RFC2119]. 66 2012 68 Table of Contents 70 1. Overview................................................4 71 1.1. IPFIX Documents Overview...........................4 72 2. Introduction............................................5 73 2.1. Application Information Use Cases.....................7 74 3. Terminology.............................................8 75 3.1. New Terminology....................................8 76 4. applicationId Information Element Specification.........8 77 4.1. Existing Classification Engine IDs.................9 78 4.2. Selector ID Length per Classification IDs.........13 79 4.3. Application Name Options Template Record..........15 80 4.4. Resolving IANA L4 Port Discrepancies..............15 81 5. Grouping the Applications with the Attributes..........16 82 5.1. Options Template Record for the Attribute Values..18 83 6. Application Id Examples................................18 84 6.1. Example 1: Layer 2 Protocol.......................18 85 6.2. Example 2: Standardized IANA Layer 3 Protocol.....19 86 6.3. Example 3: Proprietary Layer 3 Protocol...........21 87 6.4. Example 4: Standardized IANA Layer 4 Port.........22 88 6.5. Example 5: Layer 7 Application....................23 89 6.6. Example 6: Layer 7 Application with Private 90 Enterprise Number (PEN)................................24 91 6.7. Example: port Obfuscation.........................25 92 6.8. Example: Application Name Mapping Options 93 Template...............................................27 94 6.9. Example: Attributes Values Options Template 95 Record.................................................28 96 7. IANA Considerations....................................29 97 7.1. New Information Elements..........................29 98 7.1.1. applicationDescription..........................30 99 7.1.2. applicationId...................................30 100 7.1.3. applicationName.................................30 101 7.1.4. classificationEngineId..........................30 102 7.1.5. applicationCategoryName.........................33 103 7.1.6. applicationSubCategoryName......................33 104 7.1.7. applicationGroupName............................34 105 7.1.8. p2pTechnology...................................34 106 7.1.9. tunnelTechnology................................34 107 7.1.10. encryptedTechnology............................34 108 7.2. Classification Engine Ids Registry................35 109 8. Security Considerations................................35 110 9. References.............................................36 111 9.1. Normative References..............................36 112 9.2. Informative References............................36 114 2012 116 10. Acknowledgement.......................................38 117 11. Authors' Addresses....................................39 118 Appendix A. Additions to XML Specification of IPFIX 119 Information Elements (non normative)......................39 120 Appendix B. Port Collisions Tables (non normative).......45 121 Appendix C. Application Registry Example (non 122 normative)................................................50 124 List of Figures and Tables 126 Figure 1: applicationId Information Element ................ 8 127 Table 1: Existing Classification Engine IDs ............... 12 128 Table 2: Selector ID default length per Classification 129 Engine ID .............................................. 14 130 Table 3: Application Id Static Attributes ................. 17 131 Table 4: Different Protocols on UDP and TCP ............... 47 132 Table 5: Different Protocols on SCTP and TCP .............. 50 134 1. Overview 136 1.1. IPFIX Documents Overview 138 The IPFIX Protocol [RFC5101] provides network administrators 139 with access to IP Flow information. 141 The architecture for the export of measured IP Flow 142 information out of an IPFIX Exporting Process to a Collecting 143 Process is defined in the IPFIX Architecture [RFC5470], per 144 the requirements defined in RFC 3917 [RFC3917]. 146 The IPFIX Architecture [RFC5470] specifies how IPFIX Data 147 Records and Templates are carried via a congestion-aware 148 transport protocol from IPFIX Exporting Processes to IPFIX 149 Collecting Processes. 151 IPFIX has a formal description of IPFIX Information Elements, 152 their name, type and additional semantic information, as 153 specified in the IPFIX information model [RFC5102]. 155 2012 157 In order to gain a level of confidence in the IPFIX 158 implementation, probe the conformity and robustness, and 159 allow interoperability, the Guidelines for IPFIX Testing 160 [RFC5471] presents a list of tests for implementers of 161 compliant Exporting Processes and Collecting Processes. 163 The Bidirectional Flow Export [RFC5103] specifies a method 164 for exporting bidirectional flow (biflow) information using 165 the IP Flow Information Export (IPFIX) protocol, representing 166 each Biflow using a single Flow Record. 168 The "Reducing Redundancy in IP Flow Information Export 169 (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] 170 specifies a bandwidth saving method for exporting Flow or 171 packet information, by separating information common to 172 several Flow Records from information specific to an 173 individual Flow Record: common Flow information is exported 174 only once. 176 2. Introduction 178 Today service providers and network administrators are 179 looking for visibility into the packet content rather than 180 just the packet header. Some network devices Metering 181 Processes inspect the packet content and identify the 182 applications that are utilizing the network traffic. 183 Applications in this context are defined as networking 184 protocols used by networking processes that exchange 185 packets between them (such as web applications, peer to 186 peer applications, file transfer, e-mail applications, 187 etc.). Applications can be further characterized by other 188 criteria, some of which are application specific. 189 Examples include: web application to a specific domain, per 190 user specific traffic, a video application with a specific 191 codec, etc... 193 The application identification is based on several 194 different methods or even a combination of methods: 195 1. L2 (Layer 2) protocols (such as ARP (Address Resolution 196 Protocol), PPP (Point-to-Point Protocol), LLDP (Link 197 Layer Discovery Protocol)) 198 2. IP protocols (such as ICMP (Internet Control Message 199 Protocol), IGMP (Internet Group Management Protocol), 200 GRE (Generic Routing Encapsulation) 201 3. TCP or UDP ports (such as HTTP, Telnet, FTP) 203 2012 205 4. Application layer header (of the application to be 206 identified) 207 5. Packet data content 208 6. Packets and traffic behavior 210 The exact application identification methods are part of 211 the Metering Process internals that aim to provide an 212 accurate identification and minimize false identification. 213 This task requires a sophisticated Metering Process since 214 the protocols do not behave in a standard manner. 216 1. Applications use port obfuscation where the 217 application runs on different port than the IANA 218 assigned one. For example an HTTP server might 219 run a TCP port 23 (assigned to telnet in [IANA- 220 PORTS]) 222 2. IANA port registries do not accurately reflect how 223 certain ports are "commonly" used today. Some 224 ports are reserved, but the application either 225 never became prevalent or is not in use today. 227 3. The application behavior and identification logic 228 become more and more complex 230 For that reason, such Metering Processes usually detect 231 applications based on multiple mechanisms in parallel. 232 Detection based only on port matching might wrongly identify 233 the application. If the Metering Process is capable of 234 detecting applications more accurately, it is considered to 235 be stronger and more accurate. 237 Similarly, a reporting mechanism that uses L4 port based 238 applications only, such as L4:, would have 239 similar issues. The reporting system should be capable of 240 reporting the applications classified using all types of 241 mechanisms. In particular applications that do not have 242 any IANA port definition. While a mechanism to export 243 application information should be defined, the L4 port 244 being used must be exported using the destination port 245 (destinationTransportPort at [IANA-IPFIX]) in the 246 corresponding IPFIX record. 248 2012 250 This document specifies the application information 251 encoding (as described in section 4. ) to export the 252 application information with the IPFIX protocol [RFC5101]. 254 Applications could be identified at different OSI layers, 255 from layer 2 to layer 7. For example: Link Layer 256 Distribution Protocol (LLDP) [LLDP] can be identified in 257 layer 2, ICMP can be identified in layer 3 [IANA-PROTO], 258 HTTP can be identified in layer 4 [IANA-PORTS], and Webex 259 can be identified in layer 7. 261 While an ideal solution would be an IANA registry for 262 applications above (or inside the payload of) the well 263 known ports [IANA-PORTS], this solution is not always 264 possible. Indeed, the specifications for some applications 265 embedded in the payload are not available. Some reverse 266 engineering as well as a ubiquitous language for 267 application identification, would be required conditions to 268 be able to manage an IANA registry for these types of 269 applications. Clearly, these are blocking factors. 271 This document specifies the application information 272 encoding. However, the layer 7 application registry values 273 are out of scope of this document. 275 2.1. Application Information Use Cases 277 There are several use cases for application information: 279 1. Application Visibility 281 This is one of the main cases for using the application 282 information. Network administrators are using 283 application visibility to understand the main network 284 consumers, network trends and user behavior. 286 2. Security Functions 288 Application knowledge is sometimes used in security 289 functions in order to provide comprehensive functions 290 such as Application based firewall, URL filtering, 291 parental control, intrusion detection, etc. 293 2012 295 All of the above use cases require exporting application 296 information to provide the network function itself or to 297 log the network function operation. 299 3. Terminology 301 IPFIX-specific terminology used in this document is defined 302 in Section 2 of the IPFIX protocol specification [RFC5101]. 303 As in [RFC5101], these IPFIX-specific terms have the first 304 letter of a word capitalized when used in this document. 306 3.1. New Terminology 308 Application Id 310 A unique identifier for an application. 312 When an application is detected, the most granular 313 application is encoded in the Application Id. 315 4. applicationId Information Element Specification 317 This document specifies the applicationId Information 318 Element, which is a single field composed of two parts: 320 1. 8 bits of Classification Engine ID. The 321 Classification Engine can be considered as a 322 specific registry for application assignments. 323 2. m bits of Selector ID. The Selector ID length 324 varies depending on the Classification Engine ID. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Class. Eng. ID| Selector ID ... | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | ... | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 1: applicationId Information Element 336 2012 338 Classification Engine ID 340 A unique identifier for the engine which determined the 341 Selector ID. Thus the Classification Engine ID defines 342 the context for the Selector ID. 344 Selector ID 346 A unique identifier of the application for a specific 347 Classification Engine ID. Note that the Selector ID 348 length varies depending on the Classification Engine 349 ID. 351 The Selector ID term is similar in concepts with the 352 selectorId Information Element, specified in the PSAMP 353 Protocol [RFC5476][RFC5477]. 355 4.1. Existing Classification Engine IDs 357 The following Classification Engine IDs have been 358 allocated: 360 Name Value Description 362 0 Invalid. 364 IANA-L3 1 The Assigned Internet Protocol 365 Number (layer 3 (L3)) is exported 366 in the Selector ID. 367 See [IANA-PROTO]. 369 PANA-L3 2 Proprietary layer 3 definition. 370 An enterprise can export its own 371 layer 3 protocol numbers. The 372 Selector ID has a global 373 significance for all devices from 374 the same enterprise. 376 IANA-L4 3 The IANA layer 4 (L4) well-known 377 port number is exported in the 378 Selector ID. See [IANA-PORTS]. 379 Note: as an IPFIX flow is 380 unidirectional, it contains the 381 destination port in a flow from 383 2012 385 the client to the server. 387 PANA-L4 4 Proprietary layer 4 definition. 388 An enterprise can export its own 389 layer 4 port numbers. The 390 Selector ID has global 391 significance for devices from the 392 same enterprise. Example: IPFIX 393 had the port 4739 pre-assigned in 394 the IETF draft for years. While 395 waiting for the RFC and its 396 associated IANA registration, the 397 Selector ID 4739 was used with 398 this PANA-L4. 400 5 Reserved. 402 USER- 6 The Selector ID represents 403 Defined applications defined by the user 404 (using CLI, GUI, etc.) based on 405 the methods described in section 406 2. The Selector ID has a local 407 significance per device. 409 7 Reserved. 411 8 Reserved. 413 9 Reserved. 415 10 Reserved. 417 11 Reserved. 419 PANA-L2 12 Proprietary layer 2 (L2) 420 definition. An enterprise can 421 export its own layer 2 422 identifiers. The Selector ID 423 represents the enterprise's 424 unique global layer 2 425 applications. The Selector ID has 426 a global significance for all 427 devices from the same enterprise. 428 Examples include Cisco Subnetwork 429 Access Protocol (SNAP). 431 2012 433 PANA-L7 13 Proprietary layer 7 definition. 434 The Selector ID represents the 435 enterprise's unique global ID for 436 the layer 7 applications. The 437 Selector ID has a global 438 significance for all devices from 439 the same enterprise. This 440 Classification Engine Id is used 441 when the application registry is 442 owned by the Exporter 443 manufacturer (referred to as the 444 "enterprise" in this document). 446 14 Reserved. 448 15 Reserved. 450 16 Reserved. 452 17 Reserved. 454 ETHERTYPE 18 The Selector ID represents the 455 well-known Ethertype. See 456 [ETHERTYPE]. Note that the 457 Ethertype is usually expressed in 458 hexadecimal. However, the 459 corresponding decimal value is 460 used in this Selector ID. 462 LLC 19 The Selector ID represents the 463 well-known IEEE 802.2 Link Layer 464 Control (LLC) Destination Service 465 Access Point (DSAP). See [LLC]. 466 Note that LLC DSAP is usually 467 expressed in hexadecimal. 468 However, the corresponding 469 decimal value is used in this 470 Selector ID. 472 PANA-L7- 20 Proprietary layer 7 definition, 473 PEN including a Private Enterprise 474 Number (PEN) [PEN] to identify 475 that the application registry 476 being used is not owned by the 477 Exporter manufacturer (referred 478 to as the "enterprise" in this 480 2012 482 document, and identified by the 483 PEN), or to identify the original 484 enterprise in the case of a 485 mediator or 3rd party device. The 486 Selector ID represents the 487 enterprise unique global ID for 488 the layer 7 applications. The 489 Selector ID has a global 490 significance for all devices from 491 the same enterprise. 493 21 to 494 255 Available (255 is the maximum 495 Engine ID) 497 Table 1: Existing Classification Engine IDs 499 "PANA = Proprietary Assigned Number Authority". In other 500 words, an enterprise specific version of IANA for 501 internal IDs. 503 The PANA-L7 Classification Engine ID SHOULD be used when 504 the application registry is owned by the Exporter 505 manufacturer, referred to as the "enterprise" in this 506 document, and identified by the PEN. Even if the 507 application registry is owned by the Exporter 508 manufacturer, the PANA-L7-PEN MAY be used, specifying the 509 manufacturer. 510 The mechanism for the Collector to know about Exporter 511 PEN is out of scope of this document. Possible tracks 512 are: SNMP polling, an Options Template export, hardcoded 513 value, etc. 515 An Exporter may classify the application according to 516 another vendor's application registry. E.g., an IPFIX 517 Mediator [RFC6183] may need to re-export applications 518 received from different Exporters using different PANA-L7 519 application registries. For example, X's IPFIX Mediator 520 aggregates traffic from some Exporters which report 521 enterprise Y applications and other Exporters which 522 report enterprise Z applications. Or, X's device 523 implements enterprise Y's application classifications. 524 In these cases, the PANA-L7-PEN Classification Engine 525 MUST be used, which allows the original enterprise ID to 526 be reported. The ID of the enterprise which defined the 528 2012 530 application ID is identified by the enterprise's PEN. An 531 example is displayed in section 6.6. 533 Note that the the PANA-L7 Classification Engine ID is 534 also used for resolving IANA L4 port Discrepancies (see 535 Section 4.4) 537 The list in table 1 is maintained by IANA thanks to the 538 registry within the classificationEngineId Information 539 Element. See the "IANA Considerations" section. The 540 Classification Engine Id is part of the Application Id 541 encoding, so the classificationEngineId Information 542 Element is currently not required by the specifications 543 in this document. However, this Information Element was 544 created for completeness, as it was anticipated that this 545 Information Element will be required in the future. 547 4.2. Selector ID Length per Classification IDs 549 As the Selector Id part of the Application Id is variable 550 based on the Classification Engine ID value, the 551 applicationId SHOULD be encoded in a variable-length 552 Information Element [RFC5101] for the IPFIX export. 554 2012 556 The following table displays the Selector ID default 557 length for the different Classification Engine IDs. 559 Classification Selector ID default 560 Engine ID Name length (in bytes) 562 IANA-L3 1 564 PANA-L3 1 566 IANA-L4 2 568 PANA-L4 2 570 USER-Defined 3 572 PANA-L2 5 574 PANA-L7 3 576 ETHERTYPE 2 578 LLC 1 580 PANA-L7-PEN 3 (*) 582 Table 2: Selector ID default length 583 per Classification Engine ID 585 (*) There is an extra 4 bytes for the PEN. However, the PEN 586 is not considered part of the Selector ID. 588 If a legacy protocol such as NetFlow version 9 [RFC3954] is 589 used, and this protocol doesn't support variable length 590 Information Elements, then either multiple Template Records 591 (one per applicationId length), or a single Template Record 592 corresponding to the maximum sized applicationId MUST be 593 used. 595 Application Ids MAY be encoded in a smaller number of 596 bytes, following the same rules as for the IPFIX Reduced 597 Size Encoding [RFC5101]. 599 Application Ids MAY be encoded with a larger length. 600 For example, a normal IANA L3 protocol encoding would take 601 2 bytes since the Selector ID represents the protocol field 603 2012 605 from the IP header encoded in one byte. However, an IANA 606 L3 protocol encoding may be encoded with 3 bytes. In this 607 case, the Selector ID value MUST always be encoded in the 608 least significant bits as shown in Figure 2. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |Class. Eng. ID |zero-valued upper-bits ... Selector ID | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Figure 2: Selector ID encoding 618 4.3. Application Name Options Template Record 620 For Classification Engines which specify locally unique 621 Application Ids (which means unique per engine and per 622 router), an Options Template Record (see [RFC5101]) MUST 623 be used to export the correspondence between the 624 Application Id, the Application Name, and the Application 625 Description. 627 For Classification Engines which specify globally unique 628 Application Ids, an Options Template Record MAY be used 629 to export the correspondence between the Application Id, 630 the Application Name and the Application Description, 631 unless the mapping is hardcoded in the Collector, or 632 known out of band (for example, by polling a MIB). 634 An example Options Template is shown in section 6.8. 636 Enterprises may assign company-wide Application Id values 637 for the PANA-L7 Classification Engine. In this case, a 638 possible optimization for the Collector is to keep the 639 mappings between the Application Ids and the Application 640 Names per enterprise, as opposed to per Exporter. 642 4.4. Resolving IANA L4 Port Discrepancies 644 Even though the IANA L4 ports usually point to the same 645 protocols for both UDP, TCP or other transport types, there 646 are some exceptions, as mentioned in the Appendix B. 648 2012 650 Instead of imposing the transport protocol 651 (UDP/TCP/SCTP/etc.) in the scope of the "Application Name 652 Options Template Record" (section 6.8. ) for all 653 applications (on top of having the transport protocol as 654 key-field in the Flow Record definition), the convention is 655 that the L4 application is always TCP related. So, 656 whenever the Collector has a conflict in looking up IANA, 657 it would choose the TCP choice. As a result, the UDP L4 658 applications from Table 3 and the SCTP L4 applications from 659 Table 4 are assigned in the PANA_L7 Application Id range, 660 i.e. under Classification Engine ID 13. 662 Currently, there are no discrepancies between the well 663 known ports for TCP and DCCP. 665 5. Grouping the Applications with the Attributes 667 Due to the high number of different Application Ids, 668 Application Ids MAY be categorized into groups. This offers 669 the benefits of easier reporting and action, such as QoS 670 policies. Indeed, most applications with the same 671 characteristics should be treated the same way; for example, 672 all video traffic. 674 Attributes are statically assigned per Application Id and are 675 independent of the traffic. The attributes are listed below: 677 Name Description 679 Category An attribute that provides a first 680 level categorization for each 681 Application Id. Examples include: 682 browsing, email, file-sharing, 683 gaming, instant messaging, voice- 684 and-video, etc... 685 The category attribute is encoded by 686 the ApplicationCategoryName 687 Information Element. 689 Sub-Category An attribute that provides a second 690 level categorization for each 691 Application Id. Examples include: 692 backup-systems, client-server, 693 database, routing-protocol, etc... 695 2012 697 The sub-category attribute is 698 encoded by the 699 ApplicationSubCategoryName 700 Information Element. 702 Application- An attribute that groups multiple 703 Group Application Ids that belong to the 704 same networking application. For 705 example, the ftp-group contain the 706 ftp-data (port 20), ftp (port 20), 707 ni-ftp (port 47), sftp (port 115), 708 bftp (port 152), ftp-agent(port 709 574), ftps-data (port 989). The 710 application-group attribute is 711 encoded by the ApplicationGroupName 712 Information Element. 714 P2P-Technology Specifies if the Application Id is 715 based on peer-to-peer technology. 716 The P2P-technology attribute is 717 encoded by the p2pTechnology 718 Information Element. 720 Tunnel- Specifies if the Application Id is 721 Technology used as a tunnel technology. The 722 tunnel-technology attribute is 723 encoded by the tunnelTechnology 724 Information Element. 726 Encrypted Specifies if the Application Id is 727 an encrypted networking protocol. 728 The encrypted attribute is encoded 729 by the encryptedTechnology 730 Information Element. 732 Table 3: Application Id Static Attributes 734 Every application is assigned to one 735 ApplicationCategoryName, one ApplicationSubCategoryName, 736 one ApplicationGroupName, has one p2pTechnology, one 737 tunnelTechnology, and one encryptedTechnology. These new 738 Information Elements are specified in the IANA 739 Consideration Section 7.1. 7.1. 741 2012 743 Maintaining the attribute values in IANA seems impossible 744 to realize. Therefore the attribute values per application 745 are enterprise specific. 747 5.1. Options Template Record for the Attribute Values 749 An Options Template Record (see [RFC5101]) SHOULD be used 750 to export the correspondence between each Application Id 751 and its related Attribute values. An alternative way for 752 the Collecting Process to learn the correspondence is to 753 populate these mappings out of band, for example, by 754 loading a CSV file containing the correspondence table. 756 The Attributes Option Template contains the ApplicationId 757 as a scope field, followed by the ApplicationCategoryName, 758 the ApplicationSubCategoryName, the ApplicationGroupName, 759 the p2pTechnology, the tunnelTechnology, and the 760 encryptedTechnology Information Elements. 762 A list of attributes may conveniently be exported using a 763 subTemplateList per [RFC6313]. 765 An example is given in section 6.9. 767 6. Application Id Examples 769 The following examples are created solely for the purpose 770 of illustrating how the extensions proposed in this 771 document are encoded. 773 6.1. Example 1: Layer 2 Protocol 775 The list of Classification Engine IDs in Table 1 shows that 776 the layer 2 Classification Engine IDs are 12 (PANA-L2), 18, 777 (Ethertype) and 19 (LLC). 779 From the Ethertype list, LLDP [LLDP] has the Selector ID 780 value 0x88CC, so 35020 in decimal: 782 NAME Selector ID 783 LLDP 35020 785 2012 787 So, in the case of LLDP, the Classification Engine ID is 18 788 (LLC) while the Selector ID has the value 35020. 790 Per section 4. , the applicationId Information Element, 791 is a single field composed of 8 bits of Classification 792 Engine ID, followed by m bits of Selector ID. 794 Therefore the Application Id is encoded as: 796 0 1 2 797 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | 18 | 35020 | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 So the Application Id has the decimal value of 1214668. 803 The format '18..35020' is used for simplicity in the 804 examples below, to clearly express that two components of 805 the Application ID. 807 The Exporting Process creates a Template Record with a few 808 Information Elements: amongst other things, the Application 809 Id. For example: 811 - applicationId (key field) 812 - octetTotalCount (non key field) 814 For example, a Flow Record corresponding to the above 815 Template Record may contain: 817 { applicationId='18..35020', 818 octetTotalCount=123456 } 820 The Collector has all the required information to determine 821 that the application is LLDP, because the Application Id 822 uses a global and well known registry, i.e. the Ethertype. 823 The Collector can determine which application is 824 represented by the Application Id by loading the registry 825 out of band. 827 6.2. Example 2: Standardized IANA Layer 3 Protocol 829 From the list of Classification Engine IDs in Table 1, the 830 IANA layer 3 Classification Engine ID (IANA-L3) is 1. 832 2012 834 From the list of IANA layer 3 protocols (see [IANA-PROTO]), 835 ICMP has the value 1: 837 Decimal Keyword Protocol Reference 838 1 ICMP Internet Control [RFC792] 839 Message 841 So in the case of the standardized IANA layer 3 protocol 842 ICMP, the Classification Engine ID is 1, and the Selector 843 ID has the value of 1. 845 Therefore the Application Id is encoded as: 847 0 1 848 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | 1 | 1 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 So the Application Id has the value of 257. The format 854 '1..1' is used for simplicity in the examples below. 856 The Exporting Process creates a Template Record with a few 857 Information Elements: amongst other things, the Application 858 Id. For example: 860 - sourceIPv4Address (key field) 861 - destinationIPv4Address (key field) 862 - ipDiffServCodePoint (key field) 863 - applicationId (key field) 864 - octetTotalCount (non key field) 866 For example, a Flow Record corresponding to the above 867 Template Record may contain: 869 { sourceIPv4Address=192.0.2.1, 870 destinationIPv4Address=192.0.2.2, 871 ipDiffServCodePoint=0, 872 applicationId='1..1', 873 octetTotalCount=123456 } 875 The Collector has all the required information to determine 876 that the application is ICMP, because the Application Id 877 uses a global and well know registry, ie the IANA L3 878 protocol number. 880 2012 882 6.3. Example 3: Proprietary Layer 3 Protocol 884 Assume that a enterprise has specified a new layer 3 885 protocol called "foo". 887 From the list of Classification Engine IDs in Table 1, the 888 proprietary layer 3 Classification Engine ID (PANA-L3) is 889 2. 891 A global registry within the enterprise specifies that the 892 "foo" protocol has the value 90: 894 Protocol Protocol Id 895 foo 90 897 So, in the case of the layer 3 protocol foo specified by 898 this enterprise, the Classification Engine ID is 2, and the 899 Selector ID has the value of 90. 901 Therefore the Application Id is encoded as: 903 0 1 904 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | 2 | 90 | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 So the Application Id has the value of 602. The format 910 '2..90' is used for simplicity in the examples below. 912 The Exporting Process creates a Template Record with a few 913 Information Elements: amongst other things, the Application 914 Id. For example: 916 - sourceIPv4Address (key field) 917 - destinationIPv4Address (key field) 918 - ipDiffServCodePoint (key field) 919 - applicationId (key field) 920 - octetTotalCount (non key field) 922 For example, a Flow Record corresponding to the above 923 Template Record may contain: 925 2012 927 { sourceIPv4Address=192.0.2.1, 928 destinationIPv4Address=192.0.2.2, 929 ipDiffServCodePoint=0, 930 applicationId='2..90', 931 octetTotalCount=123456 } 933 Along with this Flow Record, a new Options Template Record 934 would be exported, as shown in Section 6.8. 936 6.4. Example 4: Standardized IANA Layer 4 Port 938 From the list of Classification Engine IDs in Table 1, the 939 IANA layer 4 Classification Engine ID (PANA-L3) is 3. 941 From the list of IANA layer 4 ports (see [IANA-PORTS]), 942 SNMP has the value 161: 944 Keyword Decimal Description 945 snmp 161/tcp SNMP 946 snmp 161/udp SNMP 948 So in the case of the standardized IANA layer 4 SNMP port, 949 the Classification Engine ID is 3, and the Selector ID has 950 the value of 161. 952 Therefore the Application Id is encoded as: 954 0 1 955 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | 3 | 161 | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 So the Application Id has the value of 196769. The format 961 '3..161' is used for simplicity in the examples below. 963 The Exporting Process creates a Template Record with a few 964 Information Elements: amongst other things, the Application 965 Id. For example: 967 - sourceIPv4Address (key field) 968 - destinationIPv4Address (key field) 969 - protocol (key field) 971 2012 973 - ipDiffServCodePoint (key field) 974 - applicationId (key field) 975 - octetTotalCount (non key field) 977 For example, a Flow Record corresponding to the above 978 Template Record may contain: 980 { sourceIPv4Address=192.0.2.1, 981 destinationIPv4Address=192.0.2.2, 982 protocol=17, ipDiffServCodePoint=0, 983 applicationId='3..161', 984 octetTotalCount=123456 } 986 The Collector has all the required information to determine 987 that the application is SNMP, because the Application Id 988 uses a global and well know registry, ie the IANA L4 989 protocol number. 991 6.5. Example 5: Layer 7 Application 993 In this example, the Metering Process has observed some 994 Webex traffic. 996 From the list of Classification Engine IDs in Table 1, the 997 layer 7 unique Classification Engine ID (PANA-L7) is 13. 999 Suppose that the Metering Process returns the ID 10000 for 1000 Webex traffic. 1002 So, in the case of this Webex application, the 1003 Classification Engine ID is 13 and the Selector ID has the 1004 value of 10000. 1006 Therefore the Application Id is encoded as: 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | 13 | 10000 | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 So the Application Id has the value of 218113808. The 1015 format '13..10000' is used for simplicity in the examples 1016 below. 1018 2012 1020 The Exporting Process creates a Template Record with a few 1021 Information Elements: amongst other things, the Application 1022 Id. For example: 1024 - sourceIPv4Address (key field) 1025 - destinationIPv4Address (key field) 1026 - ipDiffServCodePoint (key field) 1027 - applicationId (key field) 1028 - octetTotalCount (non key field) 1030 For example, a Flow Record corresponding to the above 1031 Template Record may contain: 1033 { sourceIPv4Address=192.0.2.1, 1034 destinationIPv4Address=192.0.2.2, 1035 ipDiffServCodePoint=0, 1036 applicationId='13..10000', 1037 octetTotalCount=123456 } 1039 The 10000 value is globally unique for the enterprise, so 1040 that the Collector can determine which application is 1041 represented by the Application Id by loading the registry 1042 out of band. 1044 Along with this Flow Record, a new Options Template Record 1045 would be exported, as shown in Section 6.8. 1047 6.6. Example 6: Layer 7 Application with Private Enterprise 1048 Number (PEN) 1050 In this example, the layer 7 Webex traffic from Example 5 1051 above have been classified by enterprise X. The exported 1052 records have been received by enterprise Y's mediation 1053 device, which wishes to forward them to a top level 1054 Collector. 1056 In order for the top level Collector to know that the 1057 records were classified by enterprise X, the enterprise Y 1058 mediation device must report the records using the 1059 PANA-L7-PEN Classification Engine ID with enterprise X's 1060 Private Enterprise Number. 1062 The PANA-L7-PEN Classification Engine ID is 20, and 1063 enterprise X's Selector ID for Webex traffic has the value 1064 of 10000. 1066 2012 1068 Therefore the Application Id is encoded as: 1070 0 1 2 3 1071 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 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | 20 | enterprise ID = X ...| 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 |...Ent.ID.contd| 10000 | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 The format '20..X..10000' is used for simplicity in the 1079 examples below. 1081 The Exporting Process creates a Template Record with a few 1082 Information Elements: amongst other things, the Application 1083 Id. For example: 1085 - sourceIPv4Address (key field) 1086 - destinationIPv4Address (key field) 1087 - ipDiffServCodePoint (key field) 1088 - applicationId (key field) 1089 - octetTotalCount (non key field) 1091 For example, a Flow Record corresponding to the above 1092 Template Record may contain: 1094 { sourceIPv4Address=192.0.2.1, 1095 destinationIPv4Address=192.0.2.2, 1096 ipDiffServCodePoint=0, 1097 applicationId='20..X..10000', 1098 octetTotalCount=123456 } 1100 The 10000 value is globally unique for enterprise X, so 1101 that the Collector can determine which application is 1102 represented by the Application Id by loading the registry 1103 out of band. 1105 Along with this Flow Record, a new Options Template Record 1106 would be exported, as shown in Section 6.8. 1108 6.7. Example: port Obfuscation 1110 For example, an HTTP server might run on a TCP port 23 1111 (assigned to telnet in [IANA-PORTS]). If the Metering 1113 2012 1115 Process is capable of detecting HTTP in the same case, the 1116 Application Id representation must contain HTTP. However, 1117 if the reporting application wants to determine whether the 1118 default HTTP port 80 or 8080 was used, the destination port 1119 (destinationTransportPort at [IANA-IPFIX]) must also be 1120 exported in the corresponding IPFIX record. 1122 In the case of a standardized IANA layer 4 port, the 1123 Classification Engine ID (PANA-L4) is 3, and the Selector 1124 ID has the value of 80 for HTTP (see [IANA-PORTS]). 1125 Therefore the Application Id is encoded as: 1127 0 1 2 1128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | 3 | 80 | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 The Exporting Process creates a Template Record with a few 1134 Information Elements: amongst other things, the Application 1135 Id. For example: 1137 - sourceIPv4Address (key field) 1138 - destinationIPv4Address (key field) 1139 - protocol (key field) 1140 - destinationTransportPort (key field) 1141 - applicationId (key field) 1142 - octetTotalCount (non key field) 1144 For example, a Flow Record corresponding to the above 1145 Template Record may contain: 1147 { sourceIPv4Address=192.0.2.1, 1148 destinationIPv4Address=192.0.2.2, 1149 protocol=17, 1150 destinationTransportPort=23, 1151 applicationId='3..80', 1152 octetTotalCount=123456 } 1154 The Collector has all the required information to determine 1155 that the application is HTTP, but runs on port 23. 1157 2012 1159 6.8. Example: Application Name Mapping Options Template 1161 Along with the Flow Records shown in the above examples, a 1162 new Options Template Record should be exported to express 1163 the Application Name and Application Description associated 1164 with each Application Id. 1166 The Options Template Record contains the following 1167 Information Elements: 1169 1. Scope = applicationId. 1171 From RFC 5101: "The scope, which is only available 1172 in the Options Template Set, gives the context of 1173 the reported Information Elements in the Data 1174 Records." 1176 2. applicationName. 1178 3. applicationDescription. 1180 The Options Data Record associated with the examples above 1181 would contain, for example: 1183 { scope=applicationId='2..90', 1184 applicationName="foo", 1185 applicationDescription="The foo protocol", 1187 scope=applicationId='13..10000', 1188 applicationName="webex", 1189 applicationDescription="Webex application" } 1191 scope=applicationId='20..X..10000', 1192 applicationName="webex", 1193 applicationDescription="Webex application" } 1195 When combined with the example Flow Records above, these 1196 Options Template Records tell the Collector: 1198 1. A flow of 123456 bytes exists from sourceIPv4Address 1199 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1200 applicationId of '12..90', which maps to the "foo" 1201 application. 1203 2012 1205 2. A flow of 123456 bytes exists from sourceIPv4Address 1206 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1207 Application Id of '13..10000', which maps to the "Webex" 1208 application. 1210 3. A flow of 123456 bytes exists from sourceIPv4Address 1211 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1212 Application Id of '20..PEN..10000', which maps to the 1213 "Webex" application, according to the application registry 1214 from the entrerprise X. 1216 6.9. Example: Attributes Values Options Template Record 1218 Along with the Flow Records shown in the above examples, a 1219 new Options Template Record is exported to express the 1220 values of the different attributes related to the 1221 Application Ids. 1223 The Options Template Record would contain the following 1224 Information Elements: 1226 1. Scope = applicationId. 1228 From RFC 5101: "The scope, which is only available 1229 in the Options Template Set, gives the context of 1230 the reported Information Elements in the Data 1231 Records." 1233 2. applicationCategoryName. 1235 3. applicationSubCategoryName. 1237 4. applicationGroupName 1239 5. p2pTechnology 1241 6. tunnelTechnology 1243 7. encryptedTechnology 1245 The Options Data Record associated with the examples above 1246 would contain, for example: 1248 2012 1250 { scope=applicationId='2..90', 1251 applicationCategoryName="foo-category", 1252 applicationSubCategoryName="foo-subcategory", 1253 applicationGroupName="foo-group", 1254 p2pTechnology=NO 1255 tunnelTechnology=YES 1256 encryptedTechnology=NO 1258 When combined with the example Flow Records above, these 1259 Options Template Records tell the Collector: 1261 A flow of 123456 bytes exists from sourceIPv4Address 1262 192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP 1263 value of 0 and an applicationId of '12..90', which maps to 1264 the "foo" application. This application can be 1265 characterized by the relevant attributes values. 1267 7. IANA Considerations 1269 7.1. New Information Elements 1271 This document specifies 10 new IPFIX Information Elements: 1272 the applicationDescription, applicationId, applicationName, 1273 classificationEngineId, applicationCategoryName, 1274 applicationSubCategoryName, applicationGroupName, 1275 p2pTechnology, tunnelTechnology, and encryptedTechnology. 1277 New Information Elements to be added to the IPFIX Information 1278 Element registry at [IANA-IPFIX] are listed below. 1280 EDITOR'S NOTE: RFC5102, which explains the IANA 1281 considerations for assigning new Information Elements 1282 mentions. "The value of these identifiers is in the range of 1283 1-32767. Within this range, Information Element identifier 1284 values in the sub-range of 1-127 are compatible with field 1285 types used by NetFlow version 9 [RFC3954].". This is the 1286 reason why some Information Elements have already an assigned 1287 ElementId in the range 1-127, instead of . These 1288 Information Elements should anyway follow the IANA 1289 Considerations from RFC5102, i.e. " New assignments for IPFIX 1290 Information Elements will be administered by IANA through 1291 Expert Review review". The reviewer is Nevil Brownlee. 1292 EDITOR'S NOTE: the XML specification in Appendix A must be 1293 updated with the elementID values allocated below. 1295 2012 1297 RFC-EDITOR/IANA-EDITOR: some entries are already present in 1298 IPFIX-IANA. However, those must be updated with the current 1299 content. 1301 7.1.1. applicationDescription 1303 Name: applicationDescription 1304 Description: 1305 Specifies the description of an application. 1306 Abstract Data Type: string 1307 Data Type Semantics: 1308 ElementId: 94 1309 Status: current 1311 7.1.2. applicationId 1313 Name: applicationId 1314 Description: 1315 Specifies an Application Id. 1316 Abstract Data Type: octetArray 1317 Data Type Semantics: identifier 1318 Reference: See section 4. of [EDITORS NOTE: this document] 1319 for the applicationId Information Element Specification. 1320 ElementId: 95 1321 Status: current 1323 7.1.3. applicationName 1325 Name: applicationName 1326 Description: 1327 Specifies the name of an application. 1328 Abstract Data Type: string 1329 Data Type Semantics: 1330 ElementId: 96 1331 Status: current 1333 7.1.4. classificationEngineId 1335 Name: classificationEngineId 1336 Description: 1337 A unique identifier for the engine which determined the 1338 Selector ID. Thus the Classification Engine ID defines 1340 2012 1342 the context for the Selector ID. The Classification 1343 Engine can be considered as a specific registry for 1344 application assignments. 1346 Initial values for this field are listed below. Further 1347 values may be assigned by IANA in the Classification 1348 Engine Ids registry. 1350 0 Invalid. 1352 1 IANA-L3: The Assigned Internet Protocol Number 1353 (layer 3 (L3)) is exported in the Selector ID. See 1354 http://www.iana.org/assignments/protocol-numbers. 1356 2 PANA-L3: Proprietary layer 3 definition. An 1357 enterprise can export its own layer 3 protocol 1358 numbers. The Selector ID has a global significance 1359 for all devices from the same enterprise. 1361 3 IANA-L4: The IANA layer 4 (L4) well-known port 1362 number is exported in the Selector ID. See [IANA- 1363 PORTS]. Note: as an IPFIX flow is unidirectional, 1364 it contains the destination port in a flow from 1365 the client to the server. 1367 4 PANA-L4: Proprietary layer 4 definition. An 1368 enterprise can export its own layer 4 port 1369 numbers. The Selector ID has global significance 1370 for devices from the same enterprise. Example: 1371 IPFIX had the port 4739 pre-assigned in the IETF 1372 draft for years. While waiting for the RFC and its 1373 associated IANA registration, the Selector ID 4739 1374 was used with this PANA-L4. 1376 5 Reserved 1378 6 USER-Defined: The Selector ID represents 1379 applications defined by the user (using CLI, GUI, 1380 etc.) based on the methods described in section 2. 1381 The Selector ID has a local significance per 1382 device. 1384 7 Reserved 1386 8 Reserved 1388 2012 1390 9 Reserved 1392 10 Reserved 1394 11 Reserved 1396 12 PANA-L2: Proprietary layer 2 (L2) definition. An 1397 enterprise can export its own layer 2 identifiers. 1398 The Selector ID represents the enterprise's unique 1399 global layer 2 applications. The Selector ID has a 1400 global significance for all devices from the same 1401 enterprise. Examples include Cisco Subnetwork 1402 Access Protocol (SNAP). 1404 13 PANA-L7: Proprietary layer 7 definition. The 1405 Selector ID represents the enterprise's unique 1406 global ID for the layer 7 applications. The 1407 Selector ID has a global significance for all 1408 devices from the same enterprise. This 1409 Classification Engine Id is used when the 1410 application registry is owned by the Exporter 1411 manufacturer (referred to as the "enterprise" in 1412 this document). 1414 14 Reserved 1416 15 Reserved 1418 16 Reserved 1420 17 Reserved 1422 18 ETHERTYPE: The Selector ID represents the well- 1423 known Ethertype. See [ETHERTYPE]. Note that the 1424 Ethertype is usually expressed in hexadecimal. 1425 However, the corresponding decimal value is used 1426 in this Selector ID. 1428 19 LLC: The Selector ID represents the well-known 1429 IEEE 802.2 Link Layer Control (LLC) Destination 1430 Service Access Point (DSAP). See [LLC]. Note that 1431 LLC DSAP is usually expressed in hexadecimal. 1432 However, the corresponding decimal value is used 1433 in this Selector ID. 1435 2012 1437 20 PANA-L7-PEN: Proprietary layer 7 definition, 1438 including a Private Enterprise Number (PEN) [PEN] 1439 to identify that the application registry being 1440 used is not owned by the Exporter manufacturer 1441 (referred to as the "enterprise" in this document, 1442 and identified by the PEN), or to identify the 1443 original enterprise in the case of a mediator or 1444 3rd party device. The Selector ID represents the 1445 enterprise unique global ID for the layer 7 1446 applications. The Selector ID has a global 1447 significance for all devices from the same 1448 enterprise. 1450 Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17), 1451 are reserved to be compliant with existing 1452 implementations already using the 1453 classificationEngineId. 1455 Abstract Data Type: unsigned8 1456 Data Type Semantics: identifier 1457 ElementId: 101 1458 Status: current 1460 7.1.5. applicationCategoryName 1462 Name: applicationCategoryName 1463 Description: 1464 An attribute that provides a first level categorization for 1465 each Application Id. 1466 Abstract Data Type: string 1467 Data Type Semantics: 1468 ElementId: 1469 Status: current 1471 7.1.6. applicationSubCategoryName 1473 Name: applicationSubCategoryName 1474 Description: 1475 An attribute that provides a second level categorization 1476 for each Application Id. 1477 Abstract Data Type: string 1478 Data Type Semantics: 1479 ElementId: 1480 Status: current 1482 2012 1484 7.1.7. applicationGroupName 1486 Name: applicationGroupName 1487 Description: 1488 An attribute that groups multiple Application Ids that 1489 belong to the same networking application. 1490 Abstract Data Type: string 1491 Data Type Semantics: 1492 ElementId: 1493 Status: current 1495 7.1.8. p2pTechnology 1497 Name: p2pTechnology 1498 Description: 1499 Specifies if the Application Id is based on peer-to-peer 1500 technology. Possible values are: { "yes", "y", 1 }, 1501 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1502 Abstract Data Type: string 1503 Data Type Semantics: 1504 ElementId: 288 1505 Status: current 1507 7.1.9. tunnelTechnology 1509 Name: tunnelTechnology 1510 Description: 1511 Specifies if the Application Id is used as a tunnel 1512 technology. 1513 Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } 1514 and 1515 { "unassigned" , "u", 0 }. 1516 Abstract Data Type: string 1517 Data Type Semantics: 1518 ElementId: 289 1519 Status: current 1521 7.1.10. encryptedTechnology 1523 Name: encryptedTechnology 1525 2012 1527 Description: 1528 Specifies if the Application Id is an encrypted networking 1529 protocol. Possible values are: { "yes", "y", 1 }, 1530 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1531 Abstract Data Type: string 1532 Data Type Semantics: 1533 ElementId: 290 1534 Status: current 1536 7.2. Classification Engine Ids Registry 1538 The Information Element #101, named classificationEngineId, 1539 carries information about the context for the Selector ID, 1540 and can be considered as a specific registry for application 1541 assignments. For ensuring extensibility of this information, 1542 IANA has created a new registry for Classification Engine Ids 1543 and filled it with the initial list from the description 1544 Information Element #101, classificationEngineId. 1546 New assignments for Classification Engine Ids will be 1547 administered by IANA through Expert Review [RFC5226], i.e., 1548 review by one of a group of experts designated by an IETF 1549 Area Director. The group of experts must double check the 1550 new definitions with already defined Classification Engine 1551 Ids for completeness, accuracy, and redundancy. The 1552 specification of Classification Engine Ids MUST be published 1553 using a well-established and persistent publication medium. 1555 RFC-EDITOR: this should be assigned similarly to 1556 mplsTopLabelType subregistry at 1557 http://www.iana.org/assignments/ipfix/ipfix.xml 1559 8. Security Considerations 1561 The same security considerations as for the IPFIX Protocol 1562 [RFC5101] apply. 1564 As mentioned in Section 2.1. , the application knowledge is 1565 useful in security based applications. Security applications 1566 may impose supplementary requirements on the export of 1567 application information, and these need to be examined on a 1568 case by case basis. 1570 2012 1572 9. References 1574 9.1. Normative References 1576 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1577 Requirement Levels, BCP 14, RFC 2119, March 1997. 1579 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 1580 Information Export (IPFIX) Protocol for the 1581 Exchange of IP Traffic Flow Information", RFC 5101, 1582 January 2008. 1584 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., 1585 and J. Meyer, "Information Model for IP Flow 1586 Information Export", RFC 5102, January 2008. 1588 [RFC5226] Narten, T., and H. Alverstrand, "Guidelines for 1589 Writing an IANA Considerations Section in RFCs", 1590 RFC 5226, May 2008 1592 [ETHERTYPE] 1593 http://standards.ieee.org/develop/regauth/ethertype 1594 /eth.txt 1596 [IANA-PORTS] http://www.iana.org/assignments/port-numbers 1598 [IANA-PROTO] http://www.iana.org/assignments/protocol- 1599 numbers 1601 [LLC] 1602 http://standards.ieee.org/develop/regauth/llc/publi 1603 c.html. 1605 [PEN] http://www.iana.org/assignments/enterprise-numbers 1607 9.2. Informative References 1609 [RFC792] J. Postel, Internet Control Message Protocol, RFC 1610 792, September 1981. 1612 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. 1613 Zander, Requirements for IP Flow Information 1614 Export, RFC 3917, October 2004. 1616 2012 1618 [RFC3954] B. Claise, "Cisco Systems NetFlow Services Export 1619 Version 9", RFC 3954, October 2004. 1621 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 1622 Export Using IP Flow Information Export (IPFIX)", 1623 RFC 5103, January 2008. 1625 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 1626 Quittek, "Architecture for IP Flow Information 1627 Export", RFC 5470, March 2009. 1629 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, 1630 "Guidelines for IP Flow Information Export (IPFIX) 1631 Testing", RFC 5471, March 2009. 1633 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 1634 Redundancy in IP Flow Information Export (IPFIX) 1635 and Packet Sampling (PSAMP) Reports", RFC 5473, 1636 March 2009. 1638 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) 1639 Protocol Specifications", RFC 5476, March 2009. 1641 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dresslet F., 1642 and G. Carle, "Information Model for Packet 1643 Sampling Exports", RFC 5477, March 2009. 1645 [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. 1646 Ishibashi, "IP Flow Information Export (IPFIX) 1647 Mediation: Framework", RFC6183, April 2011 1649 [RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S. 1650 Yates, "Export of Structured Data in IP Flow 1651 Information Export (IPFIX)", RFC6313, July 2011 1653 [LLDP] "IEEE Std 802.1AB-2005, Standard for Local and 1654 metropolitan area networks - Station and Media 1655 Access Control Connectivity Discovery", IEEE Std 1656 802.1AB-2005 IEEE Std, 2005. 1658 2012 1660 [IANA-IPFIX] 1661 http://www.iana.org/assignments/ipfix/ipfix.xml 1663 [CISCO-APPLICATION-REGISTRY] 1664 http://www.cisco.com/go/application_registry 1666 10. Acknowledgement 1668 The authors would like to thank their many colleagues across 1669 Cisco Systems who made this work possible. Specifically 1670 Patrick Wildi for his time and expertise. 1672 2012 1674 11. Authors' Addresses 1676 Benoit Claise 1677 Cisco Systems, Inc. 1678 De Kleetlaan 6a b1 1679 Diegem 1813 1680 Belgium 1682 Phone: +32 2 704 5622 1683 EMail: bclaise@cisco.com 1685 Paul Aitken 1686 Cisco Systems, Inc. 1687 96 Commercial Quay 1688 Commercial Street 1689 Edinburgh, EH6 6LX, United Kingdom 1691 Phone: +44 131 561 3616 1692 EMail: paitken@cisco.com 1694 Nir Ben-Dvora 1695 Cisco Systems, Inc. 1696 32 HaMelacha St., 1697 P.O.Box 8735, I.Z.Sapir 1698 South Netanya, 42504 1699 Israel 1701 Phone: +972 9 892 7187 1702 EMail: nirbd@cisco.com 1704 Appendix A. Additions to XML Specification of IPFIX 1705 Information Elements (non normative) 1707 This appendix A contains additions to the machine-readable 1708 description of the IPFIX information model coded in XML in 1709 Appendix A and Appendix B in [RFC5102]. Note that this 1710 appendix is of informational nature, while the text in 1711 Section 7. (generated from this appendix) is normative. 1713 2012 1715 The following field definitions are appended to the IPFIX 1716 information model in Appendix A of [RFC5102]. 1718 1723 1724 1725 Specifies the description of an application. 1726 1727 1728 1730 1736 1737 1738 Specifies an Application Id. 1739 1740 1741 1742 1743 See section 4. of [EDITORS NOTE: this document] 1744 for the applicationId Information Element 1745 Specification. 1746 1747 1748 1750 1755 1756 1757 Specifies the name of an application. 1758 1759 1760 1762 2012 1764 1770 1771 1772 0 Invalid. 1774 1 IANA-L3: The Assigned Internet Protocol Number 1775 (layer 3 (L3)) is exported in the Selector ID. 1776 See http://www.iana.org/assignments/protocol- 1777 numbers. 1779 2 PANA-L3: Proprietary layer 3 definition. An 1780 enterprise can export its own layer 3 protocol 1781 numbers. The Selector ID has a global 1782 significance for all devices from the same 1783 enterprise. 1785 3 IANA-L4: The IANA layer 4 (L4) well-known port 1786 number is exported in the Selector ID. See 1787 [IANA-PORTS]. Note: as an IPFIX flow is 1788 unidirectional, it contains the destination 1789 port in a flow from the client to the server. 1791 4 PANA-L4: Proprietary layer 4 definition. An 1792 enterprise can export its own layer 4 port 1793 numbers. The Selector ID has global 1794 significance for devices from the same 1795 enterprise. Example: IPFIX had the port 4739 1796 pre-assigned in the IETF draft for years. 1797 While waiting for the RFC and its associated 1798 IANA registration, the Selector ID 4739 was 1799 used with this PANA-L4. 1801 5 Reserved 1803 2012 1805 6 USER-Defined: The Selector ID represents 1806 applications defined by the user (using CLI, 1807 GUI, etc.) based on the methods described in 1808 section 2. The Selector ID has a local 1809 significance per device. 1811 7 Reserved 1813 8 Reserved 1815 9 Reserved 1817 10 Reserved 1819 11 Reserved 1821 12 PANA-L2: Proprietary layer 2 (L2) definition. 1822 An enterprise can export its own layer 2 1823 identifiers. The Selector ID represents the 1824 enterprise's unique global layer 2 1825 applications. The Selector ID has a global 1826 significance for all devices from the same 1827 enterprise. Examples include Cisco Subnetwork 1828 Access Protocol (SNAP). 1830 13 PANA-L7: Proprietary layer 7 definition. The 1831 Selector ID represents the enterprise's unique 1832 global ID for the layer 7 applications. The 1833 Selector ID has a global significance for all 1834 devices from the same enterprise. This 1835 Classification Engine Id is used when the 1836 application registry is owned by the Exporter 1837 manufacturer (referred to as the "enterprise" 1838 in this document). 1840 14 Reserved 1842 15 Reserved 1844 16 Reserved 1846 2012 1848 17 Reserved 1850 18 ETHERTYPE: The Selector ID represents the 1851 well-known Ethertype. See [ETHERTYPE]. Note 1852 that the Ethertype is usually expressed in 1853 hexadecimal. However, the corresponding 1854 decimal value is used in this Selector ID. 1856 19 LLC: The Selector ID represents the well-known 1857 IEEE 802.2 Link Layer Control (LLC) 1858 Destination Service Access Point (DSAP). See 1859 [LLC]. Note that LLC DSAP is usually expressed 1860 in hexadecimal. However, the corresponding 1861 decimal value is used in this Selector ID. 1863 20 PANA-L7-PEN: Proprietary layer 7 definition, 1864 including a Private Enterprise Number (PEN) 1865 [PEN] to identify that the application 1866 registry being used is not owned by the 1867 Exporter manufacturer (referred to as the 1868 "enterprise" in this document, and identified 1869 by the PEN), or to identify the original 1870 enterprise in the case of a mediator or 3rd 1871 party device. The Selector ID represents the 1872 enterprise unique global ID for the layer 7 1873 applications. The Selector ID has a global 1874 significance for all devices from the same 1875 enterprise. 1876 1877 1878 1880 1886 1887 1889 2012 1891 An attribute that provides a first level 1892 categorization 1893 for each Application Id. 1894 1895 1896 1898 1904 1905 1906 An attribute that provides a second level 1907 categorization for each Application Id. 1908 1909 1910 1912 1918 1919 1920 An attribute that groups multiple Application Ids 1921 that belong to the same networking application. 1922 1923 1924 1926 1932 1933 1934 Specifies if the Application Id is based on peer- 1935 to-peer technology. Possible values are: 1937 2012 1939 { "yes", "y", 1 }, { "no", "n", 2 } and 1940 { "unassigned" , "u", 0 }. 1941 1942 1943 1945 1951 1952 1953 Specifies if the Application Id is used as a 1954 tunnel technology. Possible values are: 1955 { "yes", "y", 1 }, { "no", "n", 2 } and 1956 { "unassigned" , "u", 0 }. 1957 1958 1959 1961 1967 1968 1969 Specifies if the Application Id is an encrypted 1970 networking protocol. Possible values are: 1971 { "yes", "y", 1 }, { "no", "n", 2 } and 1972 { "unassigned" , "u", 0 }. 1973 1974 1975 1977 Appendix B. Port Collisions Tables (non normative) 1979 The following table lists the 10 ports that have different 1980 protocols assigned for TCP and UDP (at the time of writing 1981 this document): 1983 2012 1985 exec 512/tcp remote process execution; 1986 authentication performed 1987 using passwords and UNIX 1988 login names 1990 comsat/biff 512/udp used by mail system to 1991 notify users of new mail 1992 received; currently 1993 receives messages only from 1994 processes on the same 1995 machine 1997 login 513/tcp remote login a la telnet; 1998 automatic authentication 1999 performed based on 2000 priviledged port numbers 2001 and distributed data bases 2002 which identify 2004 "authentication domains" 2005 who 513/udp maintains data bases 2006 showing who's logged in to 2007 machines on a local 2008 net and the load average of 2009 the machine 2011 shell 514/tcp cmd 2012 like exec, but automatic 2013 authentication is performed 2014 as for login server 2016 syslog 514/udp 2018 oob-ws-https 664/tcp DMTF out-of-band secure web 2019 services management 2020 protocol 2021 Jim Davis 2023 2024 June 2007 2026 asf-secure-rmcp 664/udp ASF Secure Remote 2027 Management and Control 2028 Protocol 2030 2012 2032 rfile 750/tcp 2033 kerberos-iv 750/udp kerberos version iv 2035 submit 773/tcp 2036 notify 773/udp 2038 rpasswd 774/tcp 2039 acmaint_dbd 774/udp 2041 entomb 775/tcp 2042 acmaint_transd 775/udp 2044 busboy 998/tcp 2045 puparp 998/udp 2047 garcon 999/tcp 2048 applix 999/udp Applix ac 2050 Table 4: Different Protocols on UDP and TCP 2052 The following table lists the 19 ports that have different 2053 protocols assigned for TCP and SCTP (at the time of writing 2054 this document): 2056 # 3097/tcp Reserved 2058 itu-bicc-stc 3097/sctp ITU-T Q.1902.1/Q.2150.3 2059 Greg Sidebottom 2060 2062 # 5090/tcp 2064 car 5090/sctp Candidate AR 2066 # 5091/tcp 2068 cxtp 5091/sctp Context Transfer Protocol 2069 RFC 4065 - July 2005 2071 # 6704/tcp Reserved 2073 2012 2075 frc-hp 6704/sctp ForCES HP (High Priority) 2076 channel [RFC5811] 2078 # 6705/tcp Reserved 2080 frc-mp 6705/sctp ForCES MP (Medium 2081 Priority) channel 2082 [RFC5811] 2084 # 6706/tcp Reserved 2086 frc-lp 6706/sctp ForCES LP (Low priority) 2087 channel [RFC5811] 2089 # 9082/tcp 2091 lcs-ap 9082/sctp LCS Application Protocol 2092 Kimmo Kymalainen 2093 kimmo.kymalainen&etsi.org> 2094 04 June 2010 2096 # 9902/tcp 2098 enrp-sctp-tls 9902/sctp enrp/tls server channel 2099 [RFC5353] 2101 # 11997/tcp 2102 # 11998/tcp 2103 # 11999/tcp 2105 Wmereceiving 11997/sctp WorldMailExpress 2106 wmedistribution 11998/sctp WorldMailExpress 2107 wmereporting 11999/sctp WorldMailExpress 2108 Greg Foutz 2109 2110 March 2006 2112 # 25471/tcp 2114 rna 25471/sctp RNSAP User Adaptation for 2115 Iurh 2116 Dario S. Tonesi 2117 2118 07 February 2011 2120 2012 2122 # 29118/tcp Reserved 2124 sgsap 29118/sctp SGsAP in 3GPP 2126 # 29168/tcp Reserved 2128 sbcap 29168/sctp SBcAP in 3GPP 2130 # 29169/tcp 2132 iuhsctpassoc 29169/sctp HNBAP and RUA Common 2133 Association 2134 John Meredith 2135 2136 08 September 2009 2138 # 36412/tcp 2140 s1-control 36412/sctp S1-Control Plane (3GPP) 2141 KimmoKymalainen 2142 2143 01 September 2009 2145 # 36422/tcp 2147 x2-control 36422/sctp X2-Control Plane (3GPP) 2148 Kimmo Kymalainen 2149 2150 01 September 2009 2152 # 36443/tcp 2154 m2ap 36443/sctp M2 Application Part 2155 Dario S. Tonesi 2156 2157 07 February 2011 2159 # 36444/tcp 2161 m3ap 36444/sctp M3 Application Part 2162 Dario S. Tonesi 2163 2165 2012 2167 07 February 2011 2169 Table 5: Different Protocols on SCTP and TCP 2171 Appendix C. Application Registry Example (non normative) 2173 A reference to the Cisco Systems assigned numbers for the 2174 Application Id and the different attribute assignments can 2175 be found at [CISCO-APPLICATION-REGISTRY]. 2177 RFC-EDITOR NOTE: at the time of publication, if [CISCO- 2178 APPLICATION-REGISTRY] is not available, this appendix, and 2179 the [CISCO-APPLICATION-REGISTRY] reference must be removed.