Internet Engineering Task Force T. Eckert, Ed. Internet-Draft A. Zamfir Intended status: Standards Track A. Choukir Expires: January 10, 2014 C. Eckel Cisco Systems, Inc. July 09, 2013 Protocol Independent Encoding for Signaling Flow Characteristics draft-choukir-tsvwg-flow-metadata-encoding-00 Abstract This document describes a protocol independent encoding for flow characteristics (a.k.a. metadata). A flow is defined as a set of IP packets passing through a network in a given direction. All packets belonging to a particular flow have a set of common properties (e.g. IP, port, transport). Flow metadata exposes key characteristics of the flow such as the originating application, the type of media in use (e.g. audio, video) and others as defined in [I-D.eckert-intarea-flow-metadata-framework]. The flow characteristics are expressed in terms of information elements. These information elements are signaled either out of band or in band but always along the same path of the flow associated with the application. [I-D.eckert-intarea-flow-metadata-framework] defines the overall framework for flow metadata and the definition of the flow characteristics, whereas this document captures the encoding of these characteristics. The mapping of flow metadata encoding to different signaling protocols is outside the scope of this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 10, 2014. Eckert, et al. Expires January 10, 2014 [Page 1] Internet-Draft Flow Metadata Encoding July 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Encoding Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. General Principles . . . . . . . . . . . . . . . . . . . 4 2.2. Encoding Goals . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Transport independence . . . . . . . . . . . . . . . 5 2.2.2. Standard and Vendor Specific Namespaces . . . . . . . 5 2.2.3. Multiple Producers . . . . . . . . . . . . . . . . . 5 2.2.4. Upstream and Downstream . . . . . . . . . . . . . . . 5 2.2.5. Application to Network and Network to Application . . 6 2.2.6. Extensibility . . . . . . . . . . . . . . . . . . . . 6 2.2.7. Flexibility . . . . . . . . . . . . . . . . . . . . . 6 2.2.8. Per Producer Security . . . . . . . . . . . . . . . . 6 2.2.9. Compact Encoding . . . . . . . . . . . . . . . . . . 7 3. Encoding specification . . . . . . . . . . . . . . . . . . . 7 3.1. Layout . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Sections . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Security Tokens . . . . . . . . . . . . . . . . . . . 8 3.1.3. Subsections . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Upstream and Downstream Blocks . . . . . . . . . . . 10 3.1.5. Complete Encoding Example . . . . . . . . . . . . . . 10 3.1.6. Compact Encoding Example . . . . . . . . . . . . . . 11 3.2. Encoding Structures . . . . . . . . . . . . . . . . . . . 12 3.3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Encoding usage examples . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Eckert, et al. Expires January 10, 2014 [Page 2] Internet-Draft Flow Metadata Encoding July 2013 1. Introduction This document describes a protocol independent encoding for flow characteristics (a.k.a. metadata). A flow is defined as a set of IP packets passing through a network in a given direction. All packets belonging to a particular flow have a set of common properties (e.g. IP, port, transport). Flow metadata exposes key characteristics of the flow such as the originating application, the type of media in use (e.g. audio, video) and others as defined in [I-D.eckert-intarea-flow-metadata-framework]. The flow characteristics are expressed in terms of information elements. These information elements are signaled either out of band or in band but always along the same path of the flow associated with the application. As flow characteristics across different signaling protocols are identical, they benefit from a single definition and encoding irrespective of the signaling protocol in use (e.g. RSVP [ID-FMD-RSVP], STUN [I-D.martinsen-mmusic-malice], and PCP [I-D.wing-pcp-flowdata]). Different network deployments call for different protocols or combination of protocols as described in [I-D.eckert-intarea-flow-metadata-framework]. The flow characteristics can be processed by intermediate network nodes for the purpose of applying a particular treatment to the flow or simply for gathering insight on the nature of the traffic crossing the network node. Flows, and the corresponding metadata, are inherently unidirectional, in the direction from the source to the destination (e.g. from Alice to Bob). In some cases, there may be a related flow in the reverse direction (e.g. from Bob to Alice), but this is treated as a separate flow, not a bidirectional flow. The Metadata tags can characterize data in the same direction as the flow (upstream) or in the opposite direction (downstream). The encoding allows to signal for either direction or both at the same time. The Metadata tags can be signaled by the application itself and/or by network elements that have visibility of the flow data. The encoding supports distinguishing between attribute information originated by an application from attribute information originated by a network device. The encoding allows to segregates information coming from the application from information coming from the network. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Eckert, et al. Expires January 10, 2014 [Page 3] Internet-Draft Flow Metadata Encoding July 2013 2. Encoding Overview 2.1. General Principles This specification assumes that the flow is specified by the transport protocol which carries the Metadata tags. As an example, in STUN, flow identifiers such as IP addresses and ports are present in layer 3 and 4 headers of STUN messages (see [I-D.martinsen-mmusic-malice]). In RSVP, the same is obtained from the SESSION and SENDER-TEMPLATE objects (see [ID-FMD-RSVP]). In PCP the source IP is part of the request common header; other flow identifiers need to be embedded in an opcode data or an option (see[I-D.wing-pcp-flowdata]). The Flow Metadata characteristics are to be interpreted in the context of the flow defined by the signaling protocol. In this specification Flow Metadata encoding does not carry any flow identifiers but merely the flow characteristics. The specification could be extended to carry the flow identifiers if needed. The encoding defined herein does not relate to any specific signaling but rather allows different signaling protocols to transport flow characteristics. As the encoding is shared amongst several protocols, it is versioned independently to allow, if needed, its evolution without impacting the signaling protocol. 2.2. Encoding Goals The following goals have been considered in the design of the encoding: o Transport independence o Allow for a standard namespace as well as vendor specific namespaces o Support multiple producers of flow characteristics o Ability to encode flow characteristics for both the flow itself (upstream) and the flow in the reverse direction (downstream). o Ability to communicate flow characteristics from an application to the network as well as from the network back to the application o Extensibility while allowing for backwards compatibility o Flexibility Eckert, et al. Expires January 10, 2014 [Page 4] Internet-Draft Flow Metadata Encoding July 2013 o Support for integrity, authentication and authorization on a per producer basis o Compact encoding 2.2.1. Transport independence One goal of this proposal is to provide an encoding that can be used by more than one transport protocol. This should help maintain consistency across standardization of flow metadata usage by various signaling protocols, and it should simplify implementations that make use of different signaling protocols when transporting flow metadata. One example is an application that may use different signaling protocols depending on the environment, peer protocol support, etc. Another is a middlebox on an administrative boundary that may need to perform protocol interworking functions. 2.2.2. Standard and Vendor Specific Namespaces Vendors need the ability to define and use proprietary Metadata when they are delivering a pre-standard feature or product or when the encoded information is of commercially sensitive nature. This specification provides support for both standard and vendor specific defined flow characteristics. 2.2.3. Multiple Producers Multiple producers may contribute flow characteristics to the Flow Metadata information associated with a given flow. Applications are one category of candidates for generating Flow Metadata as they have precise knowledge of the flows they insert into the network. Middleboxes constitute a second class of Metadata producers. Deep Packet Inspection engines are deployed to recognize the originator and nature of the flows traversing a network. Media Termination Points (e.g. MCU, transcoders) are deployed to offer additional services to applications. Media Termination Points have knowledge of the transformations they apply on the flow they receive and can therefore update the characteristics of the flow. Other proxies and gateways exist for other applications and could produce information in relation to the flow. 2.2.4. Upstream and Downstream As explained in the introduction, a flow is unidirectional by definition, but some use cases and signaling protocols require or allow to signal both upstream and downstream flow characteristics. For example, in the context of a home user that needs to prioritize Eckert, et al. Expires January 10, 2014 [Page 5] Internet-Draft Flow Metadata Encoding July 2013 its upstream and downstream flow an end-to-edge protocol can expose flow characteristics to the edge ISP node controlling its access link for both its upstream and downstream flow. This allows the edge node to apply proper treatment to both directions. 2.2.5. Application to Network and Network to Application In accordance with [I-D.eckert-intarea-flow-metadata-framework], flow characteristics may be communication both from application to network as well as from network to application. The encoding rules are the same regardless of the direction of the communication. The ability to differentiate between the two is provided by the transport protocol. For example, when using PCP, application to network communication is via a PCP request, and network to application communication is via a PCP response. 2.2.6. Extensibility New use cases and new deployment scenarios will require the use of new flow characteristics. For this reason the encoding should support Metadata tag additions in a backwards compatible way. New Metadata tag addition supplement but do not redefine existing tags. An application or a network node always signals its currently supported tag set and devices leverage the subset they understand for the purpose of applying treatment to, or gathering information about, the application flows. 2.2.7. Flexibility Distinct use cases and individual applications have a need for different subsets of Metadata tags. The encoding should support the signaling of any subset of Metadata tags for that purpose. For example, a video conferencing application might need to signal metadata for both its audio and video flows. A video surveillance application might signal video flows only, but may need to indicate which one has priority based on embedded analytics. 2.2.8. Per Producer Security Treatment applied on the basis of metadata may involve the consumption of scarce network resources and therefore contribute to their exhaustion. Consequently, integrity, authentication, and authorization are all important aspects of any security mechanism used to secure the metadata. This specification defines an optional security element container; however, the actual security mechanism to be used is outside the scope of this specification. Eckert, et al. Expires January 10, 2014 [Page 6] Internet-Draft Flow Metadata Encoding July 2013 2.2.9. Compact Encoding One of the goals of the encoding described in this specification is to be compact and consume minimal space in the signaling protocol payload. Most of the protocols have limited space for Metadata purposes and do not support semantic fragmentation. The strategy of the encoding is to minimize the encoding structures used for the common signaling case. The common case is foreseen to be the application signaling standard flow characteristics. 3. Encoding specification 3.1. Layout This section describes the encoding layout proposed by this specification. It describes the following: o How the application and network producers coexist using sections in Figure 1 o Application of an optional security token to a section in Figure 2 o The division of a section into standard and vendor specific sub- sections in Figure 3 o The division of a sub-section into upstream and downstream blocks in Figure 4 o A full example using all the encoding building blocks in Figure 5 3.1.1. Sections The flow characteristics are grouped in sections within the encoding. A section pertains to an application or to a network producer. To segregate application and network producer sections the encoding uses a network marker. The application section does not use a network marker and therefore must come first if present. The encoding MUST contain at least an application or a network section. Figure 1 shows an example that contains an application section and two network sections. +--------------------------------+ | Application Section | +--------------------------------+ +--------------------------------+ | Network-1 Marker | +--------------------------------+ +--------------------------------+ Eckert, et al. Expires January 10, 2014 [Page 7] Internet-Draft Flow Metadata Encoding July 2013 | | | | | Network-1 Section | | | +--------------------------------+ +--------------------------------+ | Network-2 Marker | +--------------------------------+ +--------------------------------+ | | | | | Network-2 Section | | | | | | | +--------------------------------+ Figure 1: Encoding section 3.1.2. Security Tokens A section MAY include at most one security token. The security token, if present, MUST appear at the beginning of the section. In the following example, a separate security token is added to each section contained in the previous example. +--------------------------------+ | Security Token | +--------------------------------+ +--------------------------------+ | Application Section | +--------------------------------+ +--------------------------------+ | Network-1 Marker | +--------------------------------+ +--------------------------------+ | Security Token N-1 | +--------------------------------+ +--------------------------------+ | | | | | Network-1 Section | | | +--------------------------------+ +--------------------------------+ | Network-2 Marker | +--------------------------------+ +--------------------------------+ Eckert, et al. Expires January 10, 2014 [Page 8] Internet-Draft Flow Metadata Encoding July 2013 | Security Token N-2 | +--------------------------------+ +--------------------------------+ | | | | | Network-2 Section | | | | | | | +--------------------------------+ Figure 2: Encoding security tokens 3.1.3. Subsections A section may be divided into standard and vendor sub-sections. A section MUST at least have one subsection. A section MUST contain at most one standard sub-section and can contain multiple vendor subsections for different vendors. A standard and a vendor sub- section are segregated through a vendor marker. The standard subsection does not use the vendor marker and therefore must come first if present. Figure 3 shows a sample section content. +--------------------------------+ | | | | | Standard Subsection | | | +--------------------------------+ +--------------------------------+ | Vendor-1 Marker | +--------------------------------+ +--------------------------------+ | Vendor-1 Subsection | | | | | | | | | | | +--------------------------------+ +--------------------------------+ | Vendor-2 Marker | +--------------------------------+ +--------------------------------+ | Vendor-2 Subsection | | | | | | | Eckert, et al. Expires January 10, 2014 [Page 9] Internet-Draft Flow Metadata Encoding July 2013 | | | | +--------------------------------+ Figure 3: Encoding subsections 3.1.4. Upstream and Downstream Blocks A subsection MUST contain at least one upstream or downstream block. A subsection contains at most one upstream block and at most one downstream block. Upstream and downstream blocks are composed of metadata tags, with each tag specifying a flow characteristic. If the upstream and downstream blocks are both present, the upstream block MUST come first. +--------------------------------+ | Upstream block | | +------------+ +------------+ | | | MD tag | | MD tag | | | +------------+ +------------+ | +--------------------------------+ +--------------------------------+ | Downstream block | | +------------+ +------------+ | | | MD tag | | MD tag | | | +------------+ +------------+ | +--------------------------------+ Figure 4: Encoding upstream and downstream blocks 3.1.5. Complete Encoding Example Figure 5 shows a complete example combining the application and network sections together with their standard and vendor sub- sections. The tags appearing in a standard and in a vendor sub- section are managed by separate registries. See [I-D.eckert-intarea-flow-metadata-framework] for a full coverage of the information model and how the registries are handled. +--------------------------------+ | Security Token | +--------------------------------+ +--------------------------------+ ^ ^ | Upstream block | | |A | +------------+ +------------+ | | |P | | MD tag | | MD tag | | |S |P | +------------+ +------------+ | |T |L +--------------------------------+ |D |I Eckert, et al. Expires January 10, 2014 [Page 10] Internet-Draft Flow Metadata Encoding July 2013 +--------------------------------+ | |C | Downstream block | | |A | +------------+ | | |T | | MD tag | | | |I | +------------+ | | |O +--------------------------------+ v |N +--------------------------------+ | | Vendor section marker | |S +--------------------------------+ |E +--------------------------------+ ^ |C | Upstream block | |V |T | +------------+ +------------+ | |N |I | | MD tag | | MD tag | | |D |O | +------------+ +------------+ | | |N +--------------------------------+ v v +--------------------------------+ ^ | Network section marker | | +--------------------------------+ | +--------------------------------+ |N | Security Token | |E +--------------------------------+ |T +--------------------------------+ |W | Downstream block | |O | +------------+ | |R | | MD tag | | |K | +------------+ | | +--------------------------------+ | +--------------------------------+ |S | Vendor section marker | |E +--------------------------------+ |C +--------------------------------+ |T | Downstream block | |I | +------------+ | |O | | MD tag | | |N | +------------+ | | +--------------------------------+ v Figure 5: Complete encoding example 3.1.6. Compact Encoding Example Figure 6 shows an encoding example for flow metadata standard characteristics produced by an application for the upstream (same as 5-tuple) direction. As can be seen in the figure no network marker is used as we are signaling for the application. In the same way there is no vendor marker as we are signaling standard flow characteristics. This example also assumes a use case where no security token is needed. Further examples are given in Appendix A. Eckert, et al. Expires January 10, 2014 [Page 11] Internet-Draft Flow Metadata Encoding July 2013 +--------------------------------+ | Upstream block | | +------------+ +------------+ | | | MD tag | | MD tag | | | +------------+ +------------+ | +--------------------------------+ Figure 6: Compact encoding example 3.2. Encoding Structures This section explores the encoding looking more closely at the encoding structures. Figure 7 shows the encoding used by an application using only standard tags. Figure 8 shows the encoding used by an application using only vendor specific tags. Figure 9 shows the encoding for network producers using only standard tags. The three scenarios expose all the encoding structures. These structures may be combined in various ways to support other scenarios. The encoding makes use of Type Length Value (TLV) as the base building block, plus some level of nesting to create the different encoding structures. The type indicates which encoding structure is in use. In case of a marker, the length gives the size of the marker but not of the delimited section or sub-section. As explained previously, application and network sections MUST contain at least one standard or vendor sub-section and MAY contain a security token. The value of the security token TLV is broken down in two parts, a security-scheme indicating the security method used and the security-value holding the security payload specific to the security scheme. The definition of the different security schemes and their payloads are left to a separate document. The value of the upstream and downstream block TLVs are subdivided in metadata tags. Each tag is itself a TLV specifying a flow characteristic. A metadata tag MUST appear only once in an upstream or a downstream block. On the one hand the security token, the upstream and the downstream block, the vendor and network marker types are defined within the same registry. On the other hand the tag types are defined in a separate registry from the enclosing Eckert, et al. Expires January 10, 2014 [Page 12] Internet-Draft Flow Metadata Encoding July 2013 encoding structures. The separation of the registries is possible as the tags are part of the upstream and downstream block TLV value and therefore do not collide with the encoding structures. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^S | Security-type | Length ||E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C | Security-scheme | :| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :|T : Security-value :|O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+vK | Upstream-type | Length | ^U +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M|P | Tag-type | Length ||D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |B : Tag-value :|T|L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+v |O : ... : |C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vK | Downstream-type | Length | ^D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N | Tag-type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B : Tag-value : |L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O : ... : |C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vK Figure 7 Figure 8 adds the vendor sub-section marker which starts a vendor section. The vendor marker is a TLV whose type is defined in the same registry as the security token. Its value is the vendor's Private Enterprise Number (PEN) allocated by IANA. The vendor marker does not include the downstream and the upstream block but rather sets the context to interpret them. Multiple vendor sub-sections within the same application or network section are allowed as long as they pertain to different vendors. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security-type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security-scheme | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Eckert, et al. Expires January 10, 2014 [Page 13] Internet-Draft Flow Metadata Encoding July 2013 : Security-value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | PEN-type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PEN-id | |V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E | Upstream-type | Length | |N +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D | Tag-type | Length | |O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R : Tag-value : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S : ... : |E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C | Downstream-type | Length | |T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I | Tag-type | Length | |O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N : Tag-value : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : ... : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v Figure 8 Figure 9 adds the network marker that starts a network section. The network marker is a TLV whose type is defined within the same registry as the security token. The value of the network marker is the network precedence that indicates the administrative preference for the network producer flow characteristics. The precedence allows to merge information from different network producers and retain only the preferred one. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | Network-type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Precedence | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Security-type | Length | |P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R | Security-scheme | : |O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : |D : Security-value : |U +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C | Upstream-type | Length | |E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R Eckert, et al. Expires January 10, 2014 [Page 14] Internet-Draft Flow Metadata Encoding July 2013 | Tag-type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S : Tag-value : |E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C : ... : |T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I | Downstream-type | Length | |O +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N | Tag-type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : Tag-value : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : ... : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v Figure 9 All the constructs above can be combined to signal standard and vendor specific tags for different producers and allow to secure each producer's information independently. 3.3. ABNF MD-block = Version (Application-block / 1*Network-block / (Application-block 1*Network-block)) Network-blocks = Network-tlv Producer-block Application-block = Producer-block ; For the application we do not ; require the Producer-tlv Producer-block = [Security-tlv] (Standard-block / 1*Vendor-block / (Standard-block 1*Vendor-block)) Vendor-blocks = PEN-tlv Flow-block Standard-block = Flow-block; We do not require the PEN-tlv ; for the standard tags Flow-block = Upstream-tlv / Downstream-tlv / (Upstream-tlv Downstream-tlv) ; If both present, upstream must come first PEN-tlv = PEN-type Length PEN-id Network-tlv = Network-type Length Precedence Security-tlv = Security-type Length Security-scheme Security-value Eckert, et al. Expires January 10, 2014 [Page 15] Internet-Draft Flow Metadata Encoding July 2013 Upstream-tlv = Upstream-type Length Upstream-value Upstream-value = Attribute-list Downstream-tlv = Downstream-type Length Downstream-value Downstream-value = Attribute-list Attribute-list = 1*(Attribute-tlv) Attribute-tlv = Tag-type Length Attribute-value ;--------- ;TERMINALS ;--------- Version = %x01 ; NEW-VER will be picked up as the first ; version of the encoding PEN-id = 4(OCTET); Private Enterprise Number defined by IANA Length = 2(OCTET); 16-bit length field Precedence = 4(OCTET); Indicates the preferred source of information ; for a producer-type Security-scheme = OCTET; Type of security used Security-value = *(OCTET) ; length of this field must match Length of Security-tlv + 2 Tag-type = 2(OCTET) ; Value according to IANA / Vendor-specific registry Producer-type = Zero %x01; The first foreseen producer is MD-NETWORK ; to cover for DPI engines, gateways and others ; Further values may be allocated later Security-type = Zero %x00 ; Upstream-type = Zero %x01 ; Downstream-type = Zero %x02 ; PEN-type = Zero %x03 ; Network-type = Zero %x04 Eckert, et al. Expires January 10, 2014 [Page 16] Internet-Draft Flow Metadata Encoding July 2013 Attribute-value = *(OCTET) ; Zero = %x00 Figure 10 4. Security Considerations A security token, as described in Section 3.1.2, is a mechanism provided as part of the encoding to protect flow characteristics. A signaling protocol used to transport the encoded metadata may provide additional security mechanisms. The protocol specific and encoding specific security mechanisms may be used in combination to achieve the required level of security. 5. Acknowledgements We would like to thank Yann Poupet and Davide Cuda for reviewing this document and helping us proof its content. We would also like to express our gratitude to Sergio Mena de la Cruz for contributing ideas, proofing the text and for his work on validating the grammar. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [I-D.eckert-intarea-flow-metadata-framework] Eckert, T., Penno, R., Choukir, A., and C. Eckel, "A Framework for Signaling Flow Characteristics between Applications and the Network", draft-eckert-intarea-flow- metadata-framework-00 (work in progress), July 2013. [I-D.martinsen-mmusic-malice] Penno, R., Martinsen, P., Wing, D., and A. Zamfir, "Meta- data Attribute signaLling with ICE", draft-martinsen- mmusic-malice-00 (work in progress), July 2013. [I-D.wing-pcp-flowdata] Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", draft-wing-pcp-flowdata-00 (work in progress), July 2013. [ID-FMD-RSVP] Eckert, et al. Expires January 10, 2014 [Page 17] Internet-Draft Flow Metadata Encoding July 2013 Zamfir, A., "Signaling Flow Characteristics in RSVP", 2013, . Appendix A. Encoding usage examples TBD Authors' Addresses Toerless Eckert (editor) Cisco Systems, Inc. San Jose US Email: eckert@cisco.com Anca Zamfir Cisco Systems, Inc. Lausanne CH Email: ancaz@cisco.com Amine Choukir Cisco Systems, Inc. Lausanne CH Email: amchouki@cisco.com Charles Eckel Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 US Email: eckelcu@cisco.com Eckert, et al. Expires January 10, 2014 [Page 18]