idnits 2.17.1 draft-choukir-tsvwg-flow-metadata-encoding-01.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.eckert-intarea-flow-metadata-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3936 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 (-02) exists of draft-eckert-intarea-flow-metadata-framework-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Eckert, Ed. 3 Internet-Draft A. Zamfir 4 Intended status: Standards Track A. Choukir 5 Expires: January 16, 2014 C. Eckel 6 Cisco Systems, Inc. 7 July 15, 2013 9 Protocol Independent Encoding for Signaling Flow Characteristics 10 draft-choukir-tsvwg-flow-metadata-encoding-01 12 Abstract 14 This document describes a protocol independent encoding for flow 15 characteristics (a.k.a. metadata). A flow is defined as a set of IP 16 packets passing through a network in a given direction. All packets 17 belonging to a particular flow have a set of common properties (e.g. 18 IP, port, transport). Flow metadata exposes key characteristics of 19 the flow such as the originating application, the type of media in 20 use (e.g. audio, video) and others as defined in 21 [I-D.eckert-intarea-flow-metadata-framework]. The flow 22 characteristics are expressed in terms of information elements. 23 These information elements are signaled either out of band or in band 24 but always along the same path of the flow associated with the 25 application. 27 [I-D.eckert-intarea-flow-metadata-framework] defines the overall 28 framework for flow metadata and the definition of the flow 29 characteristics, whereas this document captures the encoding of these 30 characteristics. The mapping of flow metadata encoding to different 31 signaling protocols is outside the scope of this document. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 16, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Encoding Overview . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. General Principles . . . . . . . . . . . . . . . . . . . 4 71 2.2. Encoding Goals . . . . . . . . . . . . . . . . . . . . . 4 72 2.2.1. Transport independence . . . . . . . . . . . . . . . 5 73 2.2.2. Standard and Vendor Specific Namespaces . . . . . . . 5 74 2.2.3. Multiple Producers . . . . . . . . . . . . . . . . . 5 75 2.2.4. Upstream and Downstream . . . . . . . . . . . . . . . 6 76 2.2.5. Application to Network and Network to Application . . 6 77 2.2.6. Extensibility . . . . . . . . . . . . . . . . . . . . 6 78 2.2.7. Flexibility . . . . . . . . . . . . . . . . . . . . . 6 79 2.2.8. Per Producer Security . . . . . . . . . . . . . . . . 6 80 2.2.9. Compact Encoding . . . . . . . . . . . . . . . . . . 7 81 3. Encoding specification . . . . . . . . . . . . . . . . . . . 7 82 3.1. Layout . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.1.1. Sections . . . . . . . . . . . . . . . . . . . . . . 7 84 3.1.2. Security Tokens . . . . . . . . . . . . . . . . . . . 8 85 3.1.3. Subsections . . . . . . . . . . . . . . . . . . . . . 9 86 3.1.4. Upstream and Downstream Blocks . . . . . . . . . . . 10 87 3.1.5. Complete Encoding Example . . . . . . . . . . . . . . 10 88 3.1.6. Compact Encoding Example . . . . . . . . . . . . . . 11 89 3.2. Encoding Structures . . . . . . . . . . . . . . . . . . . 12 90 3.3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 93 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 95 6.2. Informative References . . . . . . . . . . . . . . . . . 17 96 Appendix A. Encoding usage examples . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 This document describes a protocol independent encoding for flow 102 characteristics (a.k.a. metadata). A flow is defined as a set of IP 103 packets passing through a network in a given direction. All packets 104 belonging to a particular flow have a set of common properties (e.g. 105 IP, port, transport). Flow metadata exposes key characteristics of 106 the flow such as the originating application, the type of media in 107 use (e.g. audio, video) and others as defined in 108 [I-D.eckert-intarea-flow-metadata-framework]. The flow 109 characteristics are expressed in terms of information elements. 110 These information elements are signaled either out of band or in band 111 but always along the same path of the flow associated with the 112 application. 114 As flow characteristics across different signaling protocols are 115 identical, they benefit from a single definition and encoding 116 irrespective of the signaling protocol in use (e.g. RSVP 117 [I-D.zamfir-tsvwg-flow-metadata-rsvp], STUN 118 [I-D.martinsen-mmusic-malice], and PCP [I-D.wing-pcp-flowdata]). 119 Different network deployments call for different protocols or 120 combination of protocols as described in 121 [I-D.eckert-intarea-flow-metadata-framework]. The flow 122 characteristics can be processed by intermediate network nodes for 123 the purpose of applying a particular treatment to the flow or simply 124 for gathering insight on the nature of the traffic crossing the 125 network node. 127 Flows, and the corresponding metadata, are inherently unidirectional, 128 in the direction from the source to the destination (e.g. from Alice 129 to Bob). In some cases, there may be a related flow in the reverse 130 direction (e.g. from Bob to Alice), but this is treated as a separate 131 flow, not a bidirectional flow. The metadata can characterize data 132 in the same direction as the flow (upstream) or in the opposite 133 direction (downstream). The encoding mechanism enabling signaling 134 for either or both directions. The metadata can be signaled by the 135 application itself and/or by network elements that have visibility of 136 the flow data. The encoding supports distinguishing between 137 attribute information originated by an application from attribute 138 information originated by a network device. The encoding allows to 139 segregates information coming from the application from information 140 coming from the network. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2. Encoding Overview 150 2.1. General Principles 152 This specification assumes that the flow is specified by the 153 transport protocol which carries the metadata. As an example, in 154 STUN, flow identifiers such as IP addresses and ports are present in 155 layer 3 and 4 headers of STUN messages (see 156 [I-D.martinsen-mmusic-malice]). In RSVP, the same is obtained from 157 the SESSION and SENDER-TEMPLATE objects (see 158 [I-D.zamfir-tsvwg-flow-metadata-rsvp]). In PCP the source IP is part 159 of the request common header; other flow identifiers need to be 160 embedded in an opcode data or an option (see[I-D.wing-pcp-flowdata]). 162 The Flow Metadata characteristics are to be interpreted in the 163 context of the flow defined by the signaling protocol. In this 164 specification Flow Metadata encoding does not carry any flow 165 identifiers but merely the flow characteristics. The specification 166 could be extended to carry the flow identifiers if needed. 168 The encoding defined herein does not relate to any specific signaling 169 but rather allows different signaling protocols to transport flow 170 characteristics. As the encoding is shared amongst several 171 protocols, it is versioned independently to allow, if needed, its 172 evolution without impacting the signaling protocol. 174 2.2. Encoding Goals 176 The following goals have been considered in the design of the 177 encoding: 179 o Transport independence 181 o Allow for a standard namespace as well as vendor specific 182 namespaces 184 o Support multiple producers of flow characteristics 186 o Ability to encode flow characteristics for both the flow itself 187 (upstream) and the flow in the reverse direction (downstream). 189 o Ability to communicate flow characteristics from an application to 190 the network as well as from the network back to the application 192 o Extensibility while allowing for backwards compatibility 194 o Flexibility 196 o Support for integrity, authentication and authorization on a per 197 producer basis 199 o Compact encoding 201 2.2.1. Transport independence 203 One goal of this proposal is to provide an encoding that can be used 204 by more than one transport protocol. This should help maintain 205 consistency across standardization of flow metadata usage by various 206 signaling protocols, and it should simplify implementations that make 207 use of different signaling protocols when transporting flow metadata. 208 One example is an application that may use different signaling 209 protocols depending on the environment, peer protocol support, etc. 210 Another is a middlebox on an administrative boundary that may need to 211 perform protocol interworking functions. 213 2.2.2. Standard and Vendor Specific Namespaces 215 Vendors need the ability to define and use proprietary Metadata when 216 they are delivering a pre-standard feature or product or when the 217 encoded information is of commercially sensitive nature. This 218 specification provides support for both standard and vendor specific 219 defined flow characteristics. 221 2.2.3. Multiple Producers 223 Multiple producers may contribute flow characteristics to the Flow 224 Metadata information associated with a given flow. 226 Applications are one category of candidates for generating Flow 227 Metadata as they have precise knowledge of the flows they insert into 228 the network. Middleboxes constitute a second class of Metadata 229 producers. Deep Packet Inspection engines are deployed to recognize 230 the originator and nature of the flows traversing a network. Media 231 Termination Points (e.g. MCU, transcoders) are deployed to offer 232 additional services to applications. Media Termination Points have 233 knowledge of the transformations they apply on the flow they receive 234 and can therefore update the characteristics of the flow. Other 235 proxies and gateways exist for other applications and could produce 236 information in relation to the flow. 238 2.2.4. Upstream and Downstream 240 As explained in the introduction, a flow is unidirectional by 241 definition, but some use cases and signaling protocols require or 242 allow to signal both upstream and downstream flow characteristics. 243 For example, in the context of a home user that needs to prioritize 244 its upstream and downstream flow an end-to-edge protocol can expose 245 flow characteristics to the edge ISP node controlling its access link 246 for both its upstream and downstream flow. This allows the edge node 247 to apply proper treatment to both directions. 249 2.2.5. Application to Network and Network to Application 251 In accordance with [I-D.eckert-intarea-flow-metadata-framework], flow 252 characteristics may be communicated both from application to network 253 as well as from network to application. The encoding rules are the 254 same regardless of the direction of the communication. The ability 255 to differentiate between the two is provided by the transport 256 protocol. For example, when using PCP, application to network 257 communication is via a PCP request, and network to application 258 communication is via a PCP response. 260 2.2.6. Extensibility 262 New use cases and new deployment scenarios will require the use of 263 new flow characteristics. For this reason the encoding should 264 support new metadata (i.e. new information elements) in a backwards 265 compatible way. New information element definitions supplement but 266 do not redefine existing definitions. An application or a network 267 node always signals its currently supported set of information 268 elements and devices leverage the subset they understand for the 269 purpose of applying treatment to, or gathering information about, the 270 application flows. 272 2.2.7. Flexibility 274 Distinct use cases and individual applications have a need for 275 different subsets of information elements. The encoding should 276 support the signaling of any subset of information elements for that 277 purpose. For example, a video conferencing application might need to 278 signal metadata for both its audio and video flows. A video 279 surveillance application might signal video flows only, but may need 280 to indicate which one has priority based on embedded analytics. 282 2.2.8. Per Producer Security 284 Treatment applied on the basis of metadata may involve the 285 consumption of scarce network resources and therefore contribute to 286 their exhaustion. Consequently, integrity, authentication, and 287 authorization are all important aspects of any security mechanism 288 used to secure the metadata. 290 This specification defines an optional security element container; 291 however, the actual security mechanism to be used is outside the 292 scope of this specification. 294 2.2.9. Compact Encoding 296 One of the goals of the encoding described in this specification is 297 to be compact and consume minimal space in the signaling protocol 298 payload. Most of the protocols have limited space for Metadata 299 purposes and do not support semantic fragmentation. The strategy of 300 the encoding is to minimize the encoding structures used for the 301 common signaling case. The common case is foreseen to be the 302 application signaling standard flow characteristics. 304 3. Encoding specification 306 3.1. Layout 308 This section describes the encoding layout proposed by this 309 specification. It describes the following: 311 o How the application and network producers coexist using sections 312 in Figure 1 314 o Application of an optional security token to a section in Figure 2 316 o The division of a section into standard and vendor specific sub- 317 sections in Figure 3 319 o The division of a sub-section into upstream and downstream blocks 320 in Figure 4 322 o A full example using all the encoding building blocks in Figure 5 324 3.1.1. Sections 326 The flow characteristics are grouped in sections within the encoding. 327 A section pertains to an application or to a network producer. To 328 segregate application and network producer sections the encoding uses 329 a network marker. The application section does not use a network 330 marker and therefore must come first if present. The encoding MUST 331 contain at least an application or a network section. Figure 1 shows 332 an example that contains an application section and two network 333 sections. 335 +--------------------------------+ 336 | Application Section | 337 +--------------------------------+ 338 +--------------------------------+ 339 | Network-1 Marker | 340 +--------------------------------+ 341 +--------------------------------+ 342 | | 343 | | 344 | Network-1 Section | 345 | | 346 +--------------------------------+ 347 +--------------------------------+ 348 | Network-2 Marker | 349 +--------------------------------+ 350 +--------------------------------+ 351 | | 352 | | 353 | Network-2 Section | 354 | | 355 | | 356 | | 357 +--------------------------------+ 359 Figure 1: Encoding section 361 3.1.2. Security Tokens 363 A section MAY include at most one security token. The security 364 token, if present, MUST appear at the beginning of the section. In 365 the following example, a separate security token is added to each 366 section contained in the previous example. 368 +--------------------------------+ 369 | Security Token | 370 +--------------------------------+ 371 +--------------------------------+ 372 | Application Section | 373 +--------------------------------+ 374 +--------------------------------+ 375 | Network-1 Marker | 376 +--------------------------------+ 377 +--------------------------------+ 378 | Security Token N-1 | 379 +--------------------------------+ 380 +--------------------------------+ 381 | | 382 | | 383 | Network-1 Section | 384 | | 385 +--------------------------------+ 386 +--------------------------------+ 387 | Network-2 Marker | 388 +--------------------------------+ 389 +--------------------------------+ 390 | Security Token N-2 | 391 +--------------------------------+ 392 +--------------------------------+ 393 | | 394 | | 395 | Network-2 Section | 396 | | 397 | | 398 | | 399 +--------------------------------+ 401 Figure 2: Encoding security tokens 403 3.1.3. Subsections 405 A section may be divided into standard and vendor sub-sections. A 406 section MUST at least have one subsection. A section MUST contain at 407 most one standard sub-section and can contain multiple vendor 408 subsections for different vendors. A standard and a vendor sub- 409 section are segregated through a vendor marker. The standard 410 subsection does not use the vendor marker and therefore must come 411 first if present. Figure 3 shows a sample section content. 413 +--------------------------------+ 414 | | 415 | | 416 | Standard Subsection | 417 | | 418 +--------------------------------+ 419 +--------------------------------+ 420 | Vendor-1 Marker | 421 +--------------------------------+ 422 +--------------------------------+ 423 | Vendor-1 Subsection | 424 | | 425 | | 426 | | 427 | | 428 | | 429 +--------------------------------+ 430 +--------------------------------+ 431 | Vendor-2 Marker | 432 +--------------------------------+ 433 +--------------------------------+ 434 | Vendor-2 Subsection | 435 | | 436 | | 437 | | 438 | | 439 | | 440 +--------------------------------+ 442 Figure 3: Encoding subsections 444 3.1.4. Upstream and Downstream Blocks 446 A subsection MUST contain at least one upstream or downstream block. 447 A subsection contains at most one upstream block and at most one 448 downstream block. Upstream and downstream blocks are composed of 449 metadata tags, with each tag representing an encoding of a specific 450 information element. If the upstream and downstream blocks are both 451 present, the upstream block MUST come first. 453 +--------------------------------+ 454 | Upstream block | 455 | +------------+ +------------+ | 456 | | MD tag | | MD tag | | 457 | +------------+ +------------+ | 458 +--------------------------------+ 459 +--------------------------------+ 460 | Downstream block | 461 | +------------+ +------------+ | 462 | | MD tag | | MD tag | | 463 | +------------+ +------------+ | 464 +--------------------------------+ 466 Figure 4: Encoding upstream and downstream blocks 468 3.1.5. Complete Encoding Example 470 Figure 5 shows a complete example combining the application and 471 network sections together with their standard and vendor sub- 472 sections. The metadata tags appearing in a standard and in a vendor 473 sub-section are managed by separate registries. See 474 [I-D.eckert-intarea-flow-metadata-framework] for a full coverage of 475 the information model and how the registries are handled. 477 +--------------------------------+ 478 | Security Token | 479 +--------------------------------+ 480 +--------------------------------+ ^ ^ 481 | Upstream block | | |A 482 | +------------+ +------------+ | | |P 483 | | MD tag | | MD tag | | |S |P 484 | +------------+ +------------+ | |T |L 485 +--------------------------------+ |D |I 486 +--------------------------------+ | |C 487 | Downstream block | | |A 488 | +------------+ | | |T 489 | | MD tag | | | |I 490 | +------------+ | | |O 491 +--------------------------------+ v |N 492 +--------------------------------+ | 493 | Vendor section marker | |S 494 +--------------------------------+ |E 495 +--------------------------------+ ^ |C 496 | Upstream block | |V |T 497 | +------------+ +------------+ | |N |I 498 | | MD tag | | MD tag | | |D |O 499 | +------------+ +------------+ | | |N 500 +--------------------------------+ v v 501 +--------------------------------+ ^ 502 | Network section marker | | 503 +--------------------------------+ | 504 +--------------------------------+ |N 505 | Security Token | |E 506 +--------------------------------+ |T 507 +--------------------------------+ |W 508 | Downstream block | |O 509 | +------------+ | |R 510 | | MD tag | | |K 511 | +------------+ | | 512 +--------------------------------+ | 513 +--------------------------------+ |S 514 | Vendor section marker | |E 515 +--------------------------------+ |C 516 +--------------------------------+ |T 517 | Downstream block | |I 518 | +------------+ | |O 519 | | MD tag | | |N 520 | +------------+ | | 521 +--------------------------------+ v 523 Figure 5: Complete encoding example 525 3.1.6. Compact Encoding Example 526 Figure 6 shows an encoding example for flow metadata standard 527 characteristics produced by an application for the upstream (same as 528 5-tuple) direction. As can be seen in the figure no network marker 529 is used as we are signaling for the application. In the same way 530 there is no vendor marker as we are signaling standard flow 531 characteristics. This example also assumes a use case where no 532 security token is needed. Further examples are given in Appendix A. 534 +--------------------------------+ 535 | Upstream block | 536 | +------------+ +------------+ | 537 | | MD tag | | MD tag | | 538 | +------------+ +------------+ | 539 +--------------------------------+ 541 Figure 6: Compact encoding example 543 3.2. Encoding Structures 545 This section explores the encoding looking more closely at the 546 encoding structures. 548 Figure 7 shows the encoding used by an application using only 549 standard metadata tags. 551 Figure 8 shows the encoding used by an application using only 552 vendor specific metadata tags. 554 Figure 9 shows the encoding for network producers using only 555 standard metadata tags. 557 The three scenarios expose all the encoding structures. These 558 structures may be combined in various ways to support other 559 scenarios. 561 The encoding makes use of Type Length Value (TLV) as the base 562 building block, plus some level of nesting to create the different 563 encoding structures. The type indicates which encoding structure is 564 in use. In case of a marker, the length gives the size of the marker 565 but not of the delimited section or sub-section. 567 As explained previously, application and network sections MUST 568 contain at least one standard or vendor sub-section and MAY contain a 569 security token. The value of the security token TLV is broken down 570 in two parts, a security-scheme indicating the security method used 571 and the security-value holding the security payload specific to the 572 security scheme. The definition of the different security schemes 573 and their payloads are left to a separate document. 575 The value of the upstream and downstream block TLVs are subdivided in 576 metadata tags. Each tag is itself a TLV specifying a flow 577 characteristic. A metadata tag MUST appear only once in an upstream 578 or a downstream block. On the one hand the security token, the 579 upstream and the downstream block, the vendor and network marker 580 types are defined within the same registry. On the other hand the 581 tag types are defined in a separate registry from the enclosing 582 encoding structures. The separation of the registries is possible as 583 the metadata tags are part of the upstream and downstream block TLV 584 value and therefore do not collide with the encoding structures. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^S 589 | Security-type | Length ||E 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C 591 | Security-scheme | :| 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :|T 593 : Security-value :|O 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+vK 595 | Upstream-type | Length | ^U 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M|P 597 | Tag-type | Length ||D| 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |B 599 : Tag-value :|T|L 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+v |O 601 : ... : |C 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vK 603 | Downstream-type | Length | ^D 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N 605 | Tag-type | Length | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B 607 : Tag-value : |L 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O 609 : ... : |C 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vK 612 Figure 7 614 Figure 8 adds the vendor sub-section marker which starts a vendor 615 section. The vendor marker is a TLV whose type is defined in the 616 same registry as the security token. Its value is the vendor's 617 Private Enterprise Number (PEN) allocated by IANA. The vendor marker 618 does not include the downstream and the upstream block but rather 619 sets the context to interpret them. Multiple vendor sub-sections 620 within the same application or network section are allowed as long as 621 they pertain to different vendors. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Security-type | Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Security-scheme | : 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 630 : Security-value : 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 632 | PEN-type | Length | | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 634 | PEN-id | |V 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E 636 | Upstream-type | Length | |N 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D 638 | Tag-type | Length | |O 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R 640 : Tag-value : | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S 642 : ... : |E 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C 644 | Downstream-type | Length | |T 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I 646 | Tag-type | Length | |O 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N 648 : Tag-value : | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 650 : ... : | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 653 Figure 8 655 Figure 9 adds the network marker that starts a network section. The 656 network marker is a TLV whose type is defined within the same 657 registry as the security token. The value of the network marker is 658 the network precedence that indicates the administrative preference 659 for the network producer flow characteristics. The precedence allows 660 to merge information from different network producers and retain only 661 the preferred one. 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 666 | Network-type | Length | | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 668 | Precedence | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 670 | Security-type | Length | |P 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R 672 | Security-scheme | : |O 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : |D 674 : Security-value : |U 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C 676 | Upstream-type | Length | |E 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R 678 | Tag-type | Length | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S 680 : Tag-value : |E 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C 682 : ... : |T 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I 684 | Downstream-type | Length | |O 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N 686 | Tag-type | Length | | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 688 : Tag-value : | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 690 : ... : | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 693 Figure 9 695 All the constructs above can be combined to signal standard and 696 vendor specific metadata tags for different producers and allow to 697 secure each producer's information independently. 699 3.3. ABNF 701 MD-block = Version (Application-block / 1*Network-block / 702 (Application-block 1*Network-block)) 704 Network-blocks = Network-tlv Producer-block 706 Application-block = Producer-block ; For the application we do not 707 ; require the Producer-tlv 709 Producer-block = [Security-tlv] (Standard-block / 1*Vendor-block / 710 (Standard-block 1*Vendor-block)) 712 Vendor-blocks = PEN-tlv Flow-block 714 Standard-block = Flow-block; We do not require the PEN-tlv 715 ; for the standard metadata tags 717 Flow-block = Upstream-tlv / Downstream-tlv / 718 (Upstream-tlv Downstream-tlv) 719 ; If both present, upstream must come first 721 PEN-tlv = PEN-type Length PEN-id 723 Network-tlv = Network-type Length Precedence 725 Security-tlv = Security-type Length Security-scheme Security-value 727 Upstream-tlv = Upstream-type Length Upstream-value 729 Upstream-value = Attribute-list 731 Downstream-tlv = Downstream-type Length Downstream-value 733 Downstream-value = Attribute-list 735 Attribute-list = 1*(Attribute-tlv) 737 Attribute-tlv = Tag-type Length Attribute-value 739 ;--------- 740 ;TERMINALS 741 ;--------- 743 Version = %x01 ; NEW-VER will be picked up as the first 744 ; version of the encoding 746 PEN-id = 4(OCTET); Private Enterprise Number defined by IANA 748 Length = 2(OCTET); 16-bit length field 750 Precedence = 4(OCTET); Indicates the preferred source of information 751 ; for a producer-type 753 Security-scheme = OCTET; Type of security used 755 Security-value = *(OCTET) 756 ; length of this field must match Length of Security-tlv + 2 758 Tag-type = 2(OCTET); Value according to IANA/Vendor-specific registry 760 Producer-type = Zero %x01; The first foreseen producer is MD-NETWORK 761 ; to cover for DPI engines, gateways and others 762 ; Further values may be allocated later 764 Security-type = Zero %x00 ; 765 Upstream-type = Zero %x01 ; 767 Downstream-type = Zero %x02 ; 769 PEN-type = Zero %x03 ; 771 Network-type = Zero %x04 773 Attribute-value = *(OCTET) ; 775 Zero = %x00 777 Figure 10 779 4. Security Considerations 781 A security token, as described in Section 3.1.2, is a mechanism 782 provided as part of the encoding to protect flow characteristics. A 783 signaling protocol used to transport the encoded metadata may provide 784 additional security mechanisms. The protocol specific and encoding 785 specific security mechanisms may be used in combination to achieve 786 the required level of security. 788 5. Acknowledgements 790 We would like to thank Yann Poupet and Davide Cuda for reviewing this 791 document and helping us proof its content. We would also like to 792 express our gratitude to Sergio Mena de la Cruz for contributing 793 ideas, proofing the text and for his work on validating the grammar. 795 6. References 797 6.1. Normative References 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 6.2. Informative References 804 [I-D.eckert-intarea-flow-metadata-framework] 805 Eckert, T., Penno, R., Choukir, A., and C. Eckel, "A 806 Framework for Signaling Flow Characteristics between 807 Applications and the Network", draft-eckert-intarea-flow- 808 metadata-framework-00 (work in progress), July 2013. 810 [I-D.martinsen-mmusic-malice] 811 Penno, R., Martinsen, P., Wing, D., and A. Zamfir, "Meta- 812 data Attribute signaLling with ICE", draft-martinsen- 813 mmusic-malice-00 (work in progress), July 2013. 815 [I-D.wing-pcp-flowdata] 816 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 817 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 819 [I-D.zamfir-tsvwg-flow-metadata-rsvp] 820 Eckert, T., Zamfir, A., and A. Choukir, "Flow Metadata 821 Signaling with RSVP", draft-zamfir-tsvwg-flow-metadata- 822 rsvp-00 (work in progress), July 2013. 824 Appendix A. Encoding usage examples 826 TBD 828 Authors' Addresses 830 Toerless Eckert (editor) 831 Cisco Systems, Inc. 832 San Jose 833 US 835 Email: eckert@cisco.com 837 Anca Zamfir 838 Cisco Systems, Inc. 839 Lausanne 840 CH 842 Email: ancaz@cisco.com 844 Amine Choukir 845 Cisco Systems, Inc. 846 Lausanne 847 CH 849 Email: amchouki@cisco.com 850 Charles Eckel 851 Cisco Systems, Inc. 852 170 West Tasman Drive 853 San Jose, CA 95134 854 US 856 Email: eckelcu@cisco.com