[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00 draft-martinsen-tram-discuss

MMUSIC                                                     R. Penno, Ed.
Internet-Draft                                              P. Martinsen
Intended status: Standards Track                                 D. Wing
Expires: January 03, 2014                                      A. Zamfir
                                                                   Cisco
                                                           July 02, 2013


                Meta-data Attribute signaLling with ICE
                    draft-martinsen-mmusic-malice-00

Abstract

   It can be useful for applications to provide flow metadata
   information to on-path devices to influence flow treatment in the
   network.  Provided that the network is able to provide useful
   feedback, this can also influence path selection if an application
   have multiple flow paths to choose from.

   This draft describes how this can be achieved by adding metadata to
   the STUN packets sent during the ICE connectivity checks or a
   slightly modified version of the keep-alive mechanism.  Devices on
   the media path can use the metadata information to prioritize the
   flow, perform traffic engineering, or provide network analytics and
   notifications as requested by the endpoints.  On-path devices can
   append or modify the existing metadata information in the STUN/ICE
   messages to enable feedback to other on-path devices or the
   applications in both ends of the media session.

   This document describes a framework mechanism for how such metadata
   can be transported by STUN when ICE is in use and it covers the
   endpoint and on path device processing.  The functionality described
   here is referred to as MALICE.

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 RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.







Penno, et al.           Expires January 03, 2014                [Page 1]


Internet-Draft                   MALICE                        July 2013


   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 03, 2014.

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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview of MALICE  . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Metadata Attributes . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Sending and Receiving . . . . . . . . . . . . . . . .   6
       3.1.2.  Directionality and Asymmetry  . . . . . . . . . . . .   7
       3.1.3.  Network Element Processing  . . . . . . . . . . . . .   8
       3.1.4.  MALICE Client and Server Processing . . . . . . . . .   8
     3.2.  Connectivity Checks . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  MALICE to non-MALICE  . . . . . . . . . . . . . . . .   9
       3.2.2.  MALICE to MALICE  . . . . . . . . . . . . . . . . . .   9
     3.3.  Keepalives  . . . . . . . . . . . . . . . . . . . . . . .  10
     3.4.  Aggressive Nomination . . . . . . . . . . . . . . . . . .  10
     3.5.  Implications on Concluding ICE  . . . . . . . . . . . . .  11
     3.6.  Lite Implementations and MALICE . . . . . . . . . . . . .  12
   4.  Performing Connectivity Checks  . . . . . . . . . . . . . . .  12
     4.1.  MALICE Client Procedures  . . . . . . . . . . . . . . . .  12
       4.1.1.  Building the MALICE Request . . . . . . . . . . . . .  12
       4.1.2.  Processing MALICE Responses . . . . . . . . . . . . .  13



Penno, et al.           Expires January 03, 2014                [Page 2]


Internet-Draft                   MALICE                        July 2013


     4.2.  MALICE Network Element Procedures . . . . . . . . . . . .  14
       4.2.1.  Adding a new Metadata IE  . . . . . . . . . . . . . .  14
       4.2.2.  Removing a Metadata IE  . . . . . . . . . . . . . . .  16
       4.2.3.  Changing a metadata IE  . . . . . . . . . . . . . . .  18
       4.2.4.  Network Element Response Change . . . . . . . . . . .  19
       4.2.5.  Solving Conflicts in Metadata Attribute Values  . . .  19
       4.2.6.  Conflict Resolution . . . . . . . . . . . . . . . . .  22
     4.3.  MALICE Server Procedures  . . . . . . . . . . . . . . . .  23
   5.  Concluding MALICE Processing  . . . . . . . . . . . . . . . .  23
   6.  Subsequent Connectivity Checks  . . . . . . . . . . . . . . .  24
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
     7.1.  STUN Inspection . . . . . . . . . . . . . . . . . . . . .  24
     7.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .  25
   8.  STUN Extensions . . . . . . . . . . . . . . . . . . . . . . .  25
     8.1.  New Attributes  . . . . . . . . . . . . . . . . . . . . .  25
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
     9.1.  STUN Attribute TLV Definitions  . . . . . . . . . . . . .  26
       9.1.1.  MD-AGENT Attribute  . . . . . . . . . . . . . . . . .  26
       9.1.2.  MD-RESP-UP and MD-RESP-DN Attributes  . . . . . . . .  26
       9.1.3.  MD-PEER-CHECK Attribute . . . . . . . . . . . . . . .  27
     9.2.  Metadata Attributes sub-TLV Definitions . . . . . . . . .  27
       9.2.1.  FLOWDATA Request  . . . . . . . . . . . . . . . . . .  27
       9.2.2.  FLOWDATA Response . . . . . . . . . . . . . . . . . .  29
       9.2.3.  Usage Example . . . . . . . . . . . . . . . . . . . .  31
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  32
     11.2.  Informational References . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Problem Statement

   In the context of Content, Mobile, Fixed Service, Service Providers,
   Enterprise and Private networks have a need to prioritize packet
   flows end-to-end.  These flows are often dynamic, time-bound,
   encrypted, peer-to-peer, possibly asymmetric, and might have
   different priorities depending on network conditions, direction, time
   of the day, dynamic user preferences and other factors.  These
   factors may be time variant, and thus need to be signalled.
   Moreover, in many cases of peer-to-peer communication, flow
   information is known only to the endpoint.  These considerations,
   coupled with the trend to use encryption for browser-to-browser
   communication [I-D.ietf-rtcweb-security-arch], imply that access
   lists, deep packet inspection and other static prioritization methods
   cannot be employed successfully to prioritize packet flows.  It can
   also be useful for the endpoints to provide flow metadata and receive
   network feedback in order select an optimal media communication path.
   This specification describes how these problems can be solved at



Penno, et al.           Expires January 03, 2014                [Page 3]


Internet-Draft                   MALICE                        July 2013


   different points in the network by using either STUN [RFC5389]
   packets sent during ICE's [RFC5245] connectivity check phase during
   establishment of a media session, or as part a slightly modified
   keep-alive mechanism after the session is established.  Devices on
   the media path can use the metadata information to prioritize the
   flow, perform traffic engineering, or provide network analytics and
   notifications as requested by the endpoints.  On-path devices can
   append or modify the existing metadata information in the STUN/ICE
   messages.  The ICE agents may use this information to learn about the
   status of their requests at on-path devices.

   This document describes a framework mechanism for how such metadata
   can be transported by STUN when ICE is in use with UDP based media
   and it covers the endpoint and middlebox processing.  The
   functionality described here is referred to as MALICE.

2.  Terminology

   Metadata -  Information and actions associated with a flow but not
      used for matching.  For example, firewall and NAT actions,
      application name, Diffserv marking actions, media-type, amongst
      others.

   Flow -  5-tuple composed on source and destination IP addresses, IP
      protocol, source and destination ports.

   MALICE Agent -  An ICE agent [RFC5245] that supports this
      specification

   MALICE Check -  An ICE connectivity check that includes client
      metadata and that may include the results from network elements
      that have processed the request.

   MALICE Message -  An ICE connectivity check message (STUN Binding
      request or response) that carries metadata attributes.

   Metadata Attribute -  A STUN attribute that contains a set of
      information elements in the form of type-lenght-values (TLVs).

   Information Elements -  Information elements (IE) are TLVs that
      contain the actual metadata such as minimum bandwidth, delay
      tolerance, firewall action, etc.

   Network Elements -  Devices such as middleboxes, routers, Wireless
      Access LAN controller, amongst others.  The terms network element
      and node are used interchangeably in the text.





Penno, et al.           Expires January 03, 2014                [Page 4]


Internet-Draft                   MALICE                        July 2013


3.  Overview of MALICE

   In a typical ICE deployment there are two endpoints, known as agents
   in ICE terminology, that attempt ICE message exchanges in order to
   discover one or more paths over which they can send and recieve
   media.  The ICE exchange protocol is defined in [RFC5245].  This
   specification proposes an extension to the ICE protocol that allows
   applications to request services from the network, and learn about
   the status of these requests and of the media paths they use.  This
   is achieved by signaling flow and network metadata attributes between
   endpoints and network elements (NEs).

   The means by which an implementation determines the metadata IEs to
   be signaled is out of the scope of this specification.  Section 9
   covers different scenarios where metadata may be of use.  This
   specification defines three types of transaction that can be signaled
   by a MALICE agent and acted upon by NEs.

   o  Binding Transaction (REQ-RESP): Endpoint requests flow
      prioritization, e.g. by signaling the desired service class
      (Section 9) that includes the minimum and maximum bandwidth, loss
      and delay tolerance.  The following are examples of services that
      could be offered by network elements:

      *  IntServ: Network elements on path may perform admission control
         against the desired service class.  If resources are not
         available, a middlebox may return an error (or allocated BW =
         0) or it may try to admit the flow in a lower service class.
         In the latter case, the middlebox will update the response with
         the new service class.  If resources are available, they are
         allocated for the flow and guaranteed (in a stable network) for
         the lifetime of the flow.

      *  DiffServ: A middlebox may perform flow classification.  Flows
         are guaranteed QoS as long as there is no oversubscription.  If
         the corresponding service queue becomes full, drops and delays
         affect all flows in that service class.

   o  Advisory Transaction (REQ-RESP):

      *  Notification Subscription: An endpoint may request the network
         to send notifications when certain conditions occur.  One
         example described in Section 9 is notification when congestion
         is about to occur in the class of service associated with the
         flow.  Other services in this category may be defined in the
         future.





Penno, et al.           Expires January 03, 2014                [Page 5]


Internet-Draft                   MALICE                        July 2013


      *  Query : Endpoints may request information from the network.
         One example described in Section 9 is an endpoint requesting
         the currently available bandwidth, delay and loss tolerance of
         the service class associated with the flow.  Network elements
         update the response STUN attributes if local values are more
         restrictive than the ones carried in the message.  At the end
         of the request/response check, the endpoint has the information
         about the end-to-end b/w, delay and loss characteristics of the
         path.

   o  Informational Transaction (INFO-ONLY):

      *  Endpoints send INFO-ONLY attributes to describe their flows.
         This service can be used in managed environments like
         enterprise or data center.

   The following new comprehensive-optional STUN attributes are defined
   in order to support this functionality:

   o  MD-AGENT: includes client agent metadata information for the flow
      described by the 5-tuple identified in the STUN/ICE header.

   o  MD-RES-UP: contains the result of the request processing by the
      network elements on upstream path.

   o  MD-RES-DN: includes the result of the request processing by the
      network elements on downstream path.

   o  MD-PEER-CHECK-RES: contains the result of the MALICE check
      performed by the peer agent.

   o  MD-INFO: contains flow descriptive information.

   The client agent includes a combination of MD-AGENT, MD-RESP-UP and
   MD-RESP-DN to create one of the three transaction types described
   above.  In addition, the FLOWDATA sub-TLV is defined to support flow
   prioritization through a Binding Transaction.

3.1.  Metadata Attributes

   The main focus of this specification is around the services described
   in the previous section which are implemented through REQ-RESP
   attribute signaling.  For these services, most of the actions
   described here apply.

3.1.1.  Sending and Receiving





Penno, et al.           Expires January 03, 2014                [Page 6]


Internet-Draft                   MALICE                        July 2013


   Sending metadata can be done early in the connectivity check phase of
   ICE [RFC5245] section-7 and the result of metadata processing may be
   taken into account by the controlling agent during the nomination
   process.  Once a candidate pair is selected to be used for media,
   MALICE agents use the consent freshness mechanism described in
   [I-D.muthu-behave-consent-freshness] to signal metadata attributes.

   If a server agent supports MALICE, it MUST reflect back in the STUN
   Binding Response message the metadata attributes that were received
   in the STUN Binding Request.  It is up to the server agent whether to
   use the metadata present in the binding request for its own purposes,
   for example adjusting the metadata it will put in its own binding
   request.

   Network Elements on the path that are MALICE capable may intercept
   and read the metadata attributes from the connectivity or consent
   freshness checks.  They may also update the message with the result
   of a REQ-RESP request.  When doing so, the NEs MUST NOT add
   significant delay while attribute processing is in progress and
   SHOULD wait for the next refresh message for result update.

3.1.2.  Directionality and Asymmetry

   It is important to mention that some attributes may be bidirectional
   in nature, while others may be associated with a given direction.  A
   bi-directional attribute is represented by individual upstream and
   downstream attributes.

   In order to take into account directionality and routing asymmetry
   the following rules are proposed for the STUN Binding request/
   response messages used in connectivity check and consent freshness
   mechanism:

   STUN Request  On-path devices only process upstream attributes and if
      necessary update the original request message with the result.

   STUN Response  On-path devices only process downstream attributes and
      if necessary update the original response message with the result.

   Due to asymmetric routing, a NE may see only binding request or
   response messages for a given candidate pair and therefore it may
   read and process metadata for upstream only, downstream only or both.
   In some cases, upstream and downstream paths may span the same node
   but over different interfaces and in this case a middlebox may need
   to use different ingress and/or egress interface policies for the two
   directions of the media.





Penno, et al.           Expires January 03, 2014                [Page 7]


Internet-Draft                   MALICE                        July 2013


3.1.3.  Network Element Processing

   When processing MALICE messages, NEs generally perform the following
   steps:

   1.  Intercept and read the metadata attributes from the connectivity
       or consent freshness checks.

   2.  Depending on the metadata information elements carried in the
       message and on the current state (e.g. resource availability,
       policies, etc.), a node may perform certain actions (e.g. install
       local policies for the flow described by the message, start
       monitoring the flow, perform marking, etc.).

   3.  If the results of these actions are readily available, the
       network element should include them in the currently intercepted
       message.  Otherwise any required response is conveyed in the next
       refresh message.

   4.  Forwards the MALICE message downstream.

   The current specification makes sure that network elements do not
   have to change the STUN message size, instead the MD-RESP-*
   attributes are inserted as place holders for updates from network.

3.1.4.  MALICE Client and Server Processing

   The MALICE client agent includes metadata information elements in the
   new MD-AGENT STUN attribute defined in this specification.  The MD-
   AGENT attribute MUST be included before INTEGRITY.  If a response is
   required for all or a subset of these information elements, the
   client agent may also include the new MD-RESP-DN (before INTEGRITY)
   and MD-RESP-UP (after INTEGRITY) as place holders that can be used by
   on-path devices to provide a response.

   When a MALICE server agent receives a Binding Request, it copies the
   MD-AGENT and the MD-RESP-UP TLV in the response, adds the INTEGRITY
   attribute and then inserts the MD-RESP-DN attribute to be filled by
   on path nodes for the downstream direction.  When forming the
   response (success or error), the agent running the server follows the
   rules of Section 6 of [RFC5389].  It MUST NOT send an 'Error
   Response' message class if the processing of metadata attributes is
   the only one that has failed.  Instead the MALICE error indications
   are included in the MD-RESP-UP to communicate to the client the
   success/error indications for the metadata processing.

3.2.  Connectivity Checks




Penno, et al.           Expires January 03, 2014                [Page 8]


Internet-Draft                   MALICE                        July 2013


   Connectivity checks are extended by this specification to include
   metadata attributes in both request and response messages.  In the
   presence of REQ-RESP metadata attributes, a MALICE agent may consider
   the connectivity check successful if responses for the check received
   indicate success.  It is not necessary that the metadata attribute
   results, if present, also indicate success.

   The MALICE Server agent MAY also include the new MD-PEER-CHECK-RES
   TLV defined in this specification if it has already performed a
   MALICE check and has the result available.  This is useful if the
   MALICE Server is the controlled agent and wishes to influence the
   nomination process at MALICE Client (controlling agent).

3.2.1.  MALICE to non-MALICE

   A MALICE client agent does not have prior knowledge if the peer
   supports this specification.  If the peer agent is not MALICE
   capable, it will not reflect back the metadata STUN attributes.
   Therefore a MALICE client agent will know if peer is MALICE capable
   after the first exchange of the connectivity check.  The client may
   choose to continue to signal the metadata attributes to benefit from
   possible upstream network element processing but should not expect
   any results from the network.

3.2.2.  MALICE to MALICE

   A remote MALICE agent echoes back in the Binding Response message all
   metadata received in the request.  In the example below MALICE
   upstream network elements (router1 in the diagram below) processes
   MD-AGENT and MD-RESP-UP attributes present in the STUN binding
   request while MD-AGENT and MD-RESP-DOWN attributes present in the
   STUN binding response are processed by network elements (router2) in
   the downstream path.

     Alice                router1            router2              Bob
      |                      |                   |                  |
      |Binding_Request       |                   |                  |
   (1)|--------------------->|(2)                |                  |
      |                      |                   |                  |
      |                      |Binding_Request    |                  |
      |                      |------------------------------------->|
      |                      |                   |                  |
      |                      |                   | Binding_Response |
      |                      |                   |<-----------------|(3)
      |                      |  Binding_Response |                  |
      |<-----------------------------------------|(4)               |
      |(5)                   |                   |                  |




Penno, et al.           Expires January 03, 2014                [Page 9]


Internet-Draft                   MALICE                        July 2013


                      FLOW-METADATA MALICE to MALICE

   1.  Alice creates a Binding Request, adds MD-AGENT and result (MD-
       RESP-UP and MD-RESP-DN) attributes with desired metadata
       information elements.

   2.  Router1 inspects the Request message and, if allowed (based on
       realm, security and policy considerations), reads MD-AGENT
       attribute and its information elements.  If the result of
       processing is available, router1 writes the result in the MD-
       RESP-UP attribute.  It then forwards the request.

   3.  Bob processes the Binding Request as described in the ICE RFC
       [RFC5245](Section 7.2).  When Bob builds the response, it copies
       the metadata attribute MD-AGENT and the MD-RESP-UP attributes
       into the Binding Response and adds MD-RESP-DN after the integrity
       attribute.  Bob then transmits the message.

   4.  Router2 (first MALICE network element for the downstream
       direction) inspects the Response message, reads the metadata
       attribute and MAY change the result (MD-RESP-DN) including the
       local results if available.  It then transmits the message.

   5.  When Alice receives the Binding Response message, the same
       processing described in ICE RFC [RFC5245] (Section 7.1.3)
       applies.  Then it extracts the metadata upstream and downstream
       attributes.  If Alice's agent has the controlling role, it may
       take into account this information during the candidate pair
       selection step (if this check was part of the initial
       connectivity check sequence).

3.3.  Keepalives

   This specification proposes the use of consent freshness messages
   [I-D.muthu-behave-consent-freshness] in place of indications in order
   to have up to date results on the MALICE checks used by media.  This
   is required since network conditions may change during the lifetime
   of a flow resulting in changes, including new failure indications, in
   MALICE responses.

3.4.  Aggressive Nomination

   With aggressive nomination, the controlling agent includes the
   nominated flag in every connectivity check it sends for all media
   components.  Once the first check for a component succeeds, it is
   added to the valid list with the nominated flag set.  The nominated
   candidate pair may start being used by the media at any time after.
   This lowers the chance of MALICE results to be collected.  Therefore,



Penno, et al.           Expires January 03, 2014               [Page 10]


Internet-Draft                   MALICE                        July 2013


   if the controlling MALICE agent expects to consider the metadata
   attribute processing result into the candidate pair selection
   process, it SHOULD NOT use aggressive nomination.  The controlled
   MALICE agent does not have a way to influence the peer with respect
   to the nomination procedure used.  If the peer is non-MALICE, the
   agent SHOULD NOT signal any MD attributes.  If a MALICE agent chooses
   to use the aggressive nomination, the endpoints should be prepared
   for transient candidate selection as described in Section 8.1.1.2 of
   [RFC5245].  Using aggressive nomination is an implementation trade-
   off between quick call initiation versus waiting to determine the
   best path (using regular nomination and waiting until MALICE checks
   finish).

3.5.  Implications on Concluding ICE

   When the MALICE client agent receives the STUN binding response it
   extracts the metadata results.  A controlling agent may choose to
   ignore the received metadata information or consider it in the
   decision process.  The figure below shows MALICE used in a regular
   nomination process.

      L(Malice)                            R(Malice)
      ---------                            ---------

             <---- STUN request + {MDrl(i)}     \  R's
        STUN response ------------->            /  check
        + {MDrl(i)}
                                          local result: MDrl


        STUN request + {MDlr(i)} --------->     \  L's
                 <----- STUN response           /  check
                        + {MDlr(i)}
                        + MDrl (result)

        local result: MDlr
        e2e result: comp(MDlr, MDrl)

        STUN request + {MDlr(i)} + flag ---->   \  L's
                 <----- STUN response           /  check
                        + {MDlr(i)}


   Notations:

   L is the controlling agent.





Penno, et al.           Expires January 03, 2014               [Page 11]


Internet-Draft                   MALICE                        July 2013


   {MDrl(i)} is the set of metadata attributes sent from R to L in the
   request.  In the (2nd, 3rd,..) response back they will also include
   the result.  Similar notation for the checks in the other direction.

   MDrl is a an overall success/fail type of indication for the MALICE
   check R->L

   comp(MDlr, MDrl) - is a function that determines the overall end to
   end MALICE result based on both local check result and the one from
   the peer.

   If a connectivity check response is received for an already nominated
   pair, the controlling agent may inform the application but MUST NOT
   restart the nomination process.  In the case where the result of a
   MALICE check is not available in the response at the time of
   nomination, any subsequent MALICE results become informative.

3.6.  Lite Implementations and MALICE

   As described in [RFC5245], lite ICE implementations do not send
   connectivity checks but only reply to them.  A lite ICE
   implementation may be extended to become a lite MALICE implementation
   by adding the functionality associated with the MALICE Server.  When
   a lite MALICE server agent receives a STUN binding request, it copies
   the metadata related attributes as described in earlier sections.  A
   lite MALICE implementation will never include an MD-PEER-CHECK-RES
   attribute in the STUN binding response, since it never runs ICE or
   MALICE checks.

4.  Performing Connectivity Checks

   This section describes how MALICE agents perform connectivity checks
   and how network elements process and modify the information in the
   connectivity check messages.

4.1.  MALICE Client Procedures

4.1.1.  Building the MALICE Request

   This section describes how STUN and ICE are extended to include
   metadata attributes and refers to them in generic terms.  The new
   attributes and their usage defined in Section 9 are included in the
   connectivity checks performed by MALICE agents.

   The Client agent starts the connectivity check by sending a STUN
   binding request following the procedures described in Section 7.1.2
   of [RFC5245].  A MALICE client MAY include metadata attributes in the
   request.  The way the application determines the attributes to be



Penno, et al.           Expires January 03, 2014               [Page 12]


Internet-Draft                   MALICE                        July 2013


   sent to the MALICE agent for signaling is outside the scope of this
   specification.  The client agent may reduce the attribute set based
   on other factors (e.g. MTU considerations).

   The client encodes metadata information in the MD-AGENT attribute.
   It then builds the MD-RESP-UP and MD-RESP-DN attributes, including an
   information element for each REQ-RESP attribute for which a response
   is desired.  The values in these IEs are initialized as described in
   the corresponding metadata information element section.  MD-AGENT and
   MD-RESP-DN MUST be included before INTEGRITY, and MD-RESP-UP after
   INTEGRITY so that it can be changed by on-path devices.

4.1.2.  Processing MALICE Responses

   A MALICE agent processes a STUN binding response and depending on the
   presence of metadata attributes, their contents, and the procedures
   of [RFC5245] section 7.1.3.1 the result of MALICE connectivity check
   is considered unknown, failure or success as described below

4.1.2.1.  Unknown

   If the STUN response message does not include any metadata related
   STUN attributes, this is an indication that the peer is not MALICE
   capable.  In this case the client should change the pair state to
   Succeeded.

   It is possible that the STUN Client receives a response that includes
   metadata STUN attributes, but doesn't include any valid results from
   NEs or STUN Server.  This can happen if NEs are not MALICE enabled.

4.1.2.2.  Failure

   In the presence of a MALICE peer, a MALICE check is considered failed
   if either of the following is true:

   o  the ICE check has failed as described in Section 7.1.3.1 of
      [RFC5245].

   o  the client determines that the metadata included by an on-path
      device in the Binding response does not meet its criteria for
      success.  The success criteria is application dependent and
      outside the scope of this specification.









Penno, et al.           Expires January 03, 2014               [Page 13]


Internet-Draft                   MALICE                        July 2013


4.1.2.3.  Success

   A MALICE check is considered successful if all of the following are
   true:

   o  the ICE check as described in Section 7.1.3.1 of [RFC5245] has
      succeeded.

   o  the Binding response indicates that MALICE NEs have satisfactorily
      processed all the RESP-REQ information elements.

4.2.  MALICE Network Element Procedures

   A MALICE network element intercepts ICE request and response
   messages, reads metadata information from the MD-AGENT attribute and
   triggers corresponding processing.  When the result of this
   processing is available, the MALICE node MAY update the MD-RESP-xx
   attribute carried in the message.  As a consequence, it is
   recommended (and stated [RFC5245]) that the agent perform a few
   identical checks in order to allow NEs to react to and communicate
   the result of the metadata processing.

   MALICE NEs consume router resources to maintain per flow state and,
   depending on the information elements and requests, to enforce per
   flow QoS or perform monitoring.  State and associated attributes are
   considered alive as long as periodic refresh messages that include
   those attributes are received.  In the absence of refreshes
   [I-D.muthu-behave-consent-freshness] or if attributes cease to be
   present in those refreshes, attributes time out, associated resources
   are released and state may be removed.

   MALICE agents can signal the same metadata information elements for a
   flow.  Therefore it is possible that different STUN messages types
   containing the same information elements, with same or different
   values, are seen by NEs.  It is also possible that the two agents
   signal different metadata for the same flow.

   During the lifetime of a session, agents can change the values of
   information elements, remove or add new IEs.  It is also possible
   that a NE changes the result values over the lifetime of a session.
   A NE should determine if a newly intercepted STUN message indicates a
   refresh versus a change as compared to the previously intercepted
   message.  A refresh resets the lifetime of an IE and state.  A change
   indicates if new IEs are being created or if existing ones are being
   modified or removed.

4.2.1.  Adding a new Metadata IE




Penno, et al.           Expires January 03, 2014               [Page 14]


Internet-Draft                   MALICE                        July 2013


   When a new IE is signaled in a STUN message, a network element should
   create state for the flow if not already present, and trigger any
   required processing.  If the network element, while processing the
   metadata attribute, will add significant delay and cause timeouts in
   the agent state machines, it is recommended that it forwards the STUN
   message and use the next refresh message to provide the results.
   When the next STUN message is received, the NE should provide the
   result of processing this information element only if the locally
   stored (and acted upon) value is the same as the one in the newly
   received message.  Otherwise a removal or modification has occurred.

   The diagram below illustrates the exchange and processing when a new
   IE is added.  Alice sends a STUN request upstream with attribute MD-
   RESP-UP, MD-AGENT and IE X=A. The network element creates the f(L,R)
   state where it stores the requested metadata value (m: X=A), the
   context it was received from (s: MALICE request) and the result of
   processing (r: x=N).  It then updates the response attribute MD-RESP-
   UP in the STUN request with X=N and forwards it to Bob. Bob reflects
   back the original metadata requested value and the result.

      Alice(L)          NE                Bob(R)
      --------          ---                ------

      Alice's STUN Request
       x=A for Upstream (L->R)

      IE   x=A                         IE   x=A
      resp x=<>                        resp x=N
      ---------------->      ----------------->
                    f(L,R): create:
                      m: x=A, s: req
                      r: x=N

      <---------...................------------
                                       IE   x=A
                                       resp x=N



                   Upstream Attribute Initial Signaling

   Similar processing happens for downstream attributes except that the
   NE's actions (intercept, flow state creation, etc.) happen when a
   STUN response is intercepted.

   There are many possible transaction types for "X=A".  For example:





Penno, et al.           Expires January 03, 2014               [Page 15]


Internet-Draft                   MALICE                        July 2013


   o  Endpoint requests a particular service: "Reserve BW=5Mbps", the
      endpoint requests a 5Mbps reservation.

   o  Endpoint requests network notification: "Notify if BW < 5Mbps",
      the endpoint requires a notification when the queue capacity used
      for this flow falls below the 5Mbps limit.

   o  Endpoint request statistics for the flow path: "BW=<>", where <>
      is the unspecified value for attribute BW, the endpoint requires a
      response with the current available queue capacity used for this
      flow.

   It is assumed in the rest of this specification that the attribute,
   information element and/or context unambiguously identify the actions
   required at network element.

4.2.2.  Removing a Metadata IE

   Flow state and all its metadata ages out and should be removed when
   the state has not been refreshed recently by a request or response
   message.  The way to determine the timeout interval is described in
   [I-D.muthu-behave-consent-freshness].

   In addition, metadata must be immediately deleted and associated
   resources released if the IE is not present in any subsequent
   messages for the flow.  An IE should be considered stale and removed
   if it ceases to appear in STUN requests or responses (section 3.1.2)
   having the same 5-tuple flow.  As illustrated in the diagram below, a
   NE implementation should keep track of the source and value of the
   IEs received and detect per source addition, change and removal.
   More details are provided in the next sections.  In the diagram below
   Bob's messages do not go through the NE element:

   1.  Alice signals metadata X=A for the first time.  Actions are
       described in the previous section.

   2.  Bob signals the same value and equivalent direction for X and in
       his STUN request, this is copied in the STUN Response from Alice
       to Bob. When the NE intercepts this L->R response message, it
       extracts X=A, retrieves the existing information f(L,R) and adds
       MALICE Response as a new source.

   3.  Alice sends a new check without any metadata attributes.  The NE
       retrieves the f(L,R) state and removes the MALICE Request from
       the source list.  The flow state is maintained as the NE still
       sees refreshes for X in the L->R responses to Bob's checks.





Penno, et al.           Expires January 03, 2014               [Page 16]


Internet-Draft                   MALICE                        July 2013


   4.  Bob sends a new STUN connectivity check without any attributes.
       The NE retrieves the f(L,R) state and removes the MALICE Response
       from the source list.  Since X has no source, it also removes X
       from the metadata information element list and releases any
       resources associated with X. And because the flow state has no
       more attributes, it also removes the state.

      Alice(L)          NE                Bob(R)
      --------          ---                ------

      Alice's STUN Request                       (1)
       x=A for Upstream (L->R)

      IE   x=A                         IE   x=A
      resp x=<>                        resp x=N
      ---------------->      ----------------->
                    f(L,R): create:
                      m: x=A, s: req
                      r: x=N

      <---------...................------------
                                       IE   x=A
                                       resp x=N



                             Bob's STUN Request  (2)
                      x=A for Downstream (L->R)

                                       IE  x=A
                                      resp x=<>
      <---------...................<-----------

      IE   x=A                         IE   x=A
      resp x=<>                        resp x=N
      ---------------->      ----------------->
                    f(L,R): update
                      a: x=A, s: req
                         x=A, s: resp
                      r: x=N


      Alice's STUN Request                       (3)
       no attributes
      ---------------->      ----------------->
                    f(L,R): update
                      a: x=A, s: resp
                      r: x=N



Penno, et al.           Expires January 03, 2014               [Page 17]


Internet-Draft                   MALICE                        July 2013


      <---------...................------------


                             Bob's STUN Request  (4)
                                  no attributes
      <---------...................<-----------
      ---------------->      ----------------->
                    f(L,R): update
                      a: <none>, s:<none>
                      r: x=N
                    f(L,R): release resources for X
                            remove state


                        Upstream Attribute Removal

4.2.3.  Changing a metadata IE

   It is possible for a client to change an IE value.  Every request/
   response message contains an MD-RESP-xx attribute with "not
   specified" values when sent from the agent.  In other words, the
   agent does not include the result from previous check.  When a node
   detects a change in an attribute value it should trigger the
   appropriate actions.  Like in the case of initial attribute creation,
   the node should provide the answer in the next refresh message if the
   answer is not immediately available.

   In the diagram below, Alice changes the value of information element
   X from A to B in the second STUN request which causes the network
   element to provide a different response.

      Alice(L)          NE                Bob(R)
      --------          ---                ------

      Alice's STUN Request                       (1)
       x=A for Upstream (L->R)

      IE   x=A                         IE   x=A
      resp x=<>                        resp x=N
      ---------------->      ----------------->
                    f(L,R): create
                      m: x=A, s: req
                      r: x=N

      <---------...................------------
                                       IE   x=A
                                       resp x=N




Penno, et al.           Expires January 03, 2014               [Page 18]


Internet-Draft                   MALICE                        July 2013


     Alice's STUN Request                       (2)
       x=B for Upstream (L->R)

      IE   x=B                         IE   x=B
      resp x=<>                        resp x=M
      ---------------->      ----------------->
                    f(L,R): update
                      m: x=B, s: req
                      r: x=M

      <---------...................------------
                                       IE   x=B
                                       resp x=M


                         Upstream Attribute Change

4.2.4.  Network Element Response Change

   It is possible that the network element result of processing of an IE
   changes as resource availability changes, e.g. new links are added
   and removed, new flows come and go, etc.  For example, a NE can
   change the bandwidth available for a flow and may need to update the
   MD-RESP-xx attribute if the local value is more restrictive (e.g.
   less bandwidth, lower delay tolerance, etc.) than the one included in
   the message.  Again, it is important for this node to check that the
   MD-AGENT attribute includes the same attribute and value for which
   the answer is provided.

4.2.5.  Solving Conflicts in Metadata Attribute Values

   A conflict in a metadata information element occurs when the two
   agents signal different values for same IE and for the same direction
   of the flow.

   A conflict occurs for an IE X in the upstream direction if the values
   of X in the L check request are different than in the R check
   response.  When a NE detects an IE conflict it SHOULD keep both
   values.  If the IE is part of binding request, the MALICE node must
   perform conflict resolution as described in the diagram below and act
   on the result.

   1.  Alice sends a request for X with value A for the upstream
       direction.  The NE intercepts the message, creates f(L,R) state
       and stores X=A remembering this was received in Alice's request.
       The NE then determines that the response to A should be N,
       therefore it updates the STUN message and forwards it to Bob.




Penno, et al.           Expires January 03, 2014               [Page 19]


Internet-Draft                   MALICE                        July 2013


   2.  Bob sends a request for X with value B for the upstream
       direction.  The NE intercepts the response for the Bob->Alice
       request, extracts X=B from the response, looks up f(L,R) flow
       state, stores (x=B, s:resp) and determines that a conflict has
       occurred for attribute X since (x=A, s: req) is present in the
       state.  The NE runs the conflict resolution and determines that
       x=B should be the value used, determines that the result of
       processing B is M, updates the STUN response and forwards the
       response to Bob.

   3.  When the next refresh for X with value A is received from Alice,
       the NE updates the result to M and forwards the request to Bob.
       Bob reflects back the result in the response and Alice receives
       the changed result.

      Alice(L)          NE               Bob(R)
      --------          --               ------

      Alice's STUN Request                       (1)
       x=A for Upstream (L->R)

      IE   x=A                         IE   x=A
      resp x=<>                        resp x=N
      ---------------->      ----------------->
                    f(L,R): create:
                      m: x=A, s: req
                      r: x=N

      <---------...................------------
                                   IE UP(x=A)
                                   resp UP(x=N)



                             Bob's STUN Request  (2)
                      x=A for Downstream (L->R)

                                       IE  x=B
                                      resp x=<>
      <---------...................<-----------

      IE   x=B                         IE   x=B
      resp x=<>                        resp x=M
      ---------------->      ----------------->
                    f(L,R): update
                      m: x=A, s: req
                         x=B, s: resp
                          <- conflict detected!



Penno, et al.           Expires January 03, 2014               [Page 20]


Internet-Draft                   MALICE                        July 2013


                          <- resolution x=B
                      r: x=M



      Alice's STUN Request                       (3)
       x=A for Upstream (L->R)

      IE   x=A                         IE   x=A
      resp x=<>                        resp x=M
      ---------------->      ----------------->
                    f(L,R): refresh:
                      m: x=A, s: req
                         x=B, s: resp
                      r: x=M

      <---------...................------------
                                   attr UP(x=A)
                                   resp UP(x=M)


                        Upstream Attribute Conflict

   Note that for INFO-ONLY and ADVISORY transactions a conflict
   resolution cannot occur and, therefore, results should be kept per
   source.  Typical NE resources allocated for these attributes are
   monitors created to detect conditions or collect network statistics.
   It is up to the implementation to decide on what can be shared in
   terms of resources in this case.  In the diagram below, for
   illustration purposes, a second monitor is created for Bob's
   notification request.

      Alice(L)          Mid                Bob(R)
      --------          ---                ------

      Alice's STUN Request                       (1)
       Notif for UP BW < 10Mbps

      IE   bw=10Mbps                  IE  bw=10M
      resp bw=<>                     resp bw=<>
      ---------------->      ----------------->
                    f(L,R): create:
                      m: bw=10M, s: req
                      r: bw=<>, start monitor

      <---------...................------------
                                    attr bw=10M
                                    resp bw=<>



Penno, et al.           Expires January 03, 2014               [Page 21]


Internet-Draft                   MALICE                        July 2013


      Alice's STUN Request                       (2)
       First refresh after condition

      IE   bw=10Mbps                   IE bw=10Mbps
      resp bw=<>                     resp bw=8Mbps
      ---------------->      ----------------->
                    f(L,R): create:
                      m: bw=10Mbps, s: req
                      r: bw=8Mbps, keep monitor

      <---------...................------------
                                       IE bw=10Mbps
                                     resp bw=8Mbps


                             Bob's STUN Request  (3)
                      x=A for Downstream (L->R)

                                     IE   bw=6Mbps
                                     resp bw=<>
      <---------...................<-----------

      IE   bw=6Mbps                    IE bw=6Mbps
      resp bw=<>                     resp bw=<>
      ---------------->      ----------------->
                    f(L,R): update
                      m: bw=10Mbps, s: req
                      r: bw=8Mbps, keep monitor
                      m: bw=6Mbps, s: resp
                      r: bw=<>, start monitor2


                    Network Analytics and Notifications

4.2.6.  Conflict Resolution

   The definition/description of an information element must include a
   description of how conflict resolution should be done by network
   elements.  Below are a few examples:

   o  Informational only transactions: the IEs included are signaled in
      the upstream direction only and they are processed by middleboxes
      on path with the STUN request.  They should never generate
      conflicts.

   o  Binding transactions (QoS): the following attributes are currently
      defined:




Penno, et al.           Expires January 03, 2014               [Page 22]


Internet-Draft                   MALICE                        July 2013


      *  Bandwidth: UP/DOWN Max Bandwidth, UP/DOWN Min Bandwidth

      *  Service Class: UP/DOWN Delay, Loss and Jitter tolerance -
         specified as: 0=undefined, 1=very low, 2=low, 3=medium, 4=high

      *  Priority: UP/DOWN DSCP

      For all these attributes the conflicts are resolved by choosing
      the less strict values (apply a MIN function).  For example,
      assume Alice and Bob request the same service class.  If Alice
      requests 10Mbps UP bandwidth, Bob requests 5Mbps DOWN bandwidth
      and there are 7Mbps available for the service class specified in
      the request, the middlebox should allocate 5Mbps and update the
      result in Alice's check STUN Response.  If Alice and Bob request
      different service classes, the less restrictive is first selected
      and then the MIN function is applied to the bandwidth values.

   o  Advisory transactions (Network Analytics): there should not be any
      conflict resolution applied to these attributes.  It is perfectly
      valid for Alice to request different network analytics than Bob or
      different thresholds for congestion notifications.  As shown in
      the previous diagram, middleboxes should keep track of the
      different sources for a given attribute and, in case of network
      attributes, keep per source results and maybe resources.

4.3.  MALICE Server Procedures

   When the Malice Server agent receives a STUN Request it follows the
   same rules described in Section 7.2 of [RFC5245].  In addition, when
   building the STUN Response the following rules MUST be followed:

   o  MD-AGENT and MD-RESP-UP attributes are inserted before INTEGRITY

   o  If the result of the local MALICE check is present, an MD-PEER-
      CHECK-RES attribute with the result is included before INTEGRITY

   o  A copy of the MD-RESP-DN attribute received in the STUN Request is
      included unmodified after INTEGRITY

5.  Concluding MALICE Processing

   A MALICE Controlling agent is expected to run regular nomination
   only.  This specification also reinforces the recommendation to run a
   number of checks before nominating a pair.  This increases the
   probability of receiving network element and peer MALICE responses
   and therefore having more information for the nomination process.





Penno, et al.           Expires January 03, 2014               [Page 23]


Internet-Draft                   MALICE                        July 2013


   When nominating a pair, the controlling agent may consider the MALICE
   information received in the last STUN Response and give preference to
   the pair whose connectivity check indicated favorable network
   conditions.

6.  Subsequent Connectivity Checks

   It is possible for a MALICE Client to request a service and include
   metadata attributes after the nomination process.  It is also
   possible that a successful MALICE check for the nominated (active)
   pair fails during the media session lifetime.  The MALICE Client will
   have at all times the current status of the MALICE check for the
   active pair.  The actions that the client takes when these change are
   currently out of the scope of this document.  In the absence of
   support for other specification, these MALICE check status changes
   are informative only.

7.  Security Considerations

7.1.  STUN Inspection

   Network elements processing STUN packets are open to denial of
   service attacks from endpoints when there is no previous
   authorization and indication of which STUN messages should be
   inspected.  The vulnerability and attack vector is similar to those
   documented for the IP router alert option in [RFC6398].

   Flooding a NE with bogus (or simply undesired) STUN messages that
   contain metadata could impact its operation in undesirable ways.  For
   example, if the NE punts the datagrams containing STUN messages to
   the slow path, such an attack could consume a significant share of
   the NE's slow path and could also lead to packet drops in the slow
   path (affecting operation of all other applications and protocols
   operating in the slow path), thereby resulting in a denial of service
   (DoS) [RFC4732].  Like with other protocols, it is recommended that
   network elements that implement this functionality use rate limited
   queues when punting STUN messages.  In addition, it is recommended
   that the implementation enforces limits on the number of states
   created by the MALICE connectivity checks.

   However, the main issue is that the STUN message does not provide a
   convenient universal mechanism to accurately and reliably distinguish
   between interesting and unwanted messages.  This, in turn, creates a
   security concern when the STUN metadata attribute is used, because,
   short of appropriate network element- implementation-specific
   mechanisms, the NE slow path is at risk of being flooded by unwanted
   traffic.




Penno, et al.           Expires January 03, 2014               [Page 24]


Internet-Draft                   MALICE                        July 2013


   One solution to this problem is to include a precursor authorization
   step where a third-party device authorizes the endpoint and populates
   the NE with 5-tuple information of the packet carrying the STUN
   message.  [TODO: Reference third party authorization draft]

7.2.  Authentication

   While endpoints are able to authenticate STUN messages received by a
   peer endpoint, network elements are unable to authenticate STUN
   messages.  Further, endpoints are not fully trusted by network
   elements, so network elements need some assurance that what is
   signaled has been authorized by an application server that defines
   policies or attributes for a given media flow.  Even if an endpoint
   is well-behaved, the network elements need a means of ensuring STUN
   messages are not altered during transmission.

8.  STUN Extensions

8.1.  New Attributes

   This specification defines five new attributes, MD-AGENT, MD-REALM,
   MD-RESP-UP, MD-RESP-DN and MD-PEER-CHECK.

   o  The MD-AGENT is inserted in the Binding request by the client
      agent and copied in the Binding response by the server agent.  It
      includes the flow metadata generated by the client agent.

   o  The MD-RESP-UP is inserted by the client agent in the Binding
      request and updated by MALICE nodes on upstream path.  A MALICE
      server agent copies this attribute in the response message.

   o  The MD-PEER-CHECK attribute is inserted by the MALICE server agent
      in the response message and includes the result of the MALICE
      check executed by the server agent.

   o  The MD-RESP-DN is inserted by the client agent in the Binding
      request, copied by the MALICE server agent in the response and
      updated by MALICE nodes on downstream path.

   In addition, two new sub-TLVs are defined to provide flow
   prioritization service.  This specification allows for easy addition
   of IEs in the future.

   o  FLOWDATA Request sub-TLV is included in the MD-AGENT STUN
      attribute and indicates the desired flow treatment






Penno, et al.           Expires January 03, 2014               [Page 25]


Internet-Draft                   MALICE                        July 2013


   o  FLOWDATA Response sub-TLV is included in the MD-RESP-* STUN
      attributes and indicates, when received by the client in the STUN
      Binding Response, the result of the processing

9.  IANA Considerations

   This specification registers five new STUN attributes.  All
   attributes include metadata informational elements.  Section 10.2
   describes a possible STUN specific encoding for these.  Another
   proposal can be found in [I-D.draft-flow-metadata-encoding] and [I-D
   .draft-flow-metadata-framework]

9.1.  STUN Attribute TLV Definitions

   This section registers four new STUN attributes per the procedures in
   [RFC5389].


        0x0C02: MD-AGENT
        0x0C03: MD-RESP-UP
        0x0C04: MD-RESP-DN
        0x0C05: MD-PEER-CHECK


9.1.1.  MD-AGENT Attribute

   Metadata attributes are encoded in sub-TLV format with each sub-TLV
   corresponding to an information element or metadata.  Section 10.3
   describes in detail the information elements that can be included in
   the MD-AGENT attribute.  When parsing the STUN request and response,
   the MD-AGENT STUN attribute Length should be used to identify the
   location of next STUN attribute.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MD-AGENT              |            Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 <Attribute Block sub-TLV format>              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 1: MD-AGENT Attribute

9.1.2.  MD-RESP-UP and MD-RESP-DN Attributes

   Network Metadata attributes are encoded in sub-TLV format with each
   sub-TLV corresponding to an information element or metadata.



Penno, et al.           Expires January 03, 2014               [Page 26]


Internet-Draft                   MALICE                        July 2013


   Section 10.3 describes in detail the network information elements
   that can be included.  When parsing the STUN request and response,
   the MD-RESP-XX STUN attribute Length should be used to identify the
   location of next STUN attribute.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            MD-RESP-*          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 <Attribute Block sub-TLV format>              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 2: MD-RESP- Attribute

   Where MD-RESP-* = {MD-RESP-UP | MD-RESP-DN}

9.1.3.  MD-PEER-CHECK Attribute

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     MD-PEER-CHECK-RES         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Reserved              |   Peer Malice Check Result    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 3: MD-PEER-CHECK Attribute

   Peer Malice Check Result - "Success" or "Failure".

9.2.  Metadata Attributes sub-TLV Definitions

   Metadata information elements are encoded in sub-TLV format and
   included in MD-AGENT and MD-RESP-* STUN attributes described earlier.

9.2.1.  FLOWDATA Request

   The FLOWDATA IE has the following format.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type=TBD   |   Reserved    |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |



Penno, et al.           Expires January 03, 2014               [Page 27]


Internet-Draft                   MALICE                        July 2013


   |                    Instance Identifier                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | uDT | uLT | uJT |   RSVD1     | dDT | dLT | dJT |    RSVD2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upstream Min Bandwidth                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Downstream Min Bandwidth                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upstream Max Bandwidth                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Downstream Max Bandwidth                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: FLOWDATA Request

   Type:  TBD (optional to process)

   Reserved:  Must be 0 and ignored by the server.

   Length:  Option Length is 32 octets.

   May appear in:  STUN/ICE Binding Request and Response, inside the MD-
      AGENT STUN attribute

   Maximum occurrences:  1

   Description of the fields:

   Instance Identifier:  Instance identifier, see below for description.

   uDT:  Upstream Delay Tolerance, 0 means no information is available.
      1=very low, 2=low, 3=medium, 4=high.

   uLT:  Upstream Loss Tolerance, 0 means no information is available.
      1=very low, 2=low, 3=medium, 4=high.

   uJT:  Upstream Jitter Tolerance, 0 means no information is available.
      1=very low, 2=low, 3=medium, 4=high.

   RSVD1:  Reserved (7 bits), MUST be ignored on reception and MUST be 0
      on transmission

   dDT:  Downstream Delay Tolerance, 0 means no information is
      available. 1=very low, 2=low, 3=medium, 4=high.

   dLT:  Downstream Loss Tolerance, 0 means no information is available.
      1=very low, 2=low, 3=medium, 4=high.



Penno, et al.           Expires January 03, 2014               [Page 28]


Internet-Draft                   MALICE                        July 2013


   dJT:  Downstream Jitter Tolerance, 0 means no information available.
      1=very low, 2=low, 3=medium, 4=high.

   RSVD2:  Reserved (7 bits), MUST be ignored on reception and MUST be 0
      on transmission.

   Upstream Minimum Bandwidth  Minimum Upstream bandwidth in bytes per
      second, 0 means no information is available.

   Downstream Minimum Bandwidth:  Minimum Downstream bandwidth in bytes
      per second, 0 means no information is available.

   Upstream Maximum Bandwidth:  Maximum Upstream bandwidth in bytes per
      second, 0 means no information is available.

   Downstream Maximum Bandwidth:  Maximum Downstream bandwidth in bytes
      per second, 0 means no information is available.

   The instance identifier accommodates network traffic where multiple
   5-tuples exist for a particular data flow, but the bandwidth flows
   only over the aggregate of the multiple 5-tuples.  One example of
   this are a phone call which rings on two phones.  Only one of those
   phones will answer first (and send data).  FLOWDATA is signaled for
   both of those phone's IP addresses and ports, using the same Instance
   Identifier, indicating to the network that the flow data is being
   shared with those two different 5-tuples.  Another example is TCP
   video streaming which retrieves short pieces of the movie, often over
   separate TCP connections for load balancing, which would use the same
   Instance Identifier for each TCP connection.  The way the instance
   identifier is determined is out of the scope of this document.

9.2.2.  FLOWDATA Response

   This IE is meant for responses from network to endpoint.  It can be
   included in MD-RESP-UP or MD-RESP-DN, therefore indicating the
   direction for which the response applies.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type=TBD   |  Reserved     |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        Reserved                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  DT |  LT |  JT |                 Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Penno, et al.           Expires January 03, 2014               [Page 29]


Internet-Draft                   MALICE                        July 2013


   |                        Min Bandwidth                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Min Bandwidth                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 5: FLOWDATA Response

   Type:  TBD (optional to process)

   Reserved:  Must be 0 and ignored by the server.

   Length:  Option Length is 24 octets.

   May appear in:  STUN/ICE Binding Request and Response, inside the MD-
      RESP-UP and/or MD-RESP-DN STUN attributes.

   Maximum occurrences:  1

   When included in MD-RESP-UP TLV the FLOWDATA Response indicate the
   response from middleboxes that are on the upstream path.  When
   included in MD-RESP-DN TLV the FLOWDATA Response indicate the
   response from middleboxes that are on the downsteam path.

   Description of the fields:

   Reserved:  96 bits, MUST be ignored on reception and MUST be 0 on
      transmission.

   DT:  Delay Tolerance, 0 means no information is available.

   LT:  Loss Tolerance, 0 means no information is available.

   JT:  Jitter Tolerance, 0 means no information is available.

   Reserved:  Reserved (7 bits), MUST be ignored on reception and MUST
      be 0 on transmission

   Minimum Bandwidth  Minimum bandwidth in bytes per second, 0 means no
      information is available.

   Maximum Bandwidth:  Maximum bandwidth in bytes per second, 0 means no
      information is available.









Penno, et al.           Expires January 03, 2014               [Page 30]


Internet-Draft                   MALICE                        July 2013


9.2.3.  Usage Example

   This section describes how the STUN protocol elements defined above
   are used to implement flow prioritization.

   o  Endpoint Metadata Request (REQ-RESP) - Flow Prioritization:
      Endpoint asks flow prioritization by including in the Binding
      request non-0 values in the FLOWDATA Request and values
      initialized to 0 in MD-RESP-UP and MD-RESP-DN TLVs.  Upstream
      MALICE nodes update the MD-RESP-UP with the results.  Peer
      includes in the Binding response the received MD STUN TLVs and the
      MD-PEER-CHECK-RESP.  Downstream MALICE nodes update the MD-RESP-DN
      TLV.  In the example below, the endpoint received the required
      prioritization for the upstream direction and a lower than
      requested one for downstream.

      *  Binding Request sent by MALICE Client:

         +  MD-AGENT (InstID=0, uDT=1, uLT=1, uJT=1, dDT=2, dLT=2,
            dJT=2, uMinBW=4mbps, uMaxBW=5mbps, uMinBW=5mbps,
            MaxBW=10mbps)

         +  MD-RESP-UP (DT=0, LT=0, JT=0, MinBW=0mbps, MaxBW=0mbps)

         +  MD-RESP-DN (DT=0, LT=0, JT=0, MinBW=0mbps, MaxBW=0mbps)

      *  Binding Response received by MALICE Client:

         +  MD-AGENT (InstID=0, uDT=1, uLT=1, uJT=1, dDT=2, dLT=2,
            dJT=2, uMinBW=4mbps, uMaxBW=5mbps, uMinBW=5mbps,
            MaxBW=10mbps)

         +  MD-ATTR-UP (DT=1, LT=1, JT=1, MinBW=4mbps, MaxBW=5mbps)

         +  MD-ATTR-DN (DT=2, LT=2, JT=2, MinBW=4mbps, MaxBW=5mbps)

         +  MD-PEER-CHECK-RES ("Success")

10.  Acknowledgements

   Authors would like to thank Paul Jones, Sergio Mena de la Cruz and
   Tirumaleswar Reddy for their comments and review.









Penno, et al.           Expires January 03, 2014               [Page 31]


Internet-Draft                   MALICE                        July 2013


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4732]  Handley, M., Rescorla, E., IAB, "Internet Denial-of-
              Service Considerations", RFC 4732, December 2006.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6398]  Le Faucheur, F., "IP Router Alert Considerations and
              Usage", BCP 168, RFC 6398, October 2011.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

11.2.  Informational References

   [I-D.ietf-rtcweb-security-arch]
              Rescorla, E., "RTCWEB Security Architecture", draft-ietf-
              rtcweb-security-arch-06 (work in progress), January 2013.

   [I-D.muthu-behave-consent-freshness]
              Perumal, M., Wing, D., R, R., and H. Kaplan, "STUN Usage
              for Consent Freshness", draft-muthu-behave-consent-
              freshness-03 (work in progress), February 2013.

Authors' Addresses

   Reinaldo Penno (editor)
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose  95134
   USA

   Email: repenno@cisco.com









Penno, et al.           Expires January 03, 2014               [Page 32]


Internet-Draft                   MALICE                        July 2013


   Paal-Erik Martinsen
   Cisco Systems, Inc.
   Philip Pedersens vei 20
   Lysaker, Akershus  1366
   Norway

   Email: palmarti@cisco.com


   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: dwing@cisco.com


   Anca Zamfir
   Cisco Systems, Inc.
   EPFL, Quartier de l'Innovation
   Ecublens, Vaud  1015
   Switzerland

   Email: ancaz@cisco.com


























Penno, et al.           Expires January 03, 2014               [Page 33]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/