One document matched: draft-martinsen-mmusic-malice-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY rfc5389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!ENTITY rfc4594 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4594.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<?rfc needLines="yes" ?>
<rfc category="std" docName="draft-martinsen-mmusic-malice-00" ipr="trust200902">
<front>
<title abbrev="MALICE">Meta-data Attribute signaLling with ICE</title>
<author fullname="Reinaldo Penno" initials="R." role="editor"
surname="Penno">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region/>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<email>repenno@cisco.com</email>
<uri/>
</address>
</author>
<author fullname="Paal-Erik Martinsen" initials="P.E" surname="Martinsen">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Philip Pedersens vei 20</street>
<city>Lysaker</city>
<region>Akershus</region>
<code>1366</code>
<country>Norway</country>
</postal>
<email>palmarti@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Anca Zamfir" initials="A." surname="Zamfir">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>EPFL, Quartier de l'Innovation</street>
<city>Ecublens</city>
<region>Vaud</region>
<code>1015</code>
<country>Switzerland</country>
</postal>
<email>ancaz@cisco.com</email>
</address>
</author>
<date/>
<workgroup>MMUSIC</workgroup>
<abstract>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Problem Statement">
<t>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
<xref target="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 different points in the
network by using either STUN <xref target="RFC5389"/> packets
sent during ICE's <xref target="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.</t>
<t>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.</t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="Flow -">5-tuple composed on source and destination IP
addresses, IP protocol, source and destination ports.</t>
<t hangText="MALICE Agent -">An ICE agent <xref target="RFC5245"/>
that supports this specification</t>
<t hangText="MALICE Check -">An ICE connectivity check that includes
client metadata and that may include the results from network
elements that have processed the request.</t>
<t hangText="MALICE Message -">An ICE connectivity check message (STUN
Binding request or response) that carries metadata attributes.</t>
<t hangText="Metadata Attribute -">A STUN attribute that contains a
set of information elements in the form of type-lenght-values
(TLVs).</t>
<t hangText="Information Elements -">Information elements (IE) are
TLVs that contain the actual metadata such as minimum bandwidth,
delay tolerance, firewall action, etc.</t>
<t hangText="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.</t>
</list></t>
</section>
<section title="Overview of MALICE">
<t>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 <xref target="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).</t>
<t>The means by which an implementation determines the metadata IEs to
be signaled is out of the scope of this specification. <xref
target="IANA"/> 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.</t>
<t><list style="symbols">
<t>Binding Transaction (REQ-RESP): Endpoint requests flow
prioritization, e.g. by signaling the desired service class (<xref
target="IANA"/>) that includes the minimum and maximum bandwidth,
loss and delay tolerance. The following are examples of services
that could be offered by network elements:<list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
<t>Advisory Transaction (REQ-RESP):<list style="symbols">
<t>Notification Subscription: An endpoint may request the
network to send notifications when certain conditions occur. One
example described in <xref target="IANA"/> 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.</t>
<t>Query : Endpoints may request information from the network.
One example described in <xref target="IANA"/> 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.</t>
</list></t>
<t>Informational Transaction (INFO-ONLY):<list style="symbols">
<t>Endpoints send INFO-ONLY attributes to describe their flows.
This service can be used in managed environments like enterprise
or data center.</t>
</list></t>
</list></t>
<t>The following new comprehensive-optional STUN attributes are defined
in order to support this functionality:</t>
<t><list style="symbols">
<t>MD-AGENT: includes client agent metadata information for the flow
described by the 5-tuple identified in the STUN/ICE header.</t>
<t>MD-RES-UP: contains the result of the request processing by the
network elements on upstream path.</t>
<t>MD-RES-DN: includes the result of the request processing by the
network elements on downstream path.</t>
<t>MD-PEER-CHECK-RES: contains the result of the MALICE check
performed by the peer agent.</t>
<t>MD-INFO: contains flow descriptive information.</t>
</list></t>
<t>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. </t>
<section title="Metadata Attributes">
<t>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.</t>
<section title="Sending and Receiving">
<t>Sending metadata can be done early in the connectivity check
phase of ICE <xref target="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 <xref
target="I-D.muthu-behave-consent-freshness"/> to signal metadata
attributes.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Directionality and Asymmetry">
<t>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.</t>
<t>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:</t>
<t><list style="hanging">
<t hangText="STUN Request">On-path devices only process upstream
attributes and if necessary update the original request message
with the result.</t>
<t hangText="STUN Response">On-path devices only process
downstream attributes and if necessary update the original
response message with the result.</t>
</list>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.</t>
</section>
<section title="Network Element Processing">
<t>When processing MALICE messages, NEs generally perform the
following steps:</t>
<t><list style="numbers">
<t>Intercept and read the metadata attributes from the
connectivity or consent freshness checks.</t>
<t>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.).</t>
<t>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.</t>
<t>Forwards the MALICE message downstream.</t>
</list>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.</t>
</section>
<section title="MALICE Client and Server Processing">
<t>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.</t>
<t>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 <xref target="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.</t>
</section>
</section>
<section title="Connectivity Checks">
<t>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.</t>
<t>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).</t>
<section title="MALICE to non-MALICE">
<t>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.</t>
</section>
<section title="MALICE to MALICE">
<t>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.</t>
<figure title="FLOW-METADATA MALICE to MALICE">
<artwork><![CDATA[
Alice router1 router2 Bob
| | | |
|Binding_Request | | |
(1)|--------------------->|(2) | |
| | | |
| |Binding_Request | |
| |------------------------------------->|
| | | |
| | | Binding_Response |
| | |<-----------------|(3)
| | Binding_Response | |
|<-----------------------------------------|(4) |
|(5) | | |
]]></artwork>
</figure>
<t><list style="numbers">
<t>Alice creates a Binding Request, adds MD-AGENT and result
(MD-RESP-UP and MD-RESP-DN) attributes with desired metadata
information elements.</t>
<t>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.</t>
<t>Bob processes the Binding Request as described in the ICE RFC
<xref target="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.</t>
<t>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.</t>
<t>When Alice receives the Binding Response message, the same
processing described in ICE RFC <xref target="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).</t>
</list></t>
</section>
</section>
<section title="Keepalives">
<t>This specification proposes the use of consent freshness messages
<xref target="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. </t>
</section>
<section title="Aggressive Nomination">
<t>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, 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 <xref target="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).</t>
</section>
<section title="Implications on Concluding ICE">
<t>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.</t>
<figure>
<artwork><![CDATA[ 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)}]]></artwork>
</figure>
<t>Notations:</t>
<t>L is the controlling agent.</t>
<t>{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.</t>
<t>MDrl is a an overall success/fail type of indication for the
MALICE check R->L</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Lite Implementations and MALICE">
<t>As described in <xref target="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.</t>
</section>
</section>
<section title="Performing Connectivity Checks">
<t>This section describes how MALICE agents perform connectivity checks
and how network elements process and modify the information in the
connectivity check messages.</t>
<section title="MALICE Client Procedures">
<section title="Building the MALICE Request">
<t>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 <xref target="IANA"/> are
included in the connectivity checks performed by MALICE agents.</t>
<t>The Client agent starts the connectivity check by sending a STUN
binding request following the procedures described in Section 7.1.2
of <xref target="RFC5245"/>. A MALICE client MAY include metadata
attributes in the request. The way the application determines the
attributes to be 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).</t>
<t>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.</t>
</section>
<section title="Processing MALICE Responses">
<t>A MALICE agent processes a STUN binding response and depending on
the presence of metadata attributes, their contents, and the
procedures of <xref target="RFC5245"/> section 7.1.3.1 the result of
MALICE connectivity check is considered unknown, failure or success
as described below</t>
<section title="Unknown">
<t>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.</t>
<t>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.</t>
</section>
<section title="Failure">
<t>In the presence of a MALICE peer, a MALICE check is considered
failed if either of the following is true:</t>
<t><list style="symbols">
<t>the ICE check has failed as described in Section 7.1.3.1 of
<xref target="RFC5245"/>.</t>
<t>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.</t>
</list></t>
</section>
<section title="Success">
<t>A MALICE check is considered successful if all of the following
are true:</t>
<t><list style="symbols">
<t>the ICE check as described in Section 7.1.3.1 of <xref
target="RFC5245"/> has succeeded.</t>
<t>the Binding response indicates that MALICE NEs have
satisfactorily processed all the RESP-REQ information
elements.</t>
</list></t>
</section>
</section>
</section>
<section title="MALICE Network Element Procedures">
<t>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 <xref target="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.</t>
<t>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 <xref
target="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.</t>
<t>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.</t>
<t>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.</t>
<section title="Adding a new Metadata IE">
<t>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.</t>
<t>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.</t>
<figure title="Upstream Attribute Initial Signaling">
<artwork><![CDATA[ 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
]]></artwork>
</figure>
<t>Similar processing happens for downstream attributes except that
the NE's actions (intercept, flow state creation, etc.) happen when a
STUN response is intercepted.</t>
<t>There are many possible transaction types for "X=A". For
example:</t>
<t><list style="symbols">
<t>Endpoint requests a particular service: "Reserve BW=5Mbps",
the endpoint requests a 5Mbps reservation.</t>
<t>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.</t>
<t>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.</t>
</list>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.</t>
</section>
<section title="Removing a Metadata IE">
<t>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 <xref
target="I-D.muthu-behave-consent-freshness"/>.</t>
<t>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:
<list style="numbers">
<t>Alice signals metadata X=A for the first time. Actions are
described in the previous section.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<figure title="Upstream Attribute Removal">
<artwork><![CDATA[ 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
<---------...................------------
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
]]></artwork>
</figure>
</section>
<section title="Changing a metadata IE">
<t>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.</t>
<t>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.</t>
<figure title="Upstream Attribute Change">
<artwork><![CDATA[ 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
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
]]></artwork>
</figure>
</section>
<section title="Network Element Response Change">
<t>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.</t>
</section>
<section title="Solving Conflicts in Metadata Attribute Values">
<t>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.</t>
<t>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.</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<figure title="Upstream Attribute Conflict">
<artwork><![CDATA[ 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!
<- 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)
]]></artwork>
</figure>
<t>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.</t>
<figure title="Network Analytics and Notifications">
<artwork><![CDATA[ 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=<>
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
]]></artwork>
</figure>
</section>
<section title="Conflict Resolution ">
<t>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:</t>
<t><list style="symbols">
<t>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.</t>
<t>Binding transactions (QoS): the following attributes are
currently defined:<list style="symbols">
<t>Bandwidth: UP/DOWN Max Bandwidth, UP/DOWN Min
Bandwidth</t>
<t>Service Class: UP/DOWN Delay, Loss and Jitter tolerance
- specified as: 0=undefined, 1=very low, 2=low, 3=medium,
4=high</t>
<t>Priority: UP/DOWN DSCP</t>
</list>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.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="MALICE Server Procedures">
<t>When the Malice Server agent receives a STUN Request it follows the
same rules described in Section 7.2 of <xref target="RFC5245"/>. In
addition, when building the STUN Response the following rules MUST be
followed:<list style="symbols">
<t>MD-AGENT and MD-RESP-UP attributes are inserted before
INTEGRITY</t>
<t>If the result of the local MALICE check is present, an
MD-PEER-CHECK-RES attribute with the result is included before
INTEGRITY</t>
<t>A copy of the MD-RESP-DN attribute received in the STUN Request
is included unmodified after INTEGRITY</t>
</list></t>
</section>
</section>
<section title="Concluding MALICE Processing">
<t>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.</t>
<t>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.</t>
</section>
<section title="Subsequent Connectivity Checks">
<t>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.</t>
</section>
<section title="Security Considerations">
<section title="STUN Inspection">
<t>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 <xref target="RFC6398"/>.</t>
<t>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)
<xref target="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.</t>
<t>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.</t>
<t>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]</t>
</section>
<section title="Authentication">
<t>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.</t>
</section>
</section>
<section anchor="STUN_Extensions" title="STUN Extensions">
<section title="New Attributes ">
<t>This specification defines five new attributes, MD-AGENT, MD-REALM,
MD-RESP-UP, MD-RESP-DN and MD-PEER-CHECK.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>In addition, two new sub-TLVs are defined to provide flow
prioritization service. This specification allows for easy addition of
IEs in the future.<list style="symbols">
<t>FLOWDATA Request sub-TLV is included in the MD-AGENT STUN
attribute and indicates the desired flow treatment</t>
<t>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</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>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]</t>
<section title="STUN Attribute TLV Definitions">
<t>This section registers four new STUN attributes per the procedures
in <xref target="RFC5389"/>.</t>
<figure>
<artwork align="center"><![CDATA[
0x0C02: MD-AGENT
0x0C03: MD-RESP-UP
0x0C04: MD-RESP-DN
0x0C05: MD-PEER-CHECK
]]></artwork>
</figure>
<section title="MD-AGENT Attribute">
<t>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.</t>
<figure anchor="MD-AGENT" title="MD-AGENT Attribute">
<artwork align="right"><![CDATA[
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> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="MD-RESP-UP and MD-RESP-DN Attributes">
<t>Network 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 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.</t>
<figure anchor="MD-RESP-" title="MD-RESP- Attribute">
<artwork align="right"><![CDATA[
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> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where MD-RESP-* = {MD-RESP-UP | MD-RESP-DN}</t>
</section>
<section title="MD-PEER-CHECK Attribute">
<figure anchor="MD-PEER-CHECK" title="MD-PEER-CHECK Attribute">
<artwork align="right"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Peer Malice Check Result - "Success" or "Failure".</t>
</section>
</section>
<section title="Metadata Attributes sub-TLV Definitions">
<t>Metadata information elements are encoded in sub-TLV format and
included in MD-AGENT and MD-RESP-* STUN attributes described
earlier.</t>
<section title="FLOWDATA Request">
<t>The FLOWDATA IE has the following format.</t>
<figure anchor="flowdata_request" title="FLOWDATA Request">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| uDT | uLT | uJT | RSVD1 | dDT | dLT | dJT | RSVD2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Max Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Max Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Type:">TBD (optional to process)</t>
<t hangText="Reserved:">Must be 0 and ignored by the server.</t>
<t hangText="Length:">Option Length is 32 octets.</t>
<t hangText="May appear in:">STUN/ICE Binding Request and
Response, inside the MD-AGENT STUN attribute</t>
<t hangText="Maximum occurrences:">1</t>
</list>Description of the fields:</t>
<t><list style="hanging">
<t hangText="Instance Identifier:">Instance identifier, see
below for description.</t>
<t hangText="uDT:">Upstream Delay Tolerance, 0 means no
information is available. 1=very low, 2=low, 3=medium,
4=high.</t>
<t hangText="uLT:">Upstream Loss Tolerance, 0 means no
information is available. 1=very low, 2=low, 3=medium,
4=high.</t>
<t hangText="uJT:">Upstream Jitter Tolerance, 0 means no
information is available. 1=very low, 2=low, 3=medium,
4=high.</t>
<t hangText="RSVD1:">Reserved (7 bits), MUST be ignored on
reception and MUST be 0 on transmission</t>
<t hangText="dDT:">Downstream Delay Tolerance, 0 means no
information is available. 1=very low, 2=low, 3=medium,
4=high.</t>
<t hangText="dLT:">Downstream Loss Tolerance, 0 means no
information is available. 1=very low, 2=low, 3=medium,
4=high.</t>
<t hangText="dJT:">Downstream Jitter Tolerance, 0 means no
information available. 1=very low, 2=low, 3=medium, 4=high.</t>
<t hangText="RSVD2:">Reserved (7 bits), MUST be ignored on
reception and MUST be 0 on transmission.</t>
<t hangText="Upstream Minimum Bandwidth">Minimum Upstream
bandwidth in bytes per second, 0 means no information is
available.</t>
<t hangText="Downstream Minimum Bandwidth:">Minimum Downstream
bandwidth in bytes per second, 0 means no information is
available.</t>
<t hangText="Upstream Maximum Bandwidth:">Maximum Upstream
bandwidth in bytes per second, 0 means no information is
available.</t>
<t hangText="Downstream Maximum Bandwidth:">Maximum Downstream
bandwidth in bytes per second, 0 means no information is
available.</t>
</list>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.</t>
</section>
<section title="FLOWDATA Response">
<t>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.</t>
<figure anchor="flowdata_response" title="FLOWDATA Response">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Type:">TBD (optional to process)</t>
<t hangText="Reserved:">Must be 0 and ignored by the server.</t>
<t hangText="Length:">Option Length is 24 octets.</t>
<t hangText="May appear in:">STUN/ICE Binding Request and
Response, inside the MD-RESP-UP and/or MD-RESP-DN STUN
attributes.</t>
<t hangText="Maximum occurrences:">1</t>
</list>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.</t>
<t>Description of the fields: <list style="hanging">
<t hangText="Reserved:">96 bits, MUST be ignored on reception
and MUST be 0 on transmission.</t>
<t hangText="DT:">Delay Tolerance, 0 means no information is
available.</t>
<t hangText="LT:">Loss Tolerance, 0 means no information is
available.</t>
<t hangText="JT:">Jitter Tolerance, 0 means no information is
available.</t>
<t hangText="Reserved:">Reserved (7 bits), MUST be ignored on
reception and MUST be 0 on transmission</t>
<t hangText="Minimum Bandwidth">Minimum bandwidth in bytes per
second, 0 means no information is available.</t>
<t hangText="Maximum Bandwidth:">Maximum bandwidth in bytes per
second, 0 means no information is available.</t>
</list></t>
</section>
<section title="Usage Example">
<t>This section describes how the STUN protocol elements defined
above are used to implement flow prioritization.<list
style="symbols">
<t>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.<list style="symbols">
<t>Binding Request sent by MALICE Client:<list
style="symbols">
<t>MD-AGENT (InstID=0, uDT=1, uLT=1, uJT=1, dDT=2,
dLT=2, dJT=2, uMinBW=4mbps, uMaxBW=5mbps, uMinBW=5mbps,
MaxBW=10mbps)</t>
<t>MD-RESP-UP (DT=0, LT=0, JT=0, MinBW=0mbps,
MaxBW=0mbps)</t>
<t>MD-RESP-DN (DT=0, LT=0, JT=0, MinBW=0mbps,
MaxBW=0mbps)</t>
</list></t>
<t>Binding Response received by MALICE Client:<list
style="symbols">
<t>MD-AGENT (InstID=0, uDT=1, uLT=1, uJT=1, dDT=2,
dLT=2, dJT=2, uMinBW=4mbps, uMaxBW=5mbps, uMinBW=5mbps,
MaxBW=10mbps)</t>
<t>MD-ATTR-UP (DT=1, LT=1, JT=1, MinBW=4mbps,
MaxBW=5mbps)</t>
<t>MD-ATTR-DN (DT=2, LT=2, JT=2, MinBW=4mbps,
MaxBW=5mbps)</t>
<t>MD-PEER-CHECK-RES ("Success")</t>
</list></t>
</list></t>
</list></t>
</section>
</section>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Authors would like to thank Paul Jones, Sergio Mena de la
Cruz and Tirumaleswar Reddy for their
comments and review.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<?rfc include="reference.RFC.4732"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.6398"?>
<?rfc include="reference.RFC.5245"?>
</references>
<references title="Informational References">
<?rfc include='reference.I-D.ietf-rtcweb-security-arch' ?>
<?rfc include='reference.I-D.muthu-behave-consent-freshness' ?>
</references>
<!--
-->
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:48 |