idnits 2.17.1 draft-claise-export-application-info-in-ipfix-06.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 4371 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 692, 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-06 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..... 20 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 4: Layer 7 Application....................... 25 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...................................... 30 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................................... 35 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 ..................................................... 12 116 Table 3: IANA layer 4 port collisions between UDP and TCP . 15 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 defined at different OSI layers, from 234 layer 2 to layer 7. For example: Link Layer Distribution 235 Protocol (LLDP) [LLDP] is layer 2 application, ICMP is layer 236 3 application [IANA-PROTO], HTTP is layer 4 application 237 [IANA-PORTS], and skype is layer 7. 239 While an ideal solution would be an IANA registry for 240 applications above (or inside the payload of) the well known 241 ports [IANA-PORTS], this solution is not always possible. 242 Indeed, the specifications for some applications embedded in 243 the payload, for example Skype, are not available. Some 244 reverse engineering as well as a ubiquitous language for 245 application identification, would be two required conditions 246 to be able to manage an IANA registry for these types of 247 applications. Clearly, these are blocking factors. 248 As this specification focuses on the application information 249 encoding, this document doesn't contain an application 250 registry for non IANA applications. However, a reference to 251 the Cisco Systems assigned numbers for the Application Id and 252 the different attribute assignments can be found at [CISCO]. 254 2.1. Application Information Use Cases 256 There are several use cases for application information: 258 1. Application Visibility 260 This is one of the main cases for using the application 261 information. Network administrators are using application 262 visibility to understand the main network consumers, 263 network trends and user behavior. 265 2. Congestion Control 267 While traffic demand is increasing (mainly due to the high 268 usage of peer to peer applications, video applications and 269 web download applications), the providers revenue doesn't 270 grow. Providers are looking at a more efficient way to 271 control and prioritize the network utilization. An 272 application aware bandwidth control system is used to 273 prioritize the traffic based on the applications, giving 274 the critical applications priority over the non-critical 275 applications. 277 3. Security Functions 279 Application knowledge is sometimes used in security 280 functions in order to provide comprehensive functions such 281 as Application based firewall, URL filtering, parental 282 control, intrusion detection, etc. 284 All of the above use cases require exporting application 285 information to provide the network function itself or to log 286 the network function operation. 288 3. Terminology 290 IPFIX-specific terminology used in this document is defined 291 in Section 2 of the IPFIX protocol specification [RFC5101]. 292 As in [RFC5101], these IPFIX-specific terms have the first 293 letter of a word capitalized when used in this document. 295 3.1. New Terminology 297 Application Id 299 A unique identifier for an application. 301 When an application is detected, the most granular application 302 is encoded in the Application Id. 304 4. applicationId Information Element Specification 306 This document specifies the applicationId Information 307 Element, which is composed of two parts: 309 1. 8 bits of Classification Engine ID. The 310 Classification Engine can be considered as a 311 specific registry for application assignments. 312 2. m bits of Selector ID. The Selector ID length varies 313 depending on the Classification Engine ID. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Class. Eng. ID| Selector ID ... | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | ... | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 1: applicationId Information Element 325 Classification Engine ID 327 A unique identifier for the engine which determined the 328 Selector ID. Thus the Classification Engine ID defines 329 the context for the Selector ID. 331 Selector ID 333 A unique identifier of the application for a specific 334 Classification Engine ID. Note that the Selector ID 335 length varies depending on the Classification Engine ID. 337 The Selector ID term is similar to the selectorId 338 Information Element, specified in the PSAMP Protocol 339 [RFC5476]. 341 4.1. Existing Classification Engine IDs 343 The following Classification Engine IDs have been 344 allocated: 346 Name Value Description 348 0 Invalid. 350 IANA-L3 1 The IANA protocol (layer 3 (L3)) 351 number is exported in the 352 Selector ID. 353 See [IANA-PROTO]. 355 PANA-L3 2 Proprietary layer 3 definition. A 356 company can export its own layer 357 3 protocol numbers, while waiting 358 for IANA to assign it. The 359 Selector ID has a global 360 significance for all devices from 361 the same company. Hopefully the 362 same Selector IDs will be 363 maintained after the IANA 364 standardization. 366 IANA-L4 3 The IANA layer 4 (L4) well-known 367 port number is exported in the 368 Selector ID. See [IANA-PORTS]. 369 Note: as an IPFIX flow is 370 unidirectional, it contains the 371 destination port in a flow from 372 the client to the server. 374 PANA-L4 4 Proprietary layer 4 definition. A 375 company can export its own layer 376 4 port numbers, while waiting for 377 IANA to assign it. The Selector 378 ID has global significance for 379 devices from the same company. 380 Hopefully the same Selector IDs 381 will be maintained after the IANA 382 standardization. Example: IPFIX 383 had the port 4739 pre-assigned in 384 the IETF draft for years. While 385 waiting for the RFC and its 386 associated IANA registration, the 387 Selector ID 4739 was used with 388 this PANA-L4. 390 5 Reserved. 392 USER- 6 The Selector ID represents 393 Defined applications defined by the user 394 (using CLI or GUI) based on the 395 methods described in section 2. 396 The Selector ID has a local 397 significance per device. 399 7 Reserved. 401 8 Reserved. 403 9 Reserved. 405 10 Reserved. 407 11 Reserved. 409 PANA-L2 12 Proprietary layer 2 (L2) 410 definition. A company can export 411 its own layer 2 identifiers. The 412 Selector ID represents the 413 company unique global layer 2 414 applications. The Selector ID has 415 a global significance for all 416 devices from the same company. 417 Examples include Cisco Subnetwork 418 Access Protocol (SNAP). 420 PANA-L7 13 Proprietary layer 7 definition. 421 The Selector ID represents the 422 company unique global ID for the 423 layer 7 applications. The 424 Selector ID has a global 425 significance for all devices from 426 the same company. A reference to 427 the Cisco Systems assigned 428 numbers for the layer 7 429 Application Id assignments can be 430 found at [CISCO]. 432 14 Reserved. 434 15 Reserved. 436 16 Reserved. 438 17 Reserved. 440 ETHERTYPE 18 The Selector ID represents the 441 well-known Ethertype. See 442 [ETHERTYPE]. Note that the 443 Ethertype is usually expressed in 444 hexadecimal. However, the 445 corresponding decimal value is 446 used in this Selector ID. 448 LLC 19 The Selector ID represents the 449 well-known IEEE 802.2 Link Layer 450 Control (LLC) Destination Service 451 Access Point (DSAP). See [LLC]. 452 Note that LLC DSAP is usually 453 expressed in hexadecimal. 454 However, the corresponding 455 decimal value is used in this 456 Selector ID. 458 20 to 459 254 Available. 461 MAX 255 255 is the maximum Engine ID. 463 Table 1: Existing Classification Engine IDs 465 Note 1: "PANA = Proprietary Assigned Number Authority". In 466 other words, a company specific version of IANA for 467 internal IDs. 469 The list in table 1 is maintained by IANA thanks to the 470 registry within the classificationEngineId Information 471 Element. See the "IANA Considerations" section. The 472 Classification Engine Id is part of the Application Id 473 encoding, so the classificationEngineId Information Element 474 is currently not required by these specifications. 475 However, this Information Element was created for 476 completeness. 478 4.2. Selector ID Length per Classification IDs 480 As the Selector Id part of the Application Id is variable 481 based on the Classification Engine ID value, the 482 applicationId SHOULD be encoded in a variable-length 483 Information Element [RFC5101] for the IPFIX export. 485 The following table displays the Selector ID default length 486 for the different Classification Engine ID. 488 Classification Selector ID default 489 Engine ID Name length (in bytes) 491 IANA-L3 1 493 PANA-L3 1 495 IANA-L4 2 497 PANA-L4 2 499 USER-Defined 3 501 PANA-L2 5 503 PANA-L7 3 505 ETHERTYPE 2 507 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 683 lcs-ap 9082/sctp LCS Application Protocol 684 Kimmo Kymalainen 686 kimmo.kymalainen&etsi.org> 687 04 June 2010 689 # 9902/tcp 691 enrp-sctp-tls 9902/sctp enrp/tls server channel 692 [RFC5353] 694 # 11997/tcp 695 # 11998/tcp 696 # 11999/tcp 698 wmereceiving 11997/sctp WorldMailExpress 699 wmedistribution 11998/sctp WorldMailExpress 700 wmereporting 11999/sctp WorldMailExpress 701 Greg Foutz 702 703 March 2006 705 # 25471/tcp 707 rna 25471/sctp RNSAP User Adaptation 708 for 709 Iurh 710 Dario S. Tonesi 711 712 07 February 2011 714 # 29118/tcp Reserved 716 sgsap 29118/sctp SGsAP in 3GPP 718 # 29168/tcp Reserved 720 sbcap 29168/sctp SBcAP in 3GPP 722 # 29169/tcp 724 iuhsctpassoc 29169/sctp HNBAP and RUA Common 725 Association 726 John Meredith 727 728 08 September 2009 730 # 36412/tcp 732 s1-control 36412/sctp S1-Control Plane (3GPP) 733 KimmoKymalainen 735 736 01 September 2009 738 # 36422/tcp 740 x2-control 36422/sctp X2-Control Plane (3GPP) 741 Kimmo Kymalainen 743 744 01 September 2009 746 # 36443/tcp 748 m2ap 36443/sctp M2 Application Part 749 Dario S. Tonesi 750 751 07 February 2011 753 # 36444/tcp 755 m3ap 36444/sctp M3 Application Part 756 Dario S. Tonesi 757 758 07 February 2011 760 Table 4: IANA layer 4 port collisions between SCTP and TCP 762 Instead of imposing the transport protocol 763 (UDP/TCP/SCTP/etc.) in the scope of the "Application Name 764 Options Template Record" for all applications (on top of 765 having the transport protocol as key-field in the Flow Record 766 definition), the convention is that the L4 application is 767 always TCP related. So, whenever the Collector has a 768 conflict in looking up IANA, it would choose the TCP choice. 769 As a result, the UDP L4 applications from Table 3 and the 770 SCTP L4 applications from Table 4 are assigned in the PANA_L7 771 Application Id range, i.e. under Classification Engine ID 13. 773 Currently, there are no discrepancies between the well known 774 ports for TCP and DCCP. 776 5. Grouping the Applications with the Attributes 778 Due to the high number of different Application Ids, 779 Application Ids MAY be categorized into groups. This offers 780 the benefits of easier reporting and action, such as QoS 781 policies. Indeed, most applications with the same 782 characteristics should be treated the same way; for example, 783 all video traffic. 785 Attributes are statically assigned per Application Id and are 786 independent of the traffic. The attributes are listed below: 788 Name Description 790 Category An attribute that provides a first 791 level categorization for each 792 Application Id. Examples include: 793 browsing, email, file-sharing, 794 gaming, instant messaging, voice- 795 and-video, etc... 796 The category attribute is encoded by 797 the ApplicationCategoryName 798 Information Element. 800 Sub-Category An attribute that provides a second 801 level categorization for each 802 Application Id. Examples include: 803 backup-systems, client-server, 804 database, routing-protocol, etc... 805 The sub-category attribute is 806 encoded by the 807 ApplicationSubCategoryName 808 Information Element. 810 Application- An attribute that groups multiple 811 Group Application Ids that belong to the 812 same networking application. For 813 example, the ftp-group contain the 814 ftp-data (port 20), ftp (port 20), 815 ni-ftp (port 47), sftp (port 115), 816 bftp (port 152), ftp-agent(port 817 574), ftps-data (port 989). The 818 application-group attribute is 819 encoded by the ApplicationGroupName 820 Information Element. 822 P2P-Technology Specifies if the Application Id is 823 based on peer-to-peer technology. 824 The P2P-technology attribute is 825 encoded by the p2pTechnology 826 Information Element. 828 Tunnel- Specifies if the Application Id is 829 Technology used as a tunnel technology. The 830 tunnel-technology attribute is 831 encoded by the tunnelTechnology 832 Information Element. 834 Encrypted Specifies if the Application Id is 835 an encrypted networking protocol. 836 The encrypted attribute is encoded 837 by the encryptedTechnology 838 Information Element. 840 Table 5: Existing Application Id Static Attributes 842 Every application is assigned to one ApplicationCategoryName, 843 one ApplicationSubCategoryName, one ApplicationGroupName, has 844 one p2pTechnology, one tunnelTechnology, and one 845 encryptedTechnology. 847 Maintaining the attribute values in IANA seems impossible to 848 realize. Therefore the attribute values per application are 849 company specific. For example, the Cisco Systems attribute 850 values for the different applications are available at 851 [CISCO]. 853 5.1. Options Template Record for the Attribute Values 855 An Options Template Record (see [RFC5101]) SHOULD be used to 856 export the correspondence between each Application Id and its 857 related Attribute values. An alternative way for the 858 Collecting Process to learn the correspondence is to populate 859 these mappings out of band, for example, by loading a CSV 860 file containing the correspondence table. 862 The Attributes Option Template contains the ApplicationId as 863 a scope field, followed by the ApplicationCategoryName, the 864 ApplicationSubCategoryName, the ApplicationGroupName, the 865 p2pTechnology, the tunnelTechnology, and the 866 encryptedTechnology Information Elements. 868 A list of attributes may conveniently be exported using a 869 subTemplateList per [RFC6313]. 871 An example is given in section 6.8. below. 873 6. Application Id Examples 875 The following examples are created solely for the purpose of 876 illustrating how the extensions proposed in this document are 877 encoded. 879 6.1. Example 1: Layer 2 Protocol 881 The list of Classification Engine IDs in Table 1 shows that 882 the layer 2 Classification Engine IDs are 12, 18, and 19. 884 From the Ethertype list, LLDP [LLDP] has the Selector ID 885 value 0x88CC, so 35020 in decimal: 887 NAME Selector ID 888 LLDP 35020 890 So, in the case of LLDP, the Classification Engine ID is 18 891 while the Selector ID has the value 35020. 893 Therefore the Application Id is encoded as: 895 0 1 2 896 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | 18 | 35020 | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 So the Application Id has the decimal value of 1214668. The 902 format '18..35020' is used for simplicity in the examples 903 below. 905 The Exporting Process creates a Template Record with a few 906 Information Elements: amongst other things, the Application 907 Id. For example: 909 - applicationId (key field) 910 - octetTotalCount (non key field) 912 For example, a Flow Record corresponding to the above 913 Template Record may contain: 915 { applicationId='18..35020', 916 octetTotalCount=123456 } 918 The Collector has all the required information to determine 919 that the application is LLDP, because the Application Id uses 920 a global and well known registry, i.e. the Ethertype. 921 The Collector can determine which application is represented 922 by the Application Id by loading the registry out of band. 924 6.2. Example 2: Standardized IANA Layer 3 Protocol 926 From the list of Classification Engine IDs in Table 1, the 927 IANA layer 3 Classification Engine ID is 1. 928 From the list of IANA layer 3 protocols (see [IANA-PROTO]), 929 ICMP has the value 1: 931 Decimal Keyword Protocol Reference 932 1 ICMP Internet Control Message [RFC792] 934 So in the case of the standardized IANA layer 3 protocol 935 ICMP, the Classification Engine ID is 1, and the Selector ID 936 has the value of 1. 938 Therefore the Application Id is encoded as: 940 0 1 941 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | 1 | 1 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 So the Application Id has the value of 257. The format 947 '1..1' is used for simplicity in the examples below. 949 The Exporting Process creates a Template Record with a few 950 Information Elements: amongst other things, the Application 951 Id. For example: 953 - sourceIPv4Address (key field) 954 - destinationIPv4Address (key field) 955 - ipDiffServCodePoint (key field) 956 - applicationId (key field) 957 - octetTotalCount (non key field) 959 For example, a Flow Record corresponding to the above 960 Template Record may contain: 962 { sourceIPv4Address=192.0.2.1, 963 destinationIPv4Address=192.0.2.2, 964 ipDiffServCodePoint=0, 965 applicationId='1..1', 966 octetTotalCount=123456 } 968 The Collector has all the required information to determine 969 that the application is ICMP, because the Application Id uses 970 a global and well know registry, ie the IANA L3 protocol 971 number. 973 6.3. Example 3: Proprietary Layer 3 Protocol 975 Assume that a company has specified a new layer 3 protocol 976 called "foo". 978 From the list of Classification Engine IDs in Table 1, the 979 proprietary layer 3 Classification Engine ID is 2. 981 A global registry within the company specifies that the "foo" 982 protocol has the value 90: 984 Protocol Protocol Id 985 foo 90 987 So, in the case of the layer 3 protocol foo, specified by 988 this company, the Classification Engine ID is 2, and the 989 Selector ID has the value of 90. 991 Therefore the Application Id is encoded as: 993 0 1 994 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | 2 | 90 | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 So the Application Id has the value of 602. The format 1000 '2..90' is used for simplicity in the examples below. 1002 The Exporting Process creates a Template Record with a few 1003 Information Elements: amongst other things, the Application 1004 Id. For example: 1006 - sourceIPv4Address (key field) 1007 - destinationIPv4Address (key field) 1008 - ipDiffServCodePoint (key field) 1009 - applicationId (key field) 1010 - octetTotalCount (non key field) 1012 For example, a Flow Record corresponding to the above 1013 Template Record may contain: 1015 { sourceIPv4Address=192.0.2.1, 1016 destinationIPv4Address=192.0.2.2, 1017 ipDiffServCodePoint=0, 1018 applicationId='2..90', 1019 octetTotalCount=123456 } 1021 Along with this Flow Record, a new Options Template Record 1022 would be exported, as shown in Section 6.7. 1024 6.4. Example 4: Standardized IANA Layer 4 Port 1026 From the list of Classification Engine IDs in Table 1, the 1027 IANA layer 4 Classification Engine ID is 3. 1029 From the list of IANA layer 4 ports (see [IANA-PORTS]), SNMP 1030 has the value 161: 1032 Keyword Decimal Description 1033 snmp 161/tcp SNMP 1034 snmp 161/udp SNMP 1035 So in the case of the standardized IANA layer 4 SNMP port, 1036 the Classification Engine ID is 3, and the Selector ID has 1037 the value of 161. 1039 Therefore the Application Id is encoded as: 1041 0 1 1042 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | 3 | 161 | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 So the Application Id has the value of 196769. The format 1048 '2..90' is used for simplicity in the examples below. 1050 The Exporting Process creates a Template Record with a few 1051 Information Elements: amongst other things, the Application 1052 Id. For example: 1054 - sourceIPv4Address (key field) 1055 - destinationIPv4Address (key field) 1056 - protocol (key field) 1057 - ipDiffServCodePoint (key field) 1058 - applicationId (key field) 1059 - octetTotalCount (non key field) 1061 For example, a Flow Record corresponding to the above 1062 Template Record may contain: 1064 { sourceIPv4Address=192.0.2.1, 1065 destinationIPv4Address=192.0.2.2, 1066 protocol=17, ipDiffServCodePoint=0, 1067 applicationId='3..161', 1068 octetTotalCount=123456 } 1070 The Collector has all the required information to determine 1071 that the application is SNMP, because the Application Id uses 1072 a global and well know registry, ie the IANA L4 protocol 1073 number. 1075 6.5. Example 4: Layer 7 Application 1077 In this example, the Metering Process has observed some 1078 Citrix traffic. 1080 From the list of Classification Engine IDs in Table 1, the L7 1081 unique Classification Engine ID is 13. 1082 Suppose that the Metering Process returns the ID 10000 for 1083 Citrix traffic. 1085 So, in the case of this Citrix application, the 1086 Classification Engine ID is 13 and the Selector ID has the 1087 value of 10000. 1089 Therefore the Application Id is encoded as: 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | 13 | 10000 | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 So the Application Id has the value of 218113808. The format 1098 '13..10000' is used for simplicity in the examples below. 1100 The Exporting Process creates a Template Record with a few 1101 Information Elements: amongst other things, the Application 1102 Id. For example: 1104 - sourceIPv4Address (key field) 1105 - destinationIPv4Address (key field) 1106 - ipDiffServCodePoint (key field) 1107 - applicationId (key field) 1108 - octetTotalCount (non key field) 1110 For example, a Flow Record corresponding to the above 1111 Template Record may contain: 1113 { sourceIPv4Address=192.0.2.1, 1114 destinationIPv4Address=192.0.2.2, 1115 ipDiffServCodePoint=0, 1116 applicationId='13..10000', 1117 octetTotalCount=123456 } 1119 The 10000 value is globally unique for the company, so that 1120 the Collector can determine which application is represented 1121 by the Application Id by loading the registry out of band. A 1122 reference to the Cisco Systems assigned numbers for the layer 1123 7 Application Id and the different attribute assignments can 1124 be found at [CISCO]. 1126 Along with this Flow Record, a new Options Template Record 1127 would be exported, as shown in Section 6.7. 1129 6.6. Example: port Obfuscation 1131 For example, an HTTP server might run on a TCP port 23 1132 (assigned to telnet in [IANA-PORTS]). If the Metering Process 1133 is capable of detecting HTTP in the same case, the 1134 Application Id representation must contain HTTP. However, if 1135 the reporting application wants to determine whether or not 1136 the default HTTP port 80 or 8080 was used, the destination 1137 port (destinationTransportPort at [IANA-IPFIX]) must also be 1138 exported in the corresponding IPFIX record. 1140 In the case of a standardized IANA layer 4 port, the 1141 Classification Engine ID is 2, and the Selector ID has the 1142 value of 80 for HTTP (see [IANA-PORTS]). 1144 Therefore the Application Id is encoded as: 1146 0 1 2 1147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | 3 | 80 | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 The Exporting Process creates a Template Record with a few 1153 Information Elements: amongst other things, the Application 1154 Id. For example: 1156 - sourceIPv4Address (key field) 1157 - destinationIPv4Address (key field) 1158 - protocol (key field) 1159 - destinationTransportPort (key field) 1160 - applicationId (key field) 1161 - octetTotalCount (non key field) 1163 For example, a Flow Record corresponding to the above 1164 Template Record may contain: 1166 { sourceIPv4Address=192.0.2.1, 1167 destinationIPv4Address=192.0.2.2, 1168 protocol=17, 1169 destinationTransportPort=23, 1170 applicationId='3..80', 1171 octetTotalCount=123456 } 1173 The Collector has all the required information to determine 1174 that the application is HTTP, but runs on port 23. 1176 6.7. Example: Application Mapping Options Template 1178 Along with the Flow Records shown in the above examples, a 1179 new Options Template Record would be exported to express the 1180 Application Name and Application Description associated with 1181 each Application Id. 1183 The Options Template Record contains the following 1184 Information Elements: 1186 1. Scope = applicationId. 1188 From RFC 5101: "The scope, which is only available in 1189 the Options Template Set, gives the context of the 1190 reported Information Elements in the Data Records." 1192 2. applicationName. 1194 3. applicationDescription. 1196 The Options Data Record associated with the examples above 1197 would contain, for example: 1199 { scope=applicationId='2..90', 1200 applicationName="foo", 1201 applicationDescription="The foo protocol", 1203 scope=applicationId='13..10000', 1204 applicationName="Citrix", 1205 applicationDescription="A Citrix application" } 1207 When combined with the example Flow Records above, these 1208 Options Template Records tell the Collector: 1210 1. A flow of 123456 bytes exists from sourceIPv4Address 1211 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1212 applicationId of '12..90', which maps to the "foo" 1213 application. 1215 2. A flow of 123456 bytes exists from sourceIPv4Address 1216 192.0.2.1 to destinationIPv4address 192.0.2.2 with an 1217 Application Id of '13..10000', which maps to the "Citrix" 1218 application. 1220 6.8. Example: Attributes Values Options Template Record 1222 Along with the Flow Records shown in the above examples, a 1223 new Options Template Record is exported to express the values 1224 of the different attributes related to the Application Ids. 1226 The Options Template Record would contain the following 1227 Information Elements: 1229 1. Scope = applicationId. 1231 From RFC 5101: "The scope, which is only available in 1232 the Options Template Set, gives the context of the 1233 reported Information Elements in the Data Records." 1235 2. applicationCategoryName. 1237 3. applicationSubCategoryName. 1239 4. applicationGroupName 1241 5. p2pTechnology 1243 6. tunnelTechnology 1245 7. encryptedTechnology 1247 The Options Data Record associated with the examples above 1248 would contain, for example: 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 characterized 1265 by the relevant attributes values. 1267 7. IANA Considerations 1269 7.1. New Information Elements 1271 This document specifies 10 new IPFIX Information Elements: the 1272 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: the XML specification in Appendix A must be 1281 updated with the elementID values allocated below. 1283 RFC-EDITOR/IANA-EDITOR: some entries are already present in 1284 IPFIX-IANA. However, those must be updated with the current 1285 content. 1287 7.1.1. applicationDescription 1289 Name: applicationDescription 1290 Description: 1291 Specifies the description of an application. 1292 Abstract Data Type: string 1293 Data Type Semantics: 1294 ElementId: 94 1295 Status: current 1297 7.1.2. applicationId 1299 Name: applicationId 1300 Description: 1301 Specifies an Application Id. 1302 Abstract Data Type: octetArray 1303 Data Type Semantics: identifier 1304 Reference: See section 4. of [EDITORS NOTE: this document] for 1305 the applicationId Information Element Specification. 1306 ElementId: 95 1307 Status: current 1309 7.1.3. applicationName 1311 Name: applicationName 1312 Description: 1313 Specifies the name of an application. 1314 Abstract Data Type: string 1315 Data Type Semantics: 1316 ElementId: 96 1317 Status: current 1319 7.1.4. classificationEngineId 1321 Name: classificationEngineId 1322 Description: 1323 A unique identifier for the engine which determined the 1324 Selector ID. Thus the Classification Engine ID defines the 1325 context for the Selector ID. The Classification Engine can 1326 be considered as a specific registry for application 1327 assignments. 1329 Initial values for this field are listed below. Further 1330 values may be assigned by IANA in the Classification Engine 1331 Ids registry. 1333 0 Invalid. 1335 1 IANA-L3: The IANA protocol (layer 3) number is 1336 exported in the Selector ID. See 1337 http://www.iana.org/assignments/protocol-numbers. 1339 2 PANA-L3: Proprietary layer 3 definition. A company 1340 can export its own layer 3 protocol numbers, while 1341 waiting for IANA to assign it. The Selector ID has a 1342 global significance for all devices from the same 1343 company. Hopefully the same Selector IDs will be 1344 maintained after the IANA standardization. 1346 3 IANA-L4: The IANA layer 4 well-known port number is 1347 exported in the Selector ID. See 1348 http://www.iana.org/assignments/port-numbers. Note: 1350 as an IPFIX flow is unidirectional, it contains the 1351 destination port in a flow from the client to the 1352 server. 1354 4 PANA-L4: Proprietary layer 4 definition. A company 1355 can export its own layer 4 port numbers, while 1356 waiting for IANA to assign it. The Selector ID has 1357 global significance for devices from the same 1358 company. Hopefully the same Selector IDs will be 1359 maintained after the IANA standardization. Example: 1360 IPFIX had the port 4739 pre-assigned in the IETF 1361 draft for years. While waiting for the RFC and its 1362 associated IANA registration, the Selector ID 4739 1363 was used with this PANA-L4. 1365 5 Reserved 1367 6 USER-Defined: The Selector ID represents 1368 applications defined by the user (using CLI or GUI) 1369 based on the methods described in section 2. The 1370 Selector ID has a local significance per device. 1372 7 Reserved 1374 8 Reserved 1376 9 Reserved 1378 10 Reserved 1380 11 Reserved 1382 12 PANA-L2: Proprietary layer 2 definition. A company 1383 can export its own layer 2 identifiers. The 1384 Selector ID represents the company unique global 1385 layer 2 applications. The Selector ID has a global 1386 significance for all devices from the same company. 1387 Examples include Cisco Subnetwork Access Protocol 1388 (SNAP). 1390 13 PANA-L7: Proprietary layer 7 definition. The 1391 Selector ID represents the company unique global ID 1392 for the layer 7 applications. The Selector ID has a 1393 global significance for all devices from the same 1394 company. 1396 14 Reserved 1397 15 Reserved 1399 16 Reserved 1401 17 Reserved 1403 18 ETHERTYPE: The Selector ID represents the 1404 well-known Ethertype. See 1405 http://standards.ieee.org/develop/regauth/ethertype/ 1406 eth.txt. Note that the Ethertype is usually 1407 expressed in hexadecimal. However, the corresponding 1408 decimal value is used in this Selector ID. 1410 19 LLC: The Selector ID represents the well-known IEEE 1411 802.2 Link Layer Control (LLC) Destination Service 1412 Access Point (DSAP). See 1413 http://standards.ieee.org/develop/regauth/ethertype/ 1414 eth.txt. Note that LLC DSAP is usually expressed in 1415 hexadecimal. However, the corresponding decimal 1416 value is used in this Selector ID. 1418 Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17), 1419 are reserved to be compliant with existing 1420 implementations already using the 1421 classificationEngineId. 1423 Abstract Data Type: unsigned8 1424 Data Type Semantics: identifier 1425 ElementId: 101 1426 Status: current 1428 7.1.5. applicationCategoryName 1430 Name: applicationCategoryName 1431 Description: 1432 An attribute that provides a first level categorization for 1433 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 1478 technology. 1479 Possible values are: { "yes", "y", 1 }, { "no", "n", 2 } and 1480 { "unassigned" , "u", 0 }. 1481 Abstract Data Type: string 1482 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