draft-ietf-tram-stun-path-data-03.txt   draft-ietf-tram-stun-path-data-04.txt 
TRAM T. Reddy TRAM P. Martinsen
Internet-Draft D. Wing Internet-Draft T. Reddy
Intended status: Standards Track P. Martinsen Intended status: Standards Track D. Wing
Expires: July 30, 2016 Cisco Expires: December 22, 2016 Cisco
V. Singh V. Singh
callstats.io callstats.io
January 27, 2016 June 20, 2016
Discovery of path characteristics using STUN Measurement of Round Trip Time and Fractional Loss Using STUN
draft-ietf-tram-stun-path-data-03 draft-ietf-tram-stun-path-data-04
Abstract Abstract
A host with multiple interfaces needs to choose the best interface A host with multiple interfaces needs to choose the best interface
for communication. Oftentimes, this decision is based on a static for communication. Oftentimes, this decision is based on a static
configuration and does not consider the path characteristics, which configuration and does not consider the path characteristics, which
may affect the user experience. may affect the user experience.
This document describes a mechanism for an endpoint to discover the This document describes a mechanism for an endpoint to measure the
path characteristics using Session Traversal Utilities for NAT (STUN) path characteristics fractional loss and RTT using Session Traversal
messages. The measurement information can then be used to influence Utilities for NAT (STUN) messages.
the endpoint's Interactive Connectivity Establishment (ICE) candidate
pair selection algorithm.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 30, 2016. This Internet-Draft will expire on December 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Path characteristics determination mechanism . . . . . . . . 3 3. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . 3
3.1. The PATH-CHARACTERISTIC attribute in request . . . . . . 4 3.1. TRANSACTION_TRANSMIT_COUNTER attribute . . . . . . . . . 4
3.2. The PATH-CHARACTERISTIC attribute in response . . . . . . 5 3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 5
3.3. Example Operation . . . . . . . . . . . . . . . . . . . . 6 3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 5
4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The ICE [RFC5245] mechanism uses a prioritization formula to order This document extends STUN [RFC5389] to make it possible to correlate
the candidate pairs and perform connectivity checks, in which the STUN responses to specific request when re-transmits occur. This
most preferred address pairs are tested first and when a sufficiently assists the client in determining path characteristics like round-
good pair is discovered, that pair is used for communications and trip time (RTT) and fractional packet loss.
further connectivity tests are stopped. This approach works well for
an endpoint with a single interface, but is too simplistic for
endpoints with multiple interfaces, wherein a candidate pair with a
lower priority might in fact have better path characteristics (e.g.,
round-trip time, loss, etc.). The ICE connectivity checks can assist
in measuring the path characteristics, but as currently defined, the
STUN responses to re-transmitted requests are indistinguishable from
each other.
This draft extends STUN [RFC5389] to distinguish STUN responses to The TRANSACTION_TRANSMIT_COUNTER attribute introduced in section
re-transmitted requests and this assists the client in determining Section 3.1 can be used in ICE [RFC5245] connectivity checks (STUN
the path characteristics like round-trip time (RTT) and packet loss Binding request and response). It can also be used with TURN
in each direction between endpoints. These metrics can then be used [RFC5766] by adding this attribute to Allocate requests and responses
by the controlling agent to influence the ICE candidate pair to measure loss and RTT between the client and respective TURN
selection. server.
The PATH-CHARACTERISTICS attribute introduced in this document can be ICE is a mechanism commonly used in VoIP applications to traverse
used in ICE connectivity checks (STUN Binding request and response). NATs, and it uses a static prioritization formula to order the
When multiple TURN servers are discovered then this new attribute can candidate pairs and perform connectivity checks, in which the most
also be used with Allocate request to determine the priority amongst preferred address pairs are tested first and when a sufficiently good
the relayed candidates. pair is discovered, that pair is used for communications and further
connectivity tests are stopped.
The technique described in this document can be used with the regular When multiple paths are available for communication, the endpoint
nomination procedure defined in ICE [RFC5245], wherein ICE sends ICE connectivity checks across each path (candidate pair).
connectivity checks need to be performed on all or subset of the Choosing the path with the lowest round trip time is a reasonable
chosen candidate pairs. Finalizing an appropriate candidate pair approach, but re-transmits can cause an otherwise good path to appear
based on the path characteristics depends on the number of candidate flawed. However, STUN's retransmission algorithm [RFC5389] cannot
pairs, time interval for pacing ICE connectivity checks and the determine the round-trip time (RTT) if a STUN request packet is re-
corresponding RTO values. By picking appropriate values, the transmitted, because each request and retransmission packet is
endpoints will not observe any noticeable impact in the media setup identical. Further, several STUN requests may be sent before the
time. connectivity between candidate pairs are ascertained (see Section 16
of [RFC5245]). To resolve the issue of identical request and
response packets in a STUN transaction, this document changes the
retransmission behavior for idempotent packets. In addition to
determining RTT, it is also possible to get a hint regarding which
path direction caused packet loss. This is achieved by defining a
new STUN attribute and requires compliant STUN (TURN, ICE) endpoints
to count request packets.
The technique described in this document can also be used with the The mechanisms described in this document can be used by the
ICE continuous nomination procedure explained in controlling agent to influence the ICE candidate pair selection. How
[I-D.uberti-mmusic-nombis] which allows the application to pick ICE actually will use this information to improve the active
better candidate pairs as and when they appear. Hence, ICE endpoints candidate pair selection is outside the scope of this document.
will be capable of switching the application data to a candidate pair
that becomes available later and offers better path characteristics.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification uses terminology defined in ICE [RFC5245] and STUN This specification uses terminology defined in ICE [RFC5245] and STUN
[RFC5389]. [RFC5389].
3. Path characteristics determination mechanism 3. Measuring RTT and Fractional Loss
When multiple paths are available for communication, the endpoint
sends ICE connectivity checks across each path (candidate pair) and
perhaps chooses the path with the lowest round trip time. Choosing
the path with the lowest round trip time is a reasonable approach,
but re-transmits can cause an otherwise-good path to appear flawed.
However, STUN's retransmission algorithm [RFC5389] cannot determine
the round-trip time (RTT) if a STUN request packet is re-transmitted,
because each request and retransmission packet is identical.
Further, several STUN requests may be sent before the connectivity
between candidate pairs is ascertained (see Section 16 of [RFC5245]).
To resolve the issue of identical request and response packets in a
STUN transaction, this document changes the retransmission behavior
for idempotent packets. In addition to determining RTT, it is also
desirable to detect which path direction caused packet loss,
described as "bi-directional path characteristics," below. This is
achieved by defining a new STUN attribute and requires compliant STUN
(TURN, ICE) endpoints to count request packets.
This document defines a new comprehension-optional STUN attribute This document defines a new comprehension-optional STUN attribute
PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN Type TBD- TRANSACTION_TRANSMIT_COUNTER with a STUN Type TBD-CA. This type is
CA. This type is in the comprehension-optional range, which means in the comprehension-optional range, which means that STUN agents can
that STUN agents can safely ignore the attribute if they do not safely ignore the attribute. If ICE is in use it will fallback to
understand it. normal procedures.
If a client wishes to determine the path characteristics, it inserts If a client wishes to measure RTT, it inserts the
the PATH-CHARACTERISTIC attribute in a STUN request. In the PATH- TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. In this
CHARACTERISTIC attribute client sends the number of times the STUN attribute the client sends the number of times the STUN request is
request is retransmitted with the same Transaction ID. The server transmitted with the same Transaction ID. The server would echo back
would echo back the retransmission count in the response so that the transmission count in the response so that client can distinguish
client can distinguish STUN responses from the re-transmitted STUN responses from the re-transmitted requests. Hence, the endpoint
requests. Hence, the endpoint can use the STUN requests and can use the STUN requests and responses to determine the round-trip
responses to determine the round-trip time (RTT). The server may time (RTT). The server may also convey the number of responses it
also convey the number of responses it has sent for the STUN request has sent for the STUN request to the client. Further, this
to the client. Further, this information enables the client to information enables the client to get a hint regarding what direction
determine packet loss in each direction. the packet loss occurred. In some cases, it is impossible to
distinguish between packet reordering and packet loss. However if
this information is collected as network metrics from several clients
over a longer time period it will be easier to detect a pattern that
can provide useful information.
3.1. The PATH-CHARACTERISTIC attribute in request 3.1. TRANSACTION_TRANSMIT_COUNTER attribute
The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte The TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a
Value. When sending a STUN request, the PATH-CHARACTERISTIC 32-bit value. This document updates one of the STUN message
attribute allows a client to indicate to the server that it wants to structuring rules explained in Section 6 of [RFC5389] wherein resends
determine path characteristics. This document updates one the STUN of the same request reuse the same transaction ID and are bit-wise
message structuring rules explained in Section 6 of [RFC5389] wherein identical to the previous request. For idempotent packets, the Req
resends of the same request reuse the same transaction ID and are and Resp fields in the TRANSACTION_TRANSMIT_COUNTER attribute will be
bit-wise identical to the previous request. For idempotent packets incremented by 1 by the client or server for every transmission with
the ReTransCnt in the PATH-CHARACTERISTIC attribute will be the same transaction id. Any re-transmitted STUN request MUST be
incremented by 1 for every re-transmission and the re-transmitted bit-wise identical to the previous request except for the values in
STUN request MUST be bit-wise identical to the previous request the TRANSACTION_TRANSMIT_COUNTER attribute.
except for the ReTransCnt value.
The format of the value in PATH-CHARACTERISTIC attribute in the The IANA assigned STUN type for the new attribute is TBD-CA.
request is:
0 1 2 3 The format of the value in TRANSACTION_TRANSMIT_COUNTER attribute in
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 the request is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 | ReTransCnt | RespTransCnt | | Reserved (Padding) | Req | Resp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-CHARACTERISTIC attribute in request Figure 1: TRANSACTION_TRANSMIT_COUNTER attribute in request
The field is described below: The fields is described below:
ReTransCnt: Number of times request is re-transmitted with the same Req: Number of times request is transmitted with the same
transaction ID to the server. transaction ID to the server.
RespTransCnt: RespTransCnt MUST be set to zero in request and Resp: Number of times a response with the same transaction ID is
ignored by the receiver. sent from the server. MUST be set to zero in requests and ignored
by the receiver.
3.2. The PATH-CHARACTERISTIC attribute in response The padding is necessary to hit the 32-bit boundary needed for STUN
attributes. The padding bits are ignored, but to allow for future
reuse of these bits they MUST be set to 0.
When a server receives a STUN request that includes a PATH- 3.2. Usage in Requests
CHARACTERISTIC attribute, it processes the request as per the STUN
protocol [RFC5389] plus the specific rules mentioned here. The
server checks the following:
o If the PATH-CHARACTERISTIC attribute is not recognized, ignore the When sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER
attribute because its type indicates that it is comprehension- Attribute allows a client to indicate to the server that it wants to
optional. This should be the existing behavior as explained in measure RTT and get a hint of the direction of any packet loss.
section 3.1 of [RFC5389].
o The server that supports PATH-CHARACTERISTIC attribute MUST echo The client MUST populate the Req value in the
back ReTransCnt in the response. TRANSACTION_TRANSMIT_COUNTER. This value MUST reflect the number of
requests that have been transmitted to the server. Initial value for
the first request sent is therefore 1. The first re-transmit will
set the value to 2 and so on.
o If the server is stateless or does not want to remember the The Resp filed in the attribute MUST be set to zero in the request.
transaction ID then it would populate value 0 for the RespTransCnt
field in PATH-CHARACTERISTIC attribute sent in the response. If
the server is stateful then it populates RespTransCnt with the
number of responses it has sent for the STUN request.
0 1 2 3 3.3. Usage in Responses
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 | ReTransCnt | RespTransCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-CHARACTERISTIC attribute in response When a server receives a STUN request that includes a
TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as
per the STUN protocol [RFC5389] plus the specific rules mentioned
here. The server checks the following:
The fields are described below: o If the TRANSACTION_TRANSMIT_COUNTER attribute is not recognized,
ignore the attribute because its type indicates that it is
comprehension- optional. This should be the existing behavior as
explained in section 3.1 of [RFC5389].
ReTransCnt: Copied from request. o The server that supports TRANSACTION_TRANSMIT_COUNTER attribute
MUST echo back the Req field in the response using a
TRANSACTION_TRANSMIT_COUNTER attribute.
RespTransCnt: Number of responses sent to the client for the same o If the server is stateless or does not want to remember the
transaction ID. transaction ID then it would populate value 0 for the Resp field
in TRANSACTION_TRANSMIT_COUNTER attribute sent in the response.
If the server is stateful then it populates the Resp field with
the number of responses it has sent for the STUN request.
3.3. Example Operation A client that receives a STUN response with a
TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to
accurately calculate the RTT if retransmits are occurring.
The example operation is described in Figure 3. In the first case, If the server sending the STUN response is stateless the value of the
all the requests and responses are received correctly. In the Resp field will always be 0. If the server keeps state of the
upstream loss case, the first request is lost, but the second one is numbers of STUN request with that same transaction id the value will
received correctly, the client on receiving the response notes that reflect how many packets the server have seen and responded to. This
while 2 requests were sent, only one was received by the server, also gives the client a hint of which direction loss occurred. See
the server realizes that the RespTransCnt does not match the section Section 3.4 for more details.
ReTransCnt, therefore 1 request was lost. This may also occur at
startup in the presence firewalls or NATs that block unsolicited
incoming traffic. In the downstream loss case, the responses get
lost, client expecting multiple response notes that while the server
responded to 3 requests but only 1 response was received. In the
both loss case, requests and responses get lost in tandem, the server
notes one request packet was not received, while the client expecting
3 responses received only one, it notes that one request and response
packets were lost.
Normal | Upstream loss | Downstream loss| Both loss | 3.4. Example Operation
Client Server | Client Server | Client Server | Client Server |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
1 1,1 | 1 x | 1 1,1 | 1 x |
1,1 | | x | |
2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 |
2,2 | 2,1 | x | x |
3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 |
3,3 | 3,2 | 3,3 | 3,2 |
Figure 3: Retransmit Operation between client and Server Example operation, when a server is stateful, is described in
Figure 2. In the first case, all the requests and responses are
received correctly.
Another example could be the client sends two requests but the second In the upstream loss case, the first request is lost, but the second
request arrives at the server before the first request because of out one is received correctly, the client on receiving the response notes
of order delivery. In this case the stateful server populates value that while 2 requests were sent, only one was received by the server.
1 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in The server also realizes that the value in the Req field does not
response to the second request and value 2 for the RespTransCnt field match the number of received requests, therefore 1 request was lost.
in PATH-CHARACTERISTIC attribute sent in response to the first This may also occur at startup in the presence firewalls or NATs that
request. block unsolicited incoming traffic.
4. Usecases In the downstream loss case, the responses get lost, client expecting
multiple responses, notes that while the server responded to 3
requests but only 1 response was received.
The STUN attribute defined in this document can be used by In the both loss case, requests and responses get lost in tandem, the
applications in the following scenarios: server notes one request packet was not received, while the client
expecting 3 responses received only one, it notes that one request
and response packets were lost.
o When an endpoint has multiple interfaces (for example 3G, 4G, | Normal | Upstream loss | Downstream loss | Both loss |
WiFi, VPN, etc.), an ICE agent can choose the interfaces for | Client Server | Client Server | Client Server | Client Server |
application data according to the path characteristics. After |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
STUN responses to STUN checks are received, the ICE agent using | 1 1,1 | 1 x | 1 1,1 | 1 x |
regular nomination can sort the ICE candidate pairs according to | 1,1 | | x | |
the path characteristics (loss and RTT) discovered using STUN. | | 2 2,1 | 2 2,2 | 2 2,1 |
The controlling agent can then assign the highest priority to | | 2,1 | x | x |
candidate pair which best fulfills the desired path | | | 3 3,3 | 3 3,2 |
characteristics. However, it should be noted that the path | | | 3,3 | 3,2 |
capacity or throughput is not determined by these STUN checks. If
an endpoint needs to pick paths based on capacity, it would have
to send application data on those paths.
o When a host has multiple interfaces available an MPRTP Figure 2: Retransmit Operation between client and Server
[I-D.ietf-avtcore-mprtp] application can choose the interfaces for
the corresponding subflows according to the path characteristics
(loss and RTT) discovered using STUN. For example, the scheduling
algorithm described in [ACM-MPRTP] uses path capacity, latency,
and loss rate for choosing the most suitable subset of paths.
o The STUN extension proposed in this document can also be used to Another example could be the client sends two requests but the second
choose a TURN server that provides the best user experience request arrives at the server before the first request because of out
(section 3.1 of [I-D.patil-tram-turn-serv-selection]). of order delivery. In this case, the stateful server populates value
1 for the Resp field in TRANSACTION_TRANSMIT_COUNTER attribute sent
in response to the second request and value 2 for the Resp field in
TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the first
request.
5. IANA Considerations The intention with this mechanism is not to carry out comprehensive
and accurate measurements regarding in what direction loss is
occurring. In some cases, it might not be able to distinguish the
difference between downstream loss and packet reordering.
4. IANA Considerations
[Paragraphs in braces should be removed by the RFC Editor upon [Paragraphs in braces should be removed by the RFC Editor upon
publication] publication]
[The PATH-CHARACTERISTIC attribute requires that IANA allocate a [The TRANSACTION_TRANSMIT_COUNTER attribute requires that IANA
value in the "STUN attributes Registry" from the comprehension- allocate a value in the "STUN attributes Registry" from the
optional range (0x8000-0xFFFF), to be replaced for TBD-CA throughout comprehension-optional range (0x8000-0xBFFF), to be replaced for TBD-
this document] CA throughout this document]
This document defines the PATH-CHARACTERISTIC STUN attribute, This document defines the TRANSACTION_TRANSMIT_COUNTER STUN
described in Section 3. IANA has allocated the comprehension- attribute, described in Section 3. IANA has allocated the
optional codepoint TBD-CA for this attribute. comprehension-optional codepoint TBD-CA for this attribute.
6. Security Considerations 5. Security Considerations
Security considerations discussed in [RFC5389] are to be taken into Security considerations discussed in [RFC5389] are to be taken into
account. STUN requires the 96 bits transaction ID to be uniformly account. STUN requires the 96 bits transaction ID to be uniformly
and randomly chosen from the interval 0 .. 2**96-1, and be and randomly chosen from the interval 0 .. 2**96-1, and be
cryptographically strong. This is good enough security against an cryptographically strong. This is good enough security against an
off-path attacker. An on-path attacker can either inject a fake off-path attacker. An on-path attacker can either inject a fake
response or modify the values in PATH-CHARACTERISTIC attribute to response or modify the values in TRANSACTION_TRANSMIT_COUNTER
mislead the client and server. This attack can be mitigated using attribute to mislead the client and server. This attack can be
STUN authentication. As PATH-CHARACTERISTIC is expected to be used mitigated using STUN authentication. As TRANSACTION_TRANSMIT_COUNTER
between peers using ICE, and ICE uses STUN short-term credential is expected to be used between peers using ICE, and ICE uses STUN
mechanism the risk of on-path attack influencing the messages is short-term credential mechanism the risk of on-path attack
minimal. If PATH-CHARACTERISTIC is used with Allocate request then influencing the messages is minimal. If TRANSACTION_TRANSMIT_COUNTER
STUN long-term credential mechanism or STUN Extension for Third-Party is used with Allocate request then STUN long-term credential
Authorization [RFC7635] or (D)TLS connection can be used between the mechanism or STUN Extension for Third-Party Authorization [RFC7635]
TURN client and the TURN server to prevent attackers from trying to or (D)TLS connection can be used between the TURN client and the TURN
impersonate a TURN server and sending bogus PATH-CHARACTERISTIC server to prevent attackers from trying to impersonate a TURN server
attribute in the Allocate response. However, an attacker could and sending bogus TRANSACTION_TRANSMIT_COUNTER attribute in the
corrupt, remove, or delay an ICE request or response, in order to Allocate response. However, an attacker could corrupt, remove, or
discourage that path from being used. Unauthenticated STUN message delay an ICE request or response, in order to discourage that path
MUST NOT include the PATH-CHARACTERISTIC attribute in order to from being used.
prevent on-path attacker from influencing decision-making.
7. Acknowledgements The information sent in any STUN packet if not encrypted can
potentially be observed passively and used for reconnaissance and
later attacks.
6. Acknowledgements
Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin
Thomson, Oleg Moskalenko, Ram Mohan R and Spencer Dawkins for Thomson, Oleg Moskalenko, Ram Mohan R, Spencer Dawkins, Suresh
valuable inputs and comments. Krishnan, Ben Campbell, Mirja Kuhlewind, Lionel Morand, Kathleen
Moriarty and Alissa Cooper for valuable inputs and comments.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, DOI
DOI 10.17487/RFC5245, April 2010, 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>. <http://www.rfc-editor.org/info/rfc5389>.
8.2. Informative References [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
[ACM-MPRTP] Traversal Utilities for NAT (STUN)", RFC 5766, DOI
Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath 10.17487/RFC5766, April 2010,
considerations for real-time media", in Proc. of ACM <http://www.rfc-editor.org/info/rfc5766>.
Multimedia Systems, MMSys, 2013.
[I-D.ietf-avtcore-mprtp]
Varun, V., Karkkainen, T., Ott, J., Ahsan, S., and L.
Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore-
mprtp-01 (work in progress), July 2015.
[I-D.patil-tram-turn-serv-selection]
Patil, P., Reddy, T., and G. Salgueiro, "Traversal Using
Relays around NAT (TURN) Server Selection", draft-patil-
tram-turn-serv-selection-00 (work in progress), October
2014.
[I-D.uberti-mmusic-nombis] 7.2. Informative References
Uberti, J. and J. Lennox, "Improvements to ICE Candidate
Nomination", draft-uberti-mmusic-nombis-00 (work in
progress), March 2015.
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti,
"Session Traversal Utilities for NAT (STUN) Extension for "Session Traversal Utilities for NAT (STUN) Extension for
Third-Party Authorization", RFC 7635, Third-Party Authorization", RFC 7635, DOI 10.17487/
DOI 10.17487/RFC7635, August 2015, RFC7635, August 2015,
<http://www.rfc-editor.org/info/rfc7635>. <http://www.rfc-editor.org/info/rfc7635>.
Authors' Addresses Authors' Addresses
Paal-Erik Martinsen
Cisco Systems, Inc.
Philip Pedersens vei 22
Lysaker, Akershus 1325
Norway
Email: palmarti@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: tireddy@cisco.com
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Paal-Erik Martinsen
Cisco Systems, Inc.
Philip Pedersens vei 22
Lysaker, Akershus 1325
Norway
Email: palmarti@cisco.com
Varun Singh Varun Singh
Nemu Dialogue System Oy Nemu Dialogue System Oy
Itaemerenkatu 5 Itaemerenkatu 5
Helsinki 00150 Helsinki 00150
Finland Finland
Email: varun@callstats.io Email: varun@callstats.io
 End of changes. 59 change blocks. 
265 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/