idnits 2.17.1 draft-penno-sfc-appid-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2016) is 2801 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-04) exists of draft-quinn-sfc-nsh-tlv-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Netmod R. Penno 3 Internet-Draft B. Claise 4 Intended status: Standards Track C. Pignataro 5 Expires: February 16, 2017 Cisco 6 C. Fontaine 7 Qosmos 8 August 15, 2016 10 Using Application Identification in Services Function Chaining Metadata 11 draft-penno-sfc-appid-05 13 Abstract 15 This document defines the use of a structured application information 16 in the service function chaining metadata, and specifies a YANG model 17 for the configuration of the application registry. 19 The consumers of application information are Service Functions that 20 apply policy and provide application statistics based on the metadata 21 contained in the packet. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 16, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Application Information Structure . . . . . . . . . . . . . . 4 62 4. Application Information Yang Model . . . . . . . . . . . . . 5 63 4.1. Module Structure . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Application Information Configuration Module . . . . . . 6 65 5. Service Function Chaining Metadata . . . . . . . . . . . . . 11 66 6. Relationship to existing YANG Modules . . . . . . . . . . . . 11 67 7. Expected Usage . . . . . . . . . . . . . . . . . . . . . . . 12 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 71 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 12. Informative References . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Open Issues 77 1. Relationship of this YANG module and draft-penno-sfc-yang 79 2. Any reasons why those attributes are not modeled as boolean: P2P- 80 technology, tunnel-technology, encrypted? 82 3. The connection between the YANG Model in this document and 83 [I-D.penno-sfc-yang] must be explained 85 2. Introduction 87 As described in the Service Function Architecture [RFC7665], Service 88 Functions are provide specific treatment for packets and are part of 89 the end-to-end delivery of services. Many of these network services 90 include application-specific functions, treatments, and 91 optimizations. 93 The SFC Encapsulation, Network Service Header (NSH), therefore needs 94 to provide with dynamic, flexible, and easily methods to bind service 95 policy to granular traffic information, which includes application 96 information. This is achieved by the ability to carry metadata along 97 the service function path, which is derived from various sources. 98 (e.g., orchestration systems, DPI Classification, etc.) The 99 consumers of this application information are Service Functions that 100 apply policy and provide application statistics based on this 101 metadata contained in the packet. 103 This document concerns itself with defining structured application 104 information in the service function chaining metadata. 106 The "Cisco Systems Export of Application Information in IP Flow 107 Information Export (IPFIX) [RFC6759] specifies an extension to the 108 IPFIX information model [RFC7012] to export application information. 109 This IPFIX information element is registered as the identifier 95 in 110 the IPFIX registry [IANA-IPFIX]. Applications could be identified at 111 different OSI layers, from layer 2 to layer 7. For example, the Link 112 Layer Distribution Protocol [LLDP] can be identified in layer 2, ICMP 113 can be identified in layer 3 [IANA-PROTO], HTTP can be identified in 114 layer 4 [IANA-PORTS], and Webex can be identified in layer 7. 115 However, the layer 7 application registry values are out of scope of 116 [RFC6759] 118 This document purposes the use of IPFIX [RFC7011] application 119 information to be carried in the NSH MD-Type 1 context metadata 120 [I-D.ietf-sfc-nsh]. Optionally, encoding for NSH MD-Type 2 is 121 provided with the Application ID TLV [I-D.quinn-sfc-nsh-tlv]. The 122 information in the metadata will be provided by an orchestration 123 system or the result of packet processing done by a firewall, 124 Intrusion Protection Service (IPS), Deep Packet Inspection (DPI), 125 amongst others. These are defined as providers of application 126 information. 128 2.1. Terminology 130 The reader should be familiar with the terms contained in the 131 following documents: 133 o Section 1.4 of the "Service Function Chaining (SFC) Architecture" 134 [RFC7665] 136 o Section 2.1 of the "Network Service Header" [I-D.ietf-sfc-nsh] 138 o The "Generic Protocol Extension for VXLAN" 139 [I-D.ietf-nvo3-vxlan-gpe] 141 o Sections 3 and 3.1 of "Cisco Systems Export of Application 142 Information in IP Flow Information Export (IPFIX)" [RFC6759] 144 2.2. Tree Diagrams 146 A simplified graphical representation of the data model is used in 147 this document. The meaning of the symbols in these diagrams is as 148 follows: 150 The meaning of the symbols in these diagrams is as follows: 152 o Brackets "[" and "]" enclose list keys. 154 o Curly braces "{" and "}" contain names of optional features that 155 make the corresponding node conditional. 157 o Abbreviations before data node names: "rw" means configuration 158 (read-write), "ro" state data (read-only), "-x" RPC operations, 159 and "-n" notifications. 161 o Symbols after data node names: "?" means an optional node, "!" a 162 container with presence, and "*" denotes a "list" or "leaf-list". 164 o Parentheses enclose choice and case nodes, and case nodes are also 165 marked with a colon (":"). 167 o Ellipsis ("...") stands for contents of subtrees that are not 168 shown. 170 3. Application Information Structure 172 The application information data structure can be seen in Figure 1. 173 It was extracted and adapted from [RFC6759]. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Class. Eng. ID| Zero-valued upper-bits ... Selector ID | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 1: Application Identification Data Format 183 Table 1 displays the currently allocated Classification Engine IDs, 184 including their name and value, as well as their corresponding 185 Selector ID default length. 187 +---------------------+--------------------+------------------------+ 188 | Classification | Classification | Selector ID default | 189 | Engine ID Value | Engine ID Name | length (in octets) | 190 +---------------------+--------------------+------------------------+ 191 | 1 | IANA-L3 | 1 | 192 +---------------------+--------------------+------------------------+ 193 | 2 | PANA-L3 | 1 | 194 +---------------------+--------------------+------------------------+ 195 | 3 | IANA-L4 | 2 | 196 +---------------------+--------------------+------------------------+ 197 | 4 | PANA-L4 | 2 | 198 +---------------------+--------------------+------------------------+ 199 | 6 | USER-Defined | 3 | 200 +---------------------+--------------------+------------------------+ 201 | 12 | PANA-L2 | 5 | 202 +---------------------+--------------------+------------------------+ 203 | 13 | PANA-L7 | 3 | 204 +---------------------+--------------------+------------------------+ 205 | 18 | ETHERTYPE | 2 | 206 +---------------------+--------------------+------------------------+ 207 | 19 | LLC | 1 | 208 +---------------------+--------------------+------------------------+ 209 | 20 | PANA-L7-PEN | 3 (*) | 210 +---------------------+--------------------+------------------------+ 212 Table 1: Existing Classification Engine IDs 214 Where: 216 "PANA = Proprietary Assigned Number Authority". In other words, 217 an enterprise specific version of IANA for internal IDs. 219 PEN = Private Enterprise Number 221 (*) There are an extra 4 bytes for the PEN. However, the PEN is 222 not considered part of the Selector ID. 224 Section 6 of [RFC6759] provides various illustrative examples of the 225 encoding for different applications. 227 4. Application Information Yang Model 229 4.1. Module Structure 230 module: ietf-ipfix-application-information 231 +--rw class-id-dictionary 232 | +--rw class-id* [name] 233 | +--rw id? uint8 234 | +--rw name string 235 | +--rw description? string 236 +--rw application-id-dictionary 237 +--rw application-id* [application-name] 238 +--rw class-id -> /class-id-dictionary/class-id/id 239 +--rw pen uint32 240 +--rw selector-id uint32 241 +--rw application-name string 242 +--rw application-description? string 243 +--rw application-category-name? string 244 +--rw application-sub-category-name? string 245 +--rw application-group-name? string 247 4.2. Application Information Configuration Module 249 file "ietf-ipfix-application-information@2015-04-28.yang" 251 module ietf-ipfix-application-information { 252 yang-version 1; 254 namespace "urn:ietf:params:xml:ns:yang:" 255 + "ietf-ipfix-application-information"; 257 prefix ipfix-app-info; 259 organization 260 "IETF SFC (Service Function Chaining) Working Group"; 262 contact 263 "Editor: Christophe Fontaine 264 christophe.fontaine@qosmos.com 266 Editor: Reinaldo Penno 267 rapenno@gmail.com"; 269 description 270 "This module contains a collection of YANG definitions for 271 the configuration of application ids. 273 Copyright (c) 2015 IETF Trust and the persons identified as 274 authors of the code. All rights reserved. 276 Redistribution and use in source and binary forms, with or 277 without modification, is permitted pursuant to, and subject 278 to the license terms contained in, the Simplified BSD License 279 set forth in Section 4.c of the IETF Trust's Legal Provisions 280 Relating to IETF Documents 281 (http://trustee.ietf.org/license-info)."; 283 revision 2015-04-28 { 284 description "Initial revision"; 285 reference 286 "draft-penno-sfc-appid : Using Application Identification in 287 Services Function Chaining Metadata"; 288 } 290 /* 291 * Typedefs 292 */ 294 typedef application-id-ref { 295 type leafref { 296 path "/ipfix-app-info:application-id-dictionary/" 297 + "ipfix-app-info:application-id/ipfix-app-info" 298 + ":application-name"; 299 } 300 description "This type is used by data models that need 301 to reference an application-id"; 302 } 304 typedef classification-engine-id { 305 type enumeration { 306 enum "IANA-L3" { 307 value 1; 308 description 309 "IANA-L3"; 310 } 311 enum "PANA-L3" { 312 value 2; 313 description 314 "PANA-L3"; 315 } 316 enum "IANA-L4" { 317 value 3; 318 description 319 "IANA-L4"; 320 } 321 enum "PANA-L4" { 322 value 4; 323 description 324 "PANA-L4"; 325 } 326 enum "USER-Defined" { 327 value 6; 328 description 329 "USER-Defined"; 330 } 331 enum "PANA-L2" { 332 value 12; 333 description 334 "PANA-L2"; 335 } 336 enum "PANA-L7" { 337 value 13; 338 description 339 "PANA-L7"; 340 } 341 enum "ETHERTYPE" { 342 value 18; 343 description 344 "ETHERTYPE"; 345 } 346 enum "LLC" { 347 value 19; 348 description 349 "LLC"; 350 } 351 enum "PANA-L7-PEN" { 352 value 20; 353 description 354 "PANA-L7-PEN"; 355 } 356 } 357 description 358 "The definitions for Classification engine ID names."; 359 reference 360 "RFC 6759: Cisco Systems Export of Application Information 361 in IP Flow Information Export (IPFIX)"; 362 } 363 /* 364 * Configuration data nodes 365 */ 367 container class-id-dictionary { 368 description "Dictionary for classification ids"; 369 list class-id { 370 key "name"; 371 unique "id"; 372 leaf id { 373 type uint8; 374 description "Classification identifier"; 375 } 376 leaf name { 377 type string; 378 description "classification Engine name"; 379 } 380 leaf description { 381 type string; 382 description "Description of the class-id"; 383 } 384 description "A list of all classification ids"; 385 } 386 } 388 container application-id-dictionary { 389 description "Dictionary for application ids"; 390 list application-id { 391 key "application-name"; 392 unique "class-id pen selector-id"; 393 leaf class-id { 394 type leafref { 395 path "/ipfix-app-info:class-id-dictionary/" 396 + "ipfix-app-info:class-id/ipfix-app-info:id"; 397 } 398 mandatory true; 399 description "Application Name"; 400 } 401 leaf pen { 402 type uint32; 403 mandatory true; 404 description "Private Entreprise Number, only relevant 405 when used with appropriate class-id. 406 Set to 0 when not used."; 407 } 408 leaf selector-id { 409 type uint32 { 410 range "0..16777216"; 411 } 412 mandatory true; 413 description "Selector identifier"; 414 } 415 leaf application-name { 416 type string; 417 mandatory true; 418 description "The name of the application"; 419 } 420 leaf application-description { 421 type string; 422 description "The description of the application"; 423 } 424 leaf application-category-name { 425 type string; 426 description "An attribute that provides a first- 427 level categorization for each 428 Application ID. Examples include 429 browsing, email, file-sharing, 430 gaming, instant messaging, voice- 431 and-video, etc. 432 The category attribute is encoded by 433 the application-category-name 434 Information Element"; 435 } 436 leaf application-sub-category-name { 437 type string; 438 description "An attribute that provides a second- 439 level categorization for each 440 Application ID. Examples include 441 backup-systems, client-server, 442 database, routing-protocol, etc. 443 The sub-category attribute is 444 encoded by the 445 application-sub-category-name 446 Information Element"; 447 } 448 leaf application-group-name { 449 type string; 450 description "An attribute that groups multiple 451 Application IDs that belong to the 452 same networking application. For 453 example, the ftp-group contains 454 ftp-data (port 20), ftp (port 20), 455 ni-ftp (port 47), sftp (port 115), 456 bftp (port 152), ftp-agent(port 457 574), ftps-data (port 989). The 458 application-group attribute is 459 encoded by the application-group-name 460 Information Element"; 461 } 462 description "A list of all applications"; 463 } 464 } 465 } 467 469 5. Service Function Chaining Metadata 471 When a Deep Packet Inspection (DPI), Firewall or any other Service 472 Function (SF) that can identify applications want to convey this 473 knowledge to other SFs it encoded in the format discussed earlier and 474 add to the context metadata. 476 As defined in [I-D.ietf-sfc-nsh], there are two formats for the NSH 477 Metadata, or the portion of the NSH header beyond the mandatory Base 478 Hader and Service Path Header: MD-Type 1 and MD-Type 2. 480 The Application Identification data structure (see Figure 1) can be 481 carried both in MD-Type 1 and MD-Type 2. This document specifies the 482 encoding within NSH MD-Type 1 (see Figure 2), and encoding for NSH 483 MD-Type 2 is provided with the Application ID TLV 484 [I-D.quinn-sfc-nsh-tlv]. 486 The Example in Figure 2 shows the encoding of the SNMP application 487 using MD-Type 1. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | 3 | 0 | 161 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Network Shared Context | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Service Platform Context | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Service Shared Context | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 2: Example of Metadata Including the SNMP Application 502 Identification 504 In this example, the Classification Engine IDs of 3 indicates "IANA- 505 L4", and 161 is the well-known port number for SNMP (with its upper 506 bits zero-valued). 508 Other Services Functions that need application information associated 509 with a packet or flow can look at this metadata (encoded in either 510 MD-Type 1 or MD-Type 2) and easily find out its value. 512 6. Relationship to existing YANG Modules 514 [RFC6728] specifies a data model for the IP Flow Information Export 515 (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring 516 and monitoring Selection Processes, Caches, Exporting Processes, and 517 Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices 518 using the Network Configuration Protocol (NETCONF). The data model 519 is defined using UML (Unified Modeling Language) class diagrams and 520 formally specified using YANG. 522 The YANG model is this document allows the configuration of the 523 application id IPFIX information elements (ieId), which in turn, may 524 be used in a template definition (TemplateId). 526 [I-D.penno-sfc-yang] To be done 528 7. Expected Usage 530 Devices or controllers will download the [ETHERTYPE], [IANA-PROTO] 531 and [IANA-PORTS] from the appropriate URIs. However, the 532 configuration of the applications is required for applications not 533 registered in an industry-wide agreed-upon registry. In this case, 534 the Proprietary Assigned Number Authority (PANA) registries (PANA-L2, 535 PANA-L3, PANA-L4, PANA-L7), or the User-Defined registry, must be 536 used to identify new application. 538 Furthermore, the following attributes are statically assigned per 539 Application ID, and needs to be configured: category, sub-category, 540 application-group. 542 8. IANA Considerations 544 TBD 546 9. Security Considerations 548 TODO: Update with privacy and security considerations, as requested 549 in Prague IETF93. 551 10. Acknowledgements 553 The authors wish to thank Kengo Naito for a thorough review and 554 insightful comments. 556 11. Changes 558 12. Informative References 560 [ETHERTYPE] 561 "ETHERTYPE", 1984, 562 . 565 [I-D.ietf-nvo3-vxlan-gpe] 566 Kreeger, L. and U. Elzur, "Generic Protocol Extension for 567 VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), 568 April 2016. 570 [I-D.ietf-sfc-nsh] 571 Quinn, P. and U. Elzur, "Network Service Header", draft- 572 ietf-sfc-nsh-05 (work in progress), May 2016. 574 [I-D.penno-sfc-yang] 575 Penno, R., Quinn, P., Zhou, D., and J. Li, "Yang Data 576 Model for Service Function Chaining", draft-penno-sfc- 577 yang-15 (work in progress), June 2016. 579 [I-D.quinn-sfc-nsh-tlv] 580 Quinn, P., Elzur, U., Majee, S., and J. Halpern, "Network 581 Service Header TLVs", draft-quinn-sfc-nsh-tlv-01 (work in 582 progress), April 2016. 584 [IANA-IPFIX] 585 IANA, ""IP Flow Information Export (IPFIX) Entities"", 586 2015, . 588 [IANA-PORTS] 589 IANA, "IANA-L4", 1984, 590 . 592 [IANA-PROTO] 593 IANA, "IANA-L3", 1984, 594 . 596 [LLDP] IEEE, "Std 802.1AB-2005, "Standard for Local and 597 metropolitan area networks - Station and Media Access 598 Control Connectivity Discovery", IEEE Std 802.1AB-2005", 599 2005, . 601 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data 602 Model for the IP Flow Information Export (IPFIX) and 603 Packet Sampling (PSAMP) Protocols", RFC 6728, 604 DOI 10.17487/RFC6728, October 2012, 605 . 607 [RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems 608 Export of Application Information in IP Flow Information 609 Export (IPFIX)", RFC 6759, DOI 10.17487/RFC6759, November 610 2012, . 612 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 613 "Specification of the IP Flow Information Export (IPFIX) 614 Protocol for the Exchange of Flow Information", STD 77, 615 RFC 7011, DOI 10.17487/RFC7011, September 2013, 616 . 618 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 619 for IP Flow Information Export (IPFIX)", RFC 7012, 620 DOI 10.17487/RFC7012, September 2013, 621 . 623 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 624 Chaining (SFC) Architecture", RFC 7665, 625 DOI 10.17487/RFC7665, October 2015, 626 . 628 Authors' Addresses 630 Reinaldo Penno 631 Cisco Systems, Inc. 632 170 West Tasman Dr 633 San Jose CA 634 USA 636 Email: repenno@cisco.com 638 Benoit Claise 639 Cisco Systems, Inc. 640 De Kleetlaan 6a b1 641 1831 Diegem 642 Belgium 644 Email: bclaise@cisco.com 646 Carlos Pignataro 647 Cisco Systems, Inc. 648 7200-12 Kit Creek Road 649 Research Triangle Park, NC 27709-4987 650 USA 652 Email: cpignata@cisco.com 653 Christophe Fontaine 654 Qosmos 655 8 rue Bernard Buffer 656 Paris 657 France 659 Email: christophe.fontaine@qosmos.com