idnits 2.17.1 draft-claise-export-application-info-in-ipfix-07.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 573 has weird spacing: '...512/tcp rem...' == Line 578 has weird spacing: '...512/udp use...' == Line 586 has weird spacing: '...513/tcp rem...' == Line 595 has weird spacing: '...513/udp mai...' == Line 603 has weird spacing: '...514/tcp cmd...' == (2 more instances...) -- The document date (May 5, 2012) is 4374 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 679, but not defined == Missing Reference: 'RFC5353' is mentioned on line 691, 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: August 20, 2012 Cisco Systems, Inc. 6 May 5, 2012 8 Export of Application Information in IPFIX 9 draft-claise-export-application-info-in-ipfix-07 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance 14 with the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of 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 accessed 31 at http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 20, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as 38 the document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date 43 of publication of this document. Please review these 44 documents carefully, as they describe your rights and 45 restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD 47 License text as described in Section 4.e of the Trust Legal 48 Provisions and are provided without warranty as described in 49 the Simplified BSD License. 51 Abstract 53 This document specifies an extension to the IPFIX information 54 model specified in [RFC5102] to export application 55 information. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 60 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 61 "OPTIONAL" in this document are to be interpreted as 62 described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Overview................................................... 4 67 1.1. IPFIX Documents Overview.............................. 4 68 2. Introduction............................................... 5 69 2.1. Application Information Use Cases........................ 7 70 3. Terminology................................................ 8 71 3.1. New Terminology....................................... 8 72 4. applicationId Information Element Specification............ 8 73 4.1. Existing Classification Engine IDs.................... 9 74 4.2. Selector ID Length per Classification IDs............ 12 75 4.3. Application Name Options Template Record............. 13 76 4.4. Resolving IANA L4 port collisions.................... 14 77 5. Grouping the Applications with the Attributes............. 19 78 5.1. Options Template Record for the Attribute Values..... 21 79 6. Application Id Examples................................... 21 80 6.1. Example 1: Layer 2 Protocol.......................... 21 81 6.2. Example 2: Standardized IANA Layer 3 Protocol........ 22 82 6.3. Example 3: Proprietary Layer 3 Protocol.............. 23 83 6.4. Example 4: Standardized IANA Layer 4 Port............ 24 84 6.5. Example 5: Layer 7 Application....................... 26 85 6.6. Example: port Obfuscation............................ 27 86 6.7. Example: Application Mapping Options Template........ 28 87 6.8. Example: Attributes Values Options Template Record... 29 88 7. IANA Considerations....................................... 30 89 7.1. New Information Elements............................. 30 90 7.1.1. applicationDescription............................. 30 91 7.1.2. applicationId...................................... 31 92 7.1.3. applicationName.................................... 31 93 7.1.4. classificationEngineId............................. 31 94 7.1.5. applicationCategoryName............................ 33 95 7.1.6. applicationSubCategoryName......................... 34 96 7.1.7. applicationGroupName............................... 34 97 7.1.8. p2pTechnology...................................... 34 98 7.1.9. tunnelTechnology................................... 34 99 7.1.10. encryptedTechnology............................... 35 100 7.2. Classification Engine Ids Registry................... 35 101 8. Security Considerations................................... 36 102 9. References................................................ 36 103 9.1. Normative References................................. 36 104 9.2. Informative References............................... 36 105 10. Acknowledgement.......................................... 38 106 11. Authors' Addresses....................................... 39 107 Appendix A. Additions to XML Specification of IPFIX 108 Information Elements......................................... 39 110 List of Figures and Tables 112 Figure 1: applicationId Information Element ................ 8 113 Table 1: Existing Classification Engine IDs ............... 11 114 Table 2: Selector ID default length per Classification Engine 115 ID ..................................................... 13 116 Table 3: IANA layer 4 port collisions between UDP and TCP . 16 117 Table 4: IANA layer 4 port collisions between SCTP and TCP 18 118 Table 5: Existing Application Id Static Attributes ........ 20 120 1. Overview 122 1.1. IPFIX Documents Overview 124 The IPFIX Protocol [RFC5101] provides network administrators 125 with access to IP Flow information. 127 The architecture for the export of measured IP Flow information 128 out of an IPFIX Exporting Process to a Collecting Process is 129 defined in the IPFIX Architecture [RFC5470], per the 130 requirements defined in RFC 3917 [RFC3917]. 132 The IPFIX Architecture [RFC5470] specifies how IPFIX Data 133 Records and Templates are carried via a congestion-aware 134 transport protocol from IPFIX Exporting Processes to IPFIX 135 Collecting Processes. 137 IPFIX has a formal description of IPFIX Information Elements, 138 their name, type and additional semantic information, as 139 specified in the IPFIX information model [RFC5102]. 141 In order to gain a level of confidence in the IPFIX 142 implementation, probe the conformity and robustness, and allow 143 interoperability, the Guidelines for IPFIX Testing [RFC5471] 144 presents a list of tests for implementers of compliant 145 Exporting Processes and Collecting Processes. 147 The Bidirectional Flow Export [RFC5103] specifies a method for 148 exporting bidirectional flow (biflow) information using the IP 149 Flow Information Export (IPFIX) protocol, representing each 150 Biflow using a single Flow Record. 152 The "Reducing Redundancy in IP Flow Information Export 153 (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] 154 specifies a bandwidth saving method for exporting Flow or 155 packet information, by separating information common to 156 several Flow Records from information specific to an 157 individual Flow Record: common Flow information is exported 158 only once. 160 2. Introduction 162 Today service providers and network administrators are 163 looking for visibility into the packet content rather than 164 just the packet header. Some network devices Metering 165 Processes inspect the packet content and identify the 166 applications that are utilizing the network traffic. 167 Applications in this context are defined as networking 168 protocols used by networking processes that exchange packets 169 between them (such as web applications, peer to peer 170 applications, file transfer, e-mail applications, etc.). 171 Applications can be further characterized by other 172 information elements, some of which are application specific. 173 Examples include: web application to a specific domain, per 174 user specific traffic, a video application with a specific 175 codec, etc... 177 The application identification is based on several different 178 methods or even a combination of methods: 179 1. L2 (Layer 2) protocols (such as ARP (Address Resolution 180 Protocol), PPP (Point-to-Point Protocol), LLDP (Link Layer 181 Discovery Protocol)) 182 2. IP protocols (such as ICMP (Internet Control Message 183 Protocol), IGMP (Internet Group Management Protocol), GRE 184 (Generic Routing Encapsulation) 185 3. TCP or UDP ports (such as HTTP, Telnet, FTP) 186 4. Application layer header (of the application to be 187 identified) 188 5. Packet data content 189 6. Packets and traffic behavior 191 The exact application identification methods are part of the 192 Metering Process internals that aim to provide an accurate 193 identification with a minimum false identification. This 194 task requires a sophisticated Metering Process since the 195 protocols do not behave in a standard manner. 197 1. Applications use port obfuscation where the 198 application runs on different port than the IANA 199 assigned one. For example an HTTP server might run 200 a TCP port 23 (assigned to telnet in [IANA-PORTS]) 202 2. IANA port registries do not accurately reflect how 203 certain ports are "commonly" used today. Some ports 204 are reserved, but the application either never 205 became prevalent or is not in use today. 207 3. The application behavior and identification logic 208 become more and more complex 210 For that reason, such Metering Processes usually detect 211 applications based on multiple mechanisms in parallel. 212 Detection based only on port matching might wrongly identify 213 the application. Note that this example stresses the need for 214 the engine strength. If the Metering Process is capable of 215 detecting applications more accurately, it is considered to be 216 stronger and more accurate. 218 Similarly, a reporting mechanism that uses L4 port based 219 applications only, such as L4:, would have 220 similar issues. The reporting system should be capable of 221 reporting the applications classified using all types of 222 mechanisms. In particular applications that do not have any 223 IANA port definition. While a mechanism to export 224 application information should be defined, the L4 port being 225 in use must be exported using the destination port 226 (destinationTransportPort at [IANA-IPFIX]) in the 227 corresponding IPFIX record. 229 This document specifies the Application Id (as described in 230 section 4. ) to export the application information with the 231 IPFIX protocol [RFC5101]. 233 Applications could be identified at different OSI layers, 234 from layer 2 to layer 7. For example: Link Layer 235 Distribution Protocol (LLDP) [LLDP] can be identified in 236 layer 2, ICMP can be identified in layer 3 [IANA-PROTO], HTTP 237 can be identified in layer 4 [IANA-PORTS], and skype can be 238 identified in layer 7. 240 While an ideal solution would be an IANA registry for 241 applications above (or inside the payload of) the well known 242 ports [IANA-PORTS], this solution is not always possible. 244 Indeed, the specifications for some applications embedded in 245 the payload, for example Skype, are not available. Some 246 reverse engineering as well as a ubiquitous language for 247 application identification, would be two required conditions 248 to be able to manage an IANA registry for these types of 249 applications. Clearly, these are blocking factors. 250 As this specification focuses on the application information 251 encoding, this document doesn't contain an application 252 registry for non IANA applications. However, a reference to 253 the Cisco Systems assigned numbers for the Application Id and 254 the different attribute assignments can be found at [CISCO]. 256 2.1. Application Information Use Cases 258 There are several use cases for application information: 260 1. Application Visibility 262 This is one of the main cases for using the application 263 information. Network administrators are using application 264 visibility to understand the main network consumers, 265 network trends and user behavior. 267 2. Congestion Control 269 While traffic demand is increasing (mainly due to the high 270 usage of peer to peer applications, video applications and 271 web download applications), the providers revenue doesn't 272 grow. Providers are looking at a more efficient way to 273 control and prioritize the network utilization. An 274 application aware bandwidth control system is used to 275 prioritize the traffic based on the applications, giving 276 the critical applications priority over the non-critical 277 applications. 279 3. Security Functions 281 Application knowledge is sometimes used in security 282 functions in order to provide comprehensive functions such 283 as Application based firewall, URL filtering, parental 284 control, intrusion detection, etc. 286 All of the above use cases require exporting application 287 information to provide the network function itself or to log 288 the network function operation. 290 3. Terminology 292 IPFIX-specific terminology used in this document is defined 293 in Section 2 of the IPFIX protocol specification [RFC5101]. 294 As in [RFC5101], these IPFIX-specific terms have the first 295 letter of a word capitalized when used in this document. 297 3.1. New Terminology 299 Application Id 301 A unique identifier for an application. 303 When an application is detected, the most granular application 304 is encoded in the Application Id. 306 4. applicationId Information Element Specification 308 This document specifies the applicationId Information 309 Element, which is composed of two parts: 311 1. 8 bits of Classification Engine ID. The 312 Classification Engine can be considered as a 313 specific registry for application assignments. 314 2. m bits of Selector ID. The Selector ID length varies 315 depending on the Classification Engine ID. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Class. Eng. ID| Selector ID ... | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | ... | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 1: applicationId Information Element 327 Classification Engine ID 328 A unique identifier for the engine which determined the 329 Selector ID. Thus the Classification Engine ID defines 330 the context for the Selector ID. 332 Selector ID 334 A unique identifier of the application for a specific 335 Classification Engine ID. Note that the Selector ID 336 length varies depending on the Classification Engine ID. 338 The Selector ID term is similar to the selectorId 339 Information Element, specified in the PSAMP Protocol 340 [RFC5476]. 342 4.1. Existing Classification Engine IDs 344 The following Classification Engine IDs have been 345 allocated: 347 Name Value Description 349 0 Invalid. 351 IANA-L3 1 The IANA protocol (layer 3 (L3)) 352 number is exported in the 353 Selector ID. 354 See [IANA-PROTO]. 356 PANA-L3 2 Proprietary layer 3 definition. A 357 company can export its own layer 358 3 protocol numbers, while waiting 359 for IANA to assign it. The 360 Selector ID has a global 361 significance for all devices from 362 the same company. Hopefully the 363 same Selector IDs will be 364 maintained after the IANA 365 standardization. 367 IANA-L4 3 The IANA layer 4 (L4) well-known 368 port number is exported in the 369 Selector ID. See [IANA-PORTS]. 370 Note: as an IPFIX flow is 371 unidirectional, it contains the 372 destination port in a flow from 373 the client to the server. 375 PANA-L4 4 Proprietary layer 4 definition. A 376 company can export its own layer 377 4 port numbers, while waiting for 378 IANA to assign it. The Selector 379 ID has global significance for 380 devices from the same company. 381 Hopefully the same Selector IDs 382 will be maintained after the IANA 383 standardization. Example: IPFIX 384 had the port 4739 pre-assigned in 385 the IETF draft for years. While 386 waiting for the RFC and its 387 associated IANA registration, the 388 Selector ID 4739 was used with 389 this PANA-L4. 391 5 Reserved. 393 USER- 6 The Selector ID represents 394 Defined applications defined by the user 395 (using CLI or GUI) based on the 396 methods described in section 2. 397 The Selector ID has a local 398 significance per device. 400 7 Reserved. 402 8 Reserved. 404 9 Reserved. 406 10 Reserved. 408 11 Reserved. 410 PANA-L2 12 Proprietary layer 2 (L2) 411 definition. A company can export 412 its own layer 2 identifiers. The 413 Selector ID represents the 414 company unique global layer 2 415 applications. The Selector ID has 416 a global significance for all 417 devices from the same company. 418 Examples include Cisco Subnetwork 419 Access Protocol (SNAP). 421 PANA-L7 13 Proprietary layer 7 definition. 422 The Selector ID represents the 423 company unique global ID for the 424 layer 7 applications. The 425 Selector ID has a global 426 significance for all devices from 427 the same company. A reference to 428 the Cisco Systems assigned 429 numbers for the layer 7 430 Application Id assignments can be 431 found at [CISCO]. 433 14 Reserved. 435 15 Reserved. 437 16 Reserved. 439 17 Reserved. 441 ETHERTYPE 18 The Selector ID represents the 442 well-known Ethertype. See 443 [ETHERTYPE]. Note that the 444 Ethertype is usually expressed in 445 hexadecimal. However, the 446 corresponding decimal value is 447 used in this Selector ID. 449 LLC 19 The Selector ID represents the 450 well-known IEEE 802.2 Link Layer 451 Control (LLC) Destination Service 452 Access Point (DSAP). See [LLC]. 453 Note that LLC DSAP is usually 454 expressed in hexadecimal. 455 However, the corresponding 456 decimal value is used in this 457 Selector ID. 459 20 to 460 254 Available. 462 MAX 255 255 is the maximum Engine ID. 464 Table 1: Existing Classification Engine IDs 466 Note 1: "PANA = Proprietary Assigned Number Authority". In 467 other words, a company specific version of IANA for 468 internal IDs. 470 The list in table 1 is maintained by IANA thanks to the 471 registry within the classificationEngineId Information 472 Element. See the "IANA Considerations" section. The 473 Classification Engine Id is part of the Application Id 474 encoding, so the classificationEngineId Information Element 475 is currently not required by these specifications. 476 However, this Information Element was created for 477 completeness. 479 4.2. Selector ID Length per Classification IDs 481 As the Selector Id part of the Application Id is variable 482 based on the Classification Engine ID value, the 483 applicationId SHOULD be encoded in a variable-length 484 Information Element [RFC5101] for the IPFIX export. 486 The following table displays the Selector ID default length 487 for the different Classification Engine ID. 489 Classification Selector ID default 490 Engine ID Name length (in bytes) 492 IANA-L3 1 494 PANA-L3 1 496 IANA-L4 2 498 PANA-L4 2 500 USER-Defined 3 502 PANA-L2 5 504 PANA-L7 3 506 ETHERTYPE 2 508 LLC 1 509 Table 2: Selector ID default length 510 per Classification Engine ID 512 If a legacy protocol such as NetFlow version 9 [RFC3954] is 513 used, and this protocol doesn't support variable length 514 Information Elements, then either multiple Template Records 515 (one per applicationId length), or a single Template Record 516 corresponding to the maximum sized applicationId MUST be 517 used. 519 Application Ids MAY be encoded in a smaller number of bytes, 520 following the same rules as for the IPFIX Reduced Size 521 Encoding [RFC5101]. 523 Application Ids MAY be encoded with a larger length. 524 For example, a normal IANA L3 protocol encoding would take 2 525 bytes since the Selector ID represents protocol field from 526 the IP header encoded in one byte. However, an IANA L3 527 protocol encoding may be encoded with 3 bytes. In such a 528 case, the Selector ID value MUST always be encoded in the 529 least significant bits as shown in Figure 2. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 |Class. Eng. ID | zero-valued upper-bits ... | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | ... Selector ID | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 2: Selector ID encoding 541 4.3. Application Name Options Template Record 543 For Classification Engines which specify locally unique 544 Application Ids (which means unique per engine and per 545 router), an Options Template Record (see [RFC5101]) MUST be 546 used to export the correspondence between the Application 547 Id, the Application Name, and the Application Description. 548 For Classification Engines which specify globally unique 549 Application Ids, an Options Template Record MAY be used to 550 export the correspondence between the Application Id, the 551 Application Name and the Application Description, unless 552 the mapping is hardcoded in the Collector, or known out of 553 band (for example, by polling a MIB). 555 Enterprises may assign company-wide Application Id values 556 for the PANA-L7 Classification Engine. In this case, a 557 possible optimization for the Collector is to keep the 558 mappings between the Application Ids and the Application 559 Names per enterprise, as opposed to per Exporter. The 560 mechanism for the Collector to know about Exporter 561 enterprise IDs is out of scope of this document. Possible 562 tracks are: SNMP polling, an Options Template export, 563 hardcoded value, etc. 565 4.4. Resolving IANA L4 port collisions 567 Even though the IANA L4 ports usually point to the same 568 protocols for both UDP, TCP or other transport types, there 569 are some exceptions. The following table lists the 10 570 ports that have different protocols assigned for TCP and 571 UDP (at the time of writing this document): 573 exec 512/tcp remote process execution; 574 authentication performed 575 using passwords and UNIX 576 login names 578 comsat/biff 512/udp used by mail system to 579 notify users of new mail 580 received; currently 581 receives messages only 582 from 583 processes on the same 584 machine 586 login 513/tcp remote login a la telnet; 587 automatic authentication 588 performed based on 589 priviledged port numbers 590 and distributed data 591 bases 592 which identify 594 "authentication domains" 595 who 513/udp maintains data bases 596 showing who's logged in 597 to 598 machines on a local 599 net and the load average 600 of 601 the machine 603 shell 514/tcp cmd 604 like exec, but automatic 605 authentication is 606 performed 607 as for login server 609 syslog 514/udp 611 oob-ws-https 664/tcp DMTF out-of-band secure 612 web 613 services management 614 protocol 615 Jim Davis 617 618 June 2007 620 asf-secure-rmcp 664/udp ASF Secure Remote 621 Management and Control 622 Protocol 624 rfile 750/tcp 625 kerberos-iv 750/udp kerberos version iv 627 submit 773/tcp 628 notify 773/udp 630 rpasswd 774/tcp 631 acmaint_dbd 774/udp 633 entomb 775/tcp 634 acmaint_transd 775/udp 636 busboy 998/tcp 637 puparp 998/udp 639 garcon 999/tcp 640 applix 999/udp Applix ac 642 Table 3: IANA layer 4 port collisions between UDP and TCP 644 The following table lists the 19 ports that have different 645 protocols assigned for TCP and SCTP (at the time of writing 646 this document): 648 # 3097/tcp Reserved 650 itu-bicc-stc 3097/sctp ITU-T Q.1902.1/Q.2150.3 651 Greg Sidebottom 652 654 # 5090/tcp 656 car 5090/sctp Candidate AR 658 # 5091/tcp 660 cxtp 5091/sctp Context Transfer 661 Protocol 662 RFC 4065 - July 2005 664 # 6704/tcp Reserved 666 frc-hp 6704/sctp ForCES HP (High 667 Priority) 668 channel [RFC5811] 670 # 6705/tcp Reserved 672 frc-mp 6705/sctp ForCES MP (Medium 673 Priority) channel 674 [RFC5811] 676 # 6706/tcp Reserved 678 frc-lp 6706/sctp ForCES LP (Low priority) 679 channel [RFC5811] 681 # 9082/tcp 682 lcs-ap 9082/sctp LCS Application Protocol 683 Kimmo Kymalainen 685 kimmo.kymalainen&etsi.org> 686 04 June 2010 688 # 9902/tcp 690 enrp-sctp-tls 9902/sctp enrp/tls server channel 691 [RFC5353] 693 # 11997/tcp 694 # 11998/tcp 695 # 11999/tcp 697 wmereceiving 11997/sctp WorldMailExpress 698 wmedistribution 11998/sctp WorldMailExpress 699 wmereporting 11999/sctp WorldMailExpress 700 Greg Foutz 701 702 March 2006 704 # 25471/tcp 706 rna 25471/sctp RNSAP User Adaptation 707 for 708 Iurh 709 Dario S. Tonesi 710 711 07 February 2011 713 # 29118/tcp Reserved 715 sgsap 29118/sctp SGsAP in 3GPP 717 # 29168/tcp Reserved 719 sbcap 29168/sctp SBcAP in 3GPP 721 # 29169/tcp 722 iuhsctpassoc 29169/sctp HNBAP and RUA Common 723 Association 724 John Meredith 725 726 08 September 2009 728 # 36412/tcp 730 s1-control 36412/sctp S1-Control Plane (3GPP) 731 KimmoKymalainen 733 734 01 September 2009 736 # 36422/tcp 738 x2-control 36422/sctp X2-Control Plane (3GPP) 739 Kimmo Kymalainen 741 742 01 September 2009 744 # 36443/tcp 746 m2ap 36443/sctp M2 Application Part 747 Dario S. Tonesi 748 749 07 February 2011 751 # 36444/tcp 753 m3ap 36444/sctp M3 Application Part 754 Dario S. Tonesi 755 756 07 February 2011 758 Table 4: IANA layer 4 port collisions between SCTP and TCP 760 Instead of imposing the transport protocol 761 (UDP/TCP/SCTP/etc.) in the scope of the "Application Name 762 Options Template Record" for all applications (on top of 763 having the transport protocol as key-field in the Flow Record 764 definition), the convention is that the L4 application is 765 always TCP related. So, whenever the Collector has a 766 conflict in looking up IANA, it would choose the TCP choice. 767 As a result, the UDP L4 applications from Table 3 and the 768 SCTP L4 applications from Table 4 are assigned in the PANA_L7 769 Application Id range, i.e. under Classification Engine ID 13. 771 Currently, there are no discrepancies between the well known 772 ports for TCP and DCCP. 774 5. Grouping the Applications with the Attributes 776 Due to the high number of different Application Ids, 777 Application Ids MAY be categorized into groups. This offers 778 the benefits of easier reporting and action, such as QoS 779 policies. Indeed, most applications with the same 780 characteristics should be treated the same way; for example, 781 all video traffic. 783 Attributes are statically assigned per Application Id and are 784 independent of the traffic. The attributes are listed below: 786 Name Description 788 Category An attribute that provides a first 789 level categorization for each 790 Application Id. Examples include: 791 browsing, email, file-sharing, 792 gaming, instant messaging, voice- 793 and-video, etc... 794 The category attribute is encoded by 795 the ApplicationCategoryName 796 Information Element. 798 Sub-Category An attribute that provides a second 799 level categorization for each 800 Application Id. Examples include: 801 backup-systems, client-server, 802 database, routing-protocol, etc... 803 The sub-category attribute is 804 encoded by the 805 ApplicationSubCategoryName 806 Information Element. 808 Application- An attribute that groups multiple 809 Group Application Ids that belong to the 810 same networking application. For 811 example, the ftp-group contain the 812 ftp-data (port 20), ftp (port 20), 813 ni-ftp (port 47), sftp (port 115), 814 bftp (port 152), ftp-agent(port 815 574), ftps-data (port 989). The 816 application-group attribute is 817 encoded by the ApplicationGroupName 818 Information Element. 820 P2P-Technology Specifies if the Application Id is 821 based on peer-to-peer technology. 822 The P2P-technology attribute is 823 encoded by the p2pTechnology 824 Information Element. 826 Tunnel- Specifies if the Application Id is 827 Technology used as a tunnel technology. The 828 tunnel-technology attribute is 829 encoded by the tunnelTechnology 830 Information Element. 832 Encrypted Specifies if the Application Id is 833 an encrypted networking protocol. 834 The encrypted attribute is encoded 835 by the encryptedTechnology 836 Information Element. 838 Table 5: Existing Application Id Static Attributes 840 Every application is assigned to one ApplicationCategoryName, 841 one ApplicationSubCategoryName, one ApplicationGroupName, has 842 one p2pTechnology, one tunnelTechnology, and one 843 encryptedTechnology. 845 Maintaining the attribute values in IANA seems impossible to 846 realize. Therefore the attribute values per application are 847 company specific. For example, the Cisco Systems attribute 848 values for the different applications are available at 849 [CISCO]. 851 5.1. Options Template Record for the Attribute Values 853 An Options Template Record (see [RFC5101]) SHOULD be used to 854 export the correspondence between each Application Id and its 855 related Attribute values. An alternative way for the 856 Collecting Process to learn the correspondence is to populate 857 these mappings out of band, for example, by loading a CSV 858 file containing the correspondence table. 860 The Attributes Option Template contains the ApplicationId as 861 a scope field, followed by the ApplicationCategoryName, the 862 ApplicationSubCategoryName, the ApplicationGroupName, the 863 p2pTechnology, the tunnelTechnology, and the 864 encryptedTechnology Information Elements. 866 A list of attributes may conveniently be exported using a 867 subTemplateList per [RFC6313]. 869 An example is given in section 6.8. below. 871 6. Application Id Examples 873 The following examples are created solely for the purpose of 874 illustrating how the extensions proposed in this document are 875 encoded. 877 6.1. Example 1: Layer 2 Protocol 879 The list of Classification Engine IDs in Table 1 shows that 880 the layer 2 Classification Engine IDs are 12, 18, and 19. 882 From the Ethertype list, LLDP [LLDP] has the Selector ID 883 value 0x88CC, so 35020 in decimal: 885 NAME Selector ID 886 LLDP 35020 888 So, in the case of LLDP, the Classification Engine ID is 18 889 while the Selector ID has the value 35020. 891 Therefore the Application Id is encoded as: 893 0 1 2 894 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | 18 | 35020 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 So the Application Id has the decimal value of 1214668. The 900 format '18..35020' is used for simplicity in the examples 901 below. 903 The Exporting Process creates a Template Record with a few 904 Information Elements: amongst other things, the Application 905 Id. For example: 907 - applicationId (key field) 908 - octetTotalCount (non key field) 910 For example, a Flow Record corresponding to the above 911 Template Record may contain: 913 { applicationId='18..35020', 914 octetTotalCount=123456 } 916 The Collector has all the required information to determine 917 that the application is LLDP, because the Application Id uses 918 a global and well known registry, i.e. the Ethertype. 919 The Collector can determine which application is represented 920 by the Application Id by loading the registry out of band. 922 6.2. Example 2: Standardized IANA Layer 3 Protocol 924 From the list of Classification Engine IDs in Table 1, the 925 IANA layer 3 Classification Engine ID is 1. 926 From the list of IANA layer 3 protocols (see [IANA-PROTO]), 927 ICMP has the value 1: 929 Decimal Keyword Protocol Reference 930 1 ICMP Internet Control Message [RFC792] 932 So in the case of the standardized IANA layer 3 protocol 933 ICMP, the Classification Engine ID is 1, and the Selector ID 934 has the value of 1. 936 Therefore the Application Id is encoded as: 938 0 1 939 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | 1 | 1 | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 So the Application Id has the value of 257. The format 945 '1..1' is used for simplicity in the examples below. 947 The Exporting Process creates a Template Record with a few 948 Information Elements: amongst other things, the Application 949 Id. For example: 951 - sourceIPv4Address (key field) 952 - destinationIPv4Address (key field) 953 - ipDiffServCodePoint (key field) 954 - applicationId (key field) 955 - octetTotalCount (non key field) 957 For example, a Flow Record corresponding to the above 958 Template Record may contain: 960 { sourceIPv4Address=192.0.2.1, 961 destinationIPv4Address=192.0.2.2, 962 ipDiffServCodePoint=0, 963 applicationId='1..1', 964 octetTotalCount=123456 } 966 The Collector has all the required information to determine 967 that the application is ICMP, because the Application Id uses 968 a global and well know registry, ie the IANA L3 protocol 969 number. 971 6.3. Example 3: Proprietary Layer 3 Protocol 973 Assume that a company has specified a new layer 3 protocol 974 called "foo". 976 From the list of Classification Engine IDs in Table 1, the 977 proprietary layer 3 Classification Engine ID is 2. 979 A global registry within the company specifies that the "foo" 980 protocol has the value 90: 982 Protocol Protocol Id 983 foo 90 985 So, in the case of the layer 3 protocol foo, specified by 986 this company, the Classification Engine ID is 2, and the 987 Selector ID has the value of 90. 989 Therefore the Application Id is encoded as: 991 0 1 992 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | 2 | 90 | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 So the Application Id has the value of 602. The format 998 '2..90' is used for simplicity in the examples below. 1000 The Exporting Process creates a Template Record with a few 1001 Information Elements: amongst other things, the Application 1002 Id. For example: 1004 - sourceIPv4Address (key field) 1005 - destinationIPv4Address (key field) 1006 - ipDiffServCodePoint (key field) 1007 - applicationId (key field) 1008 - octetTotalCount (non key field) 1010 For example, a Flow Record corresponding to the above 1011 Template Record may contain: 1013 { sourceIPv4Address=192.0.2.1, 1014 destinationIPv4Address=192.0.2.2, 1015 ipDiffServCodePoint=0, 1016 applicationId='2..90', 1017 octetTotalCount=123456 } 1019 Along with this Flow Record, a new Options Template Record 1020 would be exported, as shown in Section 6.7. 1022 6.4. Example 4: Standardized IANA Layer 4 Port 1024 From the list of Classification Engine IDs in Table 1, the 1025 IANA layer 4 Classification Engine ID is 3. 1027 From the list of IANA layer 4 ports (see [IANA-PORTS]), SNMP 1028 has the value 161: 1030 Keyword Decimal Description 1031 snmp 161/tcp SNMP 1032 snmp 161/udp SNMP 1034 So in the case of the standardized IANA layer 4 SNMP port, 1035 the Classification Engine ID is 3, and the Selector ID has 1036 the value of 161. 1038 Therefore the Application Id is encoded as: 1040 0 1 1041 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | 3 | 161 | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 So the Application Id has the value of 196769. The format 1047 '2..90' is used for simplicity in the examples below. 1049 The Exporting Process creates a Template Record with a few 1050 Information Elements: amongst other things, the Application 1051 Id. For example: 1053 - sourceIPv4Address (key field) 1054 - destinationIPv4Address (key field) 1055 - protocol (key field) 1056 - ipDiffServCodePoint (key field) 1057 - applicationId (key field) 1058 - octetTotalCount (non key field) 1060 For example, a Flow Record corresponding to the above 1061 Template Record may contain: 1063 { sourceIPv4Address=192.0.2.1, 1064 destinationIPv4Address=192.0.2.2, 1065 protocol=17, ipDiffServCodePoint=0, 1066 applicationId='3..161', 1067 octetTotalCount=123456 } 1069 The Collector has all the required information to determine 1070 that the application is SNMP, because the Application Id uses 1071 a global and well know registry, ie the IANA L4 protocol 1072 number. 1074 6.5. Example 5: Layer 7 Application 1076 In this example, the Metering Process has observed some 1077 Citrix traffic. 1079 From the list of Classification Engine IDs in Table 1, the L7 1080 unique Classification Engine ID is 13. 1081 Suppose that the Metering Process returns the ID 10000 for 1082 Citrix traffic. 1084 So, in the case of this Citrix application, the 1085 Classification Engine ID is 13 and the Selector ID has the 1086 value of 10000. 1088 Therefore the Application Id is encoded as: 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | 13 | 10000 | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 So the Application Id has the value of 218113808. The format 1097 '13..10000' is used for simplicity in the examples below. 1099 The Exporting Process creates a Template Record with a few 1100 Information Elements: amongst other things, the Application 1101 Id. For example: 1103 - sourceIPv4Address (key field) 1104 - destinationIPv4Address (key field) 1105 - ipDiffServCodePoint (key field) 1106 - applicationId (key field) 1107 - octetTotalCount (non key field) 1109 For example, a Flow Record corresponding to the above 1110 Template Record may contain: 1112 { sourceIPv4Address=192.0.2.1, 1113 destinationIPv4Address=192.0.2.2, 1114 ipDiffServCodePoint=0, 1115 applicationId='13..10000', 1116 octetTotalCount=123456 } 1118 The 10000 value is globally unique for the company, so that 1119 the Collector can determine which application is represented 1120 by the Application Id by loading the registry out of band. A 1121 reference to the Cisco Systems assigned numbers for the layer 1122 7 Application Id and the different attribute assignments can 1123 be found at [CISCO]. 1125 Along with this Flow Record, a new Options Template Record 1126 would be exported, as shown in Section 6.7. 1128 6.6. Example: port Obfuscation 1130 For example, an HTTP server might run on a TCP port 23 1131 (assigned to telnet in [IANA-PORTS]). If the Metering Process 1132 is capable of detecting HTTP in the same case, the 1133 Application Id representation must contain HTTP. However, if 1134 the reporting application wants to determine whether or not 1135 the default HTTP port 80 or 8080 was used, the destination 1136 port (destinationTransportPort at [IANA-IPFIX]) must also be 1137 exported in the corresponding IPFIX record. 1139 In the case of a standardized IANA layer 4 port, the 1140 Classification Engine ID is 2, and the Selector ID has the 1141 value of 80 for HTTP (see [IANA-PORTS]). 1143 Therefore the Application Id is encoded as: 1145 0 1 2 1146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | 3 | 80 | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 The Exporting Process creates a Template Record with a few 1152 Information Elements: amongst other things, the Application 1153 Id. For example: 1155 - sourceIPv4Address (key field) 1156 - destinationIPv4Address (key field) 1157 - protocol (key field) 1158 - destinationTransportPort (key field) 1159 - applicationId (key field) 1160 - octetTotalCount (non key field) 1162 For example, a Flow Record corresponding to the above 1163 Template Record may contain: 1165 { sourceIPv4Address=192.0.2.1, 1166 destinationIPv4Address=192.0.2.2, 1167 protocol=17, 1168 destinationTransportPort=23, 1169 applicationId='3..80', 1170 octetTotalCount=123456 } 1172 The Collector has all the required information to determine 1173 that the application is HTTP, but runs on port 23. 1175 6.7. Example: Application Mapping Options Template 1177 Along with the Flow Records shown in the above examples, a 1178 new Options Template Record would be exported to express the 1179 Application Name and Application Description associated with 1180 each Application Id. 1182 The Options Template Record contains the following 1183 Information Elements: 1185 1. Scope = applicationId. 1187 From RFC 5101: "The scope, which is only available in 1188 the Options Template Set, gives the context of the 1189 reported Information Elements in the Data Records." 1191 2. applicationName. 1193 3. applicationDescription. 1195 The Options Data Record associated with the examples above 1196 would contain, for example: 1198 { scope=applicationId='2..90', 1199 applicationName="foo", 1200 applicationDescription="The foo protocol", 1202 scope=applicationId='13..10000', 1203 applicationName="Citrix", 1204 applicationDescription="A Citrix application" } 1206 When combined with the example Flow Records above, these 1207 Options Template Records tell the Collector: 1209 1. A flow of 123456 bytes exists from sourceIPv4Address 1210 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1211 applicationId of '12..90', which maps to the "foo" 1212 application. 1214 2. A flow of 123456 bytes exists from sourceIPv4Address 1215 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1216 Application Id of '13..10000', which maps to the "Citrix" 1217 application. 1219 6.8. Example: Attributes Values Options Template Record 1221 Along with the Flow Records shown in the above examples, a 1222 new Options Template Record is exported to express the values 1223 of the different attributes related to the Application Ids. 1225 The Options Template Record would contain the following 1226 Information Elements: 1228 1. Scope = applicationId. 1230 From RFC 5101: "The scope, which is only available in 1231 the Options Template Set, gives the context of the 1232 reported Information Elements in the Data Records." 1234 2. applicationCategoryName. 1236 3. applicationSubCategoryName. 1238 4. applicationGroupName 1240 5. p2pTechnology 1242 6. tunnelTechnology 1244 7. encryptedTechnology 1246 The Options Data Record associated with the examples above 1247 would contain, for example: 1249 { scope=applicationId='2..90', 1250 applicationCategoryName="foo-category", 1251 applicationSubCategoryName="foo-subcategory", 1252 applicationGroupName="foo-group", 1253 p2pTechnology=NO 1254 tunnelTechnology=YES 1255 encryptedTechnology=NO 1257 When combined with the example Flow Records above, these 1258 Options Template Records tell the Collector: 1260 A flow of 123456 bytes exists from sourceIPv4Address 1261 192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP 1262 value of 0 and an applicationId of '12..90', which maps to 1263 the "foo" application. This application can be characterized 1264 by the relevant attributes values. 1266 7. IANA Considerations 1268 7.1. New Information Elements 1270 This document specifies 10 new IPFIX Information Elements: the 1271 applicationDescription, applicationId, applicationName, 1272 classificationEngineId, applicationCategoryName, 1273 applicationSubCategoryName, applicationGroupName, 1274 p2pTechnology, tunnelTechnology, and encryptedTechnology. 1276 New Information Elements to be added to the IPFIX Information 1277 Element registry at [IANA-IPFIX] are listed below. 1279 EDITOR'S NOTE: the XML specification in Appendix A must be 1280 updated with the elementID values allocated below. 1282 RFC-EDITOR/IANA-EDITOR: some entries are already present in 1283 IPFIX-IANA. However, those must be updated with the current 1284 content. 1286 7.1.1. applicationDescription 1288 Name: applicationDescription 1289 Description: 1290 Specifies the description of an application. 1291 Abstract Data Type: string 1292 Data Type Semantics: 1293 ElementId: 94 1294 Status: current 1296 7.1.2. applicationId 1298 Name: applicationId 1299 Description: 1300 Specifies an Application Id. 1301 Abstract Data Type: octetArray 1302 Data Type Semantics: identifier 1303 Reference: See section 4. of [EDITORS NOTE: this document] for 1304 the applicationId Information Element Specification. 1305 ElementId: 95 1306 Status: current 1308 7.1.3. applicationName 1310 Name: applicationName 1311 Description: 1312 Specifies the name of an application. 1313 Abstract Data Type: string 1314 Data Type Semantics: 1315 ElementId: 96 1316 Status: current 1318 7.1.4. classificationEngineId 1320 Name: classificationEngineId 1321 Description: 1322 A unique identifier for the engine which determined the 1323 Selector ID. Thus the Classification Engine ID defines the 1324 context for the Selector ID. The Classification Engine can 1325 be considered as a specific registry for application 1326 assignments. 1328 Initial values for this field are listed below. Further 1329 values may be assigned by IANA in the Classification Engine 1330 Ids registry. 1332 0 Invalid. 1334 1 IANA-L3: The IANA protocol (layer 3) number is 1335 exported in the Selector ID. See 1336 http://www.iana.org/assignments/protocol-numbers. 1338 2 PANA-L3: Proprietary layer 3 definition. A company 1339 can export its own layer 3 protocol numbers, while 1340 waiting for IANA to assign it. The Selector ID has a 1341 global significance for all devices from the same 1342 company. Hopefully the same Selector IDs will be 1343 maintained after the IANA standardization. 1345 3 IANA-L4: The IANA layer 4 well-known port number is 1346 exported in the Selector ID. See 1347 http://www.iana.org/assignments/port-numbers. Note: 1348 as an IPFIX flow is unidirectional, it contains the 1349 destination port in a flow from the client to the 1350 server. 1352 4 PANA-L4: Proprietary layer 4 definition. A company 1353 can export its own layer 4 port numbers, while 1354 waiting for IANA to assign it. The Selector ID has 1355 global significance for devices from the same 1356 company. Hopefully the same Selector IDs will be 1357 maintained after the IANA standardization. Example: 1358 IPFIX had the port 4739 pre-assigned in the IETF 1359 draft for years. While waiting for the RFC and its 1360 associated IANA registration, the Selector ID 4739 1361 was used with this PANA-L4. 1363 5 Reserved 1365 6 USER-Defined: The Selector ID represents 1366 applications defined by the user (using CLI or GUI) 1367 based on the methods described in section 2. The 1368 Selector ID has a local significance per device. 1370 7 Reserved 1372 8 Reserved 1374 9 Reserved 1376 10 Reserved 1378 11 Reserved 1380 12 PANA-L2: Proprietary layer 2 definition. A company 1381 can export its own layer 2 identifiers. The 1382 Selector ID represents the company unique global 1383 layer 2 applications. The Selector ID has a global 1384 significance for all devices from the same company. 1385 Examples include Cisco Subnetwork Access Protocol 1386 (SNAP). 1388 13 PANA-L7: Proprietary layer 7 definition. The 1389 Selector ID represents the company unique global ID 1390 for the layer 7 applications. The Selector ID has a 1391 global significance for all devices from the same 1392 company. 1394 14 Reserved 1396 15 Reserved 1398 16 Reserved 1400 17 Reserved 1402 18 ETHERTYPE: The Selector ID represents the 1403 well-known Ethertype. See 1404 http://standards.ieee.org/develop/regauth/ethertype/ 1405 eth.txt. Note that the Ethertype is usually 1406 expressed in hexadecimal. However, the corresponding 1407 decimal value is used in this Selector ID. 1409 19 LLC: The Selector ID represents the well-known IEEE 1410 802.2 Link Layer Control (LLC) Destination Service 1411 Access Point (DSAP). See 1412 http://standards.ieee.org/develop/regauth/ethertype/ 1413 eth.txt. Note that LLC DSAP is usually expressed in 1414 hexadecimal. However, the corresponding decimal 1415 value is used in this Selector ID. 1417 Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17), 1418 are reserved to be compliant with existing 1419 implementations already using the 1420 classificationEngineId. 1422 Abstract Data Type: unsigned8 1423 Data Type Semantics: identifier 1424 ElementId: 101 1425 Status: current 1427 7.1.5. applicationCategoryName 1429 Name: applicationCategoryName 1430 Description: 1431 An attribute that provides a first level categorization for 1432 each Application Id. 1434 Abstract Data Type: string 1435 Data Type Semantics: 1436 ElementId: 1437 Status: current 1439 7.1.6. applicationSubCategoryName 1441 Name: applicationSubCategoryName 1442 Description: 1443 An attribute that provides a second level categorization for 1444 each Application Id. 1445 Abstract Data Type: string 1446 Data Type Semantics: 1447 ElementId: 1448 Status: current 1450 7.1.7. applicationGroupName 1452 Name: applicationGroupName 1453 Description: 1454 An attribute that groups multiple Application Ids that belong 1455 to the same networking application. 1456 Abstract Data Type: string 1457 Data Type Semantics: 1458 ElementId: 1459 Status: current 1461 7.1.8. p2pTechnology 1463 Name: p2pTechnology 1464 Description: 1465 Specifies if the Application Id is based on peer-to-peer 1466 technology. Possible values are: { "yes", "y", 1 }, 1467 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1468 Abstract Data Type: string 1469 Data Type Semantics: 1470 ElementId: 288 1471 Status: current 1473 7.1.9. tunnelTechnology 1475 Name: tunnelTechnology 1476 Description: 1477 Specifies if the Application Id is used as a tunnel 1479 technology. 1480 Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } and 1481 { "unassigned" , "u", 0 }. 1482 Abstract Data Type: string 1483 Data Type Semantics: 1484 ElementId: 289 1485 Status: current 1487 7.1.10. encryptedTechnology 1489 Name: encryptedTechnology 1490 Description: 1491 Specifies if the Application Id is an encrypted networking 1492 protocol. Possible values are: { "yes", "y", 1 }, 1493 { "no", "n", 2 } and { "unassigned" , "u", 0 }. 1494 Abstract Data Type: string 1495 Data Type Semantics: 1496 ElementId: 290 1497 Status: current 1499 7.2. Classification Engine Ids Registry 1501 The Information Element #101, named classificationEngineId, 1502 carries information about the context for the Selector ID, and 1503 can be considered as a specific registry for application 1504 assignments. For ensuring extensibility of this information, 1505 IANA has created a new registry for Classification Engine Ids 1506 and filled it with the initial list from the description 1507 Information Element #101, classificationEngineId. 1509 New assignments for Classification Engine Ids will be 1510 administered by IANA through Expert Review [RFC5226], i.e., 1511 review by one of a group of experts designated by an IETF Area 1512 Director. The group of experts must double check the new 1513 definitions with already defined Classification Engine Ids for 1514 completeness, accuracy, and redundancy. The specification of 1515 Classification Engine Ids MUST be published using a well- 1516 established and persistent publication medium. 1518 RFC-EDITOR: this should be assigned similarly to 1519 mplsTopLabelType subregistry at 1520 http://www.iana.org/assignments/ipfix/ipfix.xml 1522 8. Security Considerations 1524 The same security considerations as for the IPFIX Protocol 1525 [RFC5101] apply. 1527 As mentioned in Section 2.1. , the application knowledge is 1528 useful in security based applications. Security applications 1529 may impose supplementary requirements on the export of 1530 application information, and these need to be examined on a 1531 case by case basis. 1533 9. References 1535 9.1. Normative References 1537 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1538 Requirement Levels, BCP 14, RFC 2119, March 1997. 1540 [RFC5101] Claise, B., Ed., "Specification of the IP Flow 1541 Information Export (IPFIX) Protocol for the Exchange 1542 of IP Traffic Flow Information", RFC 5101, January 1543 2008. 1545 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., 1546 and J. Meyer, "Information Model for IP Flow 1547 Information Export", RFC 5102, January 2008. 1549 [RFC5226] Narten, T., and H. Alverstrand, "Guidelines for 1550 Writing an IANA Considerations Section in RFCs", RFC 1551 5226, May 2008 1553 [ETHERTYPE] 1554 http://standards.ieee.org/develop/regauth/ethertype/e 1555 th.txt 1557 [LLC] 1558 http://standards.ieee.org/develop/regauth/llc/public. 1559 html. 1561 9.2. Informative References 1563 [RFC792] J. Postel, Internet Control Message Protocol, RFC 1564 792, September 1981. 1566 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 1567 Requirements for IP Flow Information Export, RFC 1568 3917, October 2004. 1570 [RFC3954] B. Claise, "Cisco Systems NetFlow Services Export 1571 Version 9", RFC 3954, October 2004. 1573 [RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow 1574 Export Using IP Flow Information Export (IPFIX)", RFC 1575 5103, January 2008. 1577 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 1578 Quittek, "Architecture for IP Flow Information 1579 Export", RFC 5470, March 2009. 1581 [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines 1582 for IP Flow Information Export (IPFIX) Testing", RFC 1583 5471, March 2009. 1585 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 1586 Redundancy in IP Flow Information Export (IPFIX) and 1587 Packet Sampling (PSAMP) Reports", RFC 5473, March 1588 2009. 1590 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol 1591 Specifications", RFC 5476, March 2009. 1593 [RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S. 1594 Yates, "Export of Structured Data in IP Flow 1595 Information Export (IPFIX)", RFC6313, July 20111 1597 [LLDP] "IEEE Std 802.1AB-2005, Standard for Local and 1598 metropolitan area networks - Station and Media Access 1599 Control Connectivity Discovery", IEEE Std 802.1AB- 1600 2005 IEEE Std, 2005. 1602 [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xml 1604 [IANA-PORTS] http://www.iana.org/assignments/port-numbers 1606 [IANA-PROTO] http://www.iana.org/assignments/protocol-numbers 1608 [CISCO] http://www.cisco.com 1610 10. Acknowledgement 1612 The authors would like to thank their many colleagues across 1613 Cisco Systems who made this work possible. Specifically Patrick 1614 Wildi for his time and expertise. 1616 11. Authors' Addresses 1618 Benoit Claise 1619 Cisco Systems, Inc. 1620 De Kleetlaan 6a b1 1621 Diegem 1813 1622 Belgium 1624 Phone: +32 2 704 5622 1625 EMail: bclaise@cisco.com 1627 Paul Aitken 1628 Cisco Systems, Inc. 1629 96 Commercial Quay 1630 Commercial Street 1631 Edinburgh, EH6 6LX, United Kingdom 1633 Phone: +44 131 561 3616 1634 EMail: paitken@cisco.com 1636 Nir Ben-Dvora 1637 Cisco Systems, Inc. 1638 32 HaMelacha St., 1639 P.O.Box 8735, I.Z.Sapir 1640 South Netanya, 42504 1641 Israel 1643 Phone: +972 9 892 7187 1644 EMail: nirbd@cisco.com 1646 Appendix A. Additions to XML Specification of IPFIX 1647 Information Elements 1649 This appendix contains additions to the machine-readable 1650 description of the IPFIX information model coded in XML in 1651 Appendix A and Appendix B in [RFC5102]. Note that this 1652 appendix is of informational nature, while the text in 1653 Section 7. (generated from this appendix) is normative. 1655 The following field definitions are appended to the IPFIX 1656 information model in Appendix A of [RFC5102]. 1658 1662 1663 1664 Specifies the description of an application. 1665 1666 1667 1669 1674 1675 1676 Specifies an Application Id. 1677 1678 1679 1680 1681 See section 4. of [EDITORS NOTE: this document] for 1682 the applicationId Information Element Specification. 1683 1684 1685 1687 1691 1692 1693 Specifies the name of an application. 1694 1695 1696 1698 1704 1705 1706 A unique identifier for the engine which 1707 determined the Selector ID. Thus the 1708 Classification Engine ID defines the context for 1709 the Selector ID. The Classification Engine can be 1710 considered as a specific registry for application 1711 assignments. 1713 Initial values for this field are listed below. 1714 Further values may be assigned by IANA in the 1715 Classification Engine Ids registry. 1717 0 Invalid. 1719 1 IANA-L3: The IANA protocol (layer 3) number is 1720 exported in the Selector ID. See 1721 http://www.iana.org/assignments/protocol-numbers. 1723 2 PANA-L3: Proprietary layer 3 definition. A 1724 company can export its own layer 3 protocol 1725 numbers, while waiting for IANA to assign it. The 1726 Selector ID has a global significance for all 1727 devices from the same company. Hopefully the same 1728 Selector IDs will be maintained after the IANA 1729 standardization. 1731 3 IANA-L4: The IANA layer 4 well-known port 1732 number is exported in the Selector ID. See 1733 http://www.iana.org/assignments/port-numbers. 1734 Note: as an IPFIX flow is unidirectional, it 1735 contains the destination port in a flow from the 1736 client to the server. 1738 4 PANA-L4: Proprietary layer 4 definition. A 1739 company can export its own layer 4 port numbers, 1740 while waiting for IANA to assign it. The Selector 1741 ID has global significance for devices from the 1742 same company. Hopefully the same Selector IDs 1743 will be maintained after the IANA 1744 standardization. Example: IPFIX had the port 4739 1745 pre-assigned in the IETF draft for years. While 1746 waiting for the RFC and its associated IANA 1747 registration, the Selector ID 4739 was used with 1748 this PANA-L4. 1750 5 Reserved 1751 6 USER-Defined: The Selector ID represents 1752 applications defined by the user (using CLI or 1753 GUI) based on the methods described in section 2. 1754 The Selector ID has a local significance per 1755 device. 1757 7 Reserved 1759 8 Reserved 1761 9 Reserved 1763 10 1764 Reserved 1766 11 1767 Reserved 1769 12 PANA-L2: Proprietary layer 2 definition. A 1770 company can export its own layer 2 identifiers. 1771 The Selector ID represents the company unique 1772 global layer 2 applications. The Selector ID has 1773 a global significance for all devices from the 1774 same company. Examples include Cisco Subnetwork 1775 Access Protocol (SNAP). 1777 13 PANA-L7: Proprietary layer 7 definition. The 1778 Selector ID represents the company unique global 1779 ID for the layer 7 applications. The Selector ID 1780 has a global significance for all devices from 1781 the same company. 1783 14 Reserved 1785 15 Reserved 1787 16 Reserved 1789 17 Reserved 1791 18 ETHERTYPE: The Selector ID represents the 1792 well-known Ethertype. See 1793 http://standards.ieee.org/develop/regauth/etherty 1794 pe/eth.txt. Note that the Ethertype is usually 1795 expressed in hexadecimal. However, the 1796 corresponding decimal value is used in this 1797 Selector ID. 1799 19 LLC: The Selector ID represents the 1800 well-known IEEE 802.2 Link Layer Control (LLC) 1801 Destination Service Access Point (DSAP). See 1802 http://standards.ieee.org/develop/regauth/etherty 1803 pe/eth.txt. Note that LLC DSAP is usually 1804 expressed in hexadecimal. However, the 1805 corresponding decimal value is used in this 1806 Selector ID. 1807 1808 1809 1811 1817 1818 1819 An attribute that provides a first level 1820 categorization 1821 for each Application Id. 1822 1823 1824 1826 1832 1833 1834 An attribute that provides a second level 1835 categorization for each Application Id. 1836 1837 1838 1840 1847 1848 1849 An attribute that groups multiple Application Ids 1850 that belong to the same networking application. 1851 1852 1853 1855 1861 1862 1863 Specifies if the Application Id is based on peer- 1864 to-peer technology. Possible values are: 1865 { "yes", "y", 1 }, { "no", "n", 2 } and 1866 { "unassigned" , "u", 0 }. 1867 1868 1869 1871 1877 1878 1879 Specifies if the Application Id is used as a 1880 tunnel technology. Possible values are: 1881 { "yes", "y", 1 }, { "no", "n", 2 } and 1882 { "unassigned" , "u", 0 }. 1883 1884 1885 1887 1893 1894 1895 Specifies if the Application Id is an encrypted 1896 networking protocol. Possible values are: 1897 { "yes", "y", 1 }, { "no", "n", 2 } and 1898 { "unassigned" , "u", 0 }. 1899 1900 1901