draft-ietf-tram-stun-path-data-05.txt   rfc7982.txt 
TRAM P. Martinsen Internet Engineering Task Force (IETF) P. Martinsen
Internet-Draft T. Reddy Request for Comments: 7982 T. Reddy
Intended status: Standards Track D. Wing Category: Standards Track Cisco
Expires: February 24, 2017 Cisco ISSN: 2070-1721 D. Wing
V. Singh V. Singh
callstats.io callstats.io
August 23, 2016 September 2016
Measurement of Round Trip Time and Fractional Loss Using STUN Measurement of Round-Trip Time and Fractional Loss
draft-ietf-tram-stun-path-data-05 Using Session Traversal Utilities for NAT (STUN)
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 measure the This document describes a mechanism for an endpoint to measure the
path characteristics fractional loss and RTT using Session Traversal path characteristics fractional loss and RTT using Session Traversal
Utilities for NAT (STUN) messages. Utilities for NAT (STUN) messages.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 24, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7982.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . 3 3. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . 4
3.1. TRANSACTION_TRANSMIT_COUNTER attribute . . . . . . . . . 4 3.1. TRANSACTION_TRANSMIT_COUNTER Attribute . . . . . . . . . 4
3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 5 3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 5
3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 5 3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 5
3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 6 3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document extends STUN [RFC5389] to make it possible to correlate This document extends STUN [RFC5389] to make it possible to correlate
STUN responses to specific request when re-transmits occur. This STUN responses to specific requests when retransmits occur. This
assists the client in determining path characteristics like round- assists the client in determining path characteristics like round-
trip time (RTT) and fractional packet loss. trip time (RTT) and fractional packet loss.
The TRANSACTION_TRANSMIT_COUNTER attribute introduced in section The TRANSACTION_TRANSMIT_COUNTER attribute introduced in Section 3.1
Section 3.1 can be used in ICE [RFC5245] connectivity checks (STUN can be used in Interactive Connectivity Establishment (ICE) [RFC5245]
Binding request and response). It can also be used with TURN connectivity checks (STUN Binding request and response). It can also
[RFC5766] by adding this attribute to Allocate requests and responses be used with Traversal Using Relays around NAT (TURN) [RFC5766] by
to measure loss and RTT between the client and respective TURN adding this attribute to Allocate requests and responses to measure
server. loss and RTT between the client and the respective TURN server.
ICE is a mechanism commonly used in VoIP applications to traverse ICE is a mechanism commonly used in Voice over IP (VoIP) applications
NATs, and it uses a static prioritization formula to order the to traverse NATs, and it uses a static prioritization formula to
candidate pairs and perform connectivity checks, in which the most order the candidate pairs and perform connectivity checks, in which
preferred address pairs are tested first and when a sufficiently good the most preferred address pairs are tested first, and when a
pair is discovered, that pair is used for communications and further sufficiently good pair is discovered, that pair is used for
connectivity tests are stopped. communications and then further connectivity tests are stopped.
When multiple paths are available for communication, the endpoint When multiple paths are available for communication, the endpoint
sends ICE connectivity checks across each path (candidate pair). sends ICE connectivity checks across each path (candidate pair).
Choosing the path with the lowest round trip time is a reasonable Choosing the path with the lowest round-trip time is a reasonable
approach, but re-transmits can cause an otherwise good path to appear approach, but retransmits can cause an otherwise good path to appear
flawed. However, STUN's retransmission algorithm [RFC5389] cannot flawed. However, STUN's retransmission algorithm [RFC5389] cannot
determine the round-trip time (RTT) if a STUN request packet is re- determine the round-trip time (RTT) if a STUN request packet is
transmitted, because each request and retransmission packet is retransmitted because each request and retransmission packet is
identical. Further, several STUN requests may be sent before the identical. Further, several STUN requests may be sent before the
connectivity between candidate pairs are ascertained (see Section 16 connectivity between candidate pairs are ascertained (see Section 16
of [RFC5245]). To resolve the issue of identical request and of [RFC5245]). To resolve the issue of identical request and
response packets in a STUN transaction, this document changes the response packets in a STUN transaction, this document changes the
retransmission behavior for idempotent packets. In addition to retransmission behavior for idempotent packets. Using the mechanism
determining RTT, it is also possible to get a hint regarding which described herein, a client can determine RTT as well as get a hint
path direction caused packet loss. This is achieved by defining a regarding which path direction caused packet loss. This is achieved
new STUN attribute and requires compliant STUN (TURN, ICE) endpoints by defining a new STUN attribute and requires compliant STUN (TURN
to count request packets. and ICE) endpoints to count request packets.
The mechanisms described in this document can be used by the The mechanisms described in this document can be used by the
controlling agent to influence the ICE candidate pair selection. How controlling agent to influence the ICE candidate pair selection. How
ICE actually will use this information to improve the active ICE will actually use this information to improve the active
candidate pair selection is outside the scope of this document. candidate pair selection is outside the scope of this document.
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. Measuring RTT and Fractional Loss 3. Measuring RTT and Fractional Loss
This document defines a new comprehension-optional STUN attribute This document defines a new comprehension-optional STUN attribute
TRANSACTION_TRANSMIT_COUNTER with a STUN Type TBD-CA. This type is TRANSACTION_TRANSMIT_COUNTER with a STUN Type 0x8025. This type is
in the comprehension-optional range, which means that STUN agents can in the comprehension-optional range, which means that STUN agents can
safely ignore the attribute. If ICE is in use it will fallback to safely ignore the attribute. If ICE is in use, it will fall back to
normal procedures. normal procedures.
If a client wishes to measure RTT, it inserts the If a client wishes to measure RTT, it inserts the
TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. In this TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. In this
attribute the client sends the number of times the STUN request is attribute, the client sends the number of times the STUN request is
transmitted with the same Transaction ID. The server would echo back transmitted with the same transaction ID. The server would echo back
the transmission count in the response so that client can distinguish the transmission count in the response so that the client can
between STUN responses coming from re-transmitted requests. Hence, distinguish between STUN responses coming from retransmitted
the endpoint can use the STUN requests and responses to determine the requests. Hence, the endpoint can use the STUN requests and
round-trip time (RTT). The server may also convey the number of responses to determine the round-trip time (RTT). The server may
responses it has sent for the STUN request to the client. Further, also convey the number of responses it has sent for the STUN request
this information enables the client to get a hint regarding what to the client. Further, this information enables the client to get a
direction the packet loss occurred. In some cases, it is impossible hint regarding in which direction the packet loss occurred. In some
to distinguish between packet reordering and packet loss. However if cases, it is impossible to distinguish between packet reordering and
this information is collected as network metrics from several clients packet loss. However, if this information is collected as network
over a longer time period, it will be easier to detect a pattern that metrics from several clients over a longer time period, it will be
can provide useful information. easier to detect a pattern that can provide useful information.
3.1. TRANSACTION_TRANSMIT_COUNTER attribute 3.1. TRANSACTION_TRANSMIT_COUNTER Attribute
The TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a The TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a
32-bit value. This document updates one of the STUN message 32-bit value. This document updates one of the STUN message
structuring rules explained in Section 6 of [RFC5389] wherein structuring rules explained in Section 6 of [RFC5389] wherein
retransmit of the same request reuse the same transaction ID and are retransmission of the same request reuses the same transaction ID and
bit-wise identical to the previous request. For idempotent packets, is bit-wise identical to the previous request. For idempotent
the Req and Resp fields in the TRANSACTION_TRANSMIT_COUNTER attribute packets, the Req and Resp fields in the TRANSACTION_TRANSMIT_COUNTER
will be incremented by 1 by the client or server for every attribute will be incremented by 1 by the client or server for every
transmission with the same transaction id. Any re-transmitted STUN transmission with the same transaction ID. Any retransmitted STUN
request MUST be bit-wise identical to the previous request except for request MUST be bit-wise identical to the previous request except for
the values in the TRANSACTION_TRANSMIT_COUNTER attribute. the values in the TRANSACTION_TRANSMIT_COUNTER attribute.
The IANA assigned STUN type for the new attribute is TBD-CA. The IANA-assigned STUN type for the new attribute is 0x8025.
The format of the value in TRANSACTION_TRANSMIT_COUNTER attribute in The format of the value in the TRANSACTION_TRANSMIT_COUNTER attribute
the request is: in the request is:
0 1 2 3 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 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 (Padding) | Req | Resp | | Reserved (Padding) | Req | Resp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TRANSACTION_TRANSMIT_COUNTER attribute in request Figure 1: TRANSACTION_TRANSMIT_COUNTER Attribute in Request
The fields is described below: The fields are described below:
Req: Number of times request is transmitted with the same Req: Number of times the request is transmitted with the same
transaction ID to the server. transaction ID to the server.
Resp: Number of times a response with the same transaction ID is Resp: Number of times a response with the same transaction ID is
sent from the server. MUST be set to zero in requests and ignored sent from the server. MUST be set to zero in requests and ignored
by the receiver. by the receiver.
The padding is necessary to hit the 32-bit boundary needed for STUN The padding is necessary to hit the 32-bit boundary needed for STUN
attributes. The padding bits are ignored, but to allow for future attributes. The padding bits are ignored, but to allow for future
reuse of these bits they MUST be set to 0. reuse of these bits, they MUST be set to zero.
3.2. Usage in Requests 3.2. Usage in Requests
When sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER When sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER
Attribute allows a client to indicate to the server that it wants to Attribute allows a client to indicate to the server that it wants to
measure RTT and get a hint of the direction of any packet loss. measure RTT and get a hint about the direction of any packet loss.
The client MUST populate the Req value in the The client MUST populate the Req value in the
TRANSACTION_TRANSMIT_COUNTER. This value MUST reflect the number of TRANSACTION_TRANSMIT_COUNTER. This value MUST reflect the number of
requests that have been transmitted to the server. Initial value for requests that have been transmitted to the server. Therefore, the
the first request sent is therefore 1. The first re-transmit will initial value for the first request sent is 1. The first retransmit
set the value to 2 and so on. will set the value to 2 and so on.
The Resp filed in the attribute MUST be set to zero in the request. The Resp field in the attribute MUST be set to zero in the request.
3.3. Usage in Responses 3.3. Usage in Responses
When a server receives a STUN request that includes a When a server receives a STUN request that includes a
TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as
per the STUN protocol [RFC5389] plus the specific rules mentioned per the STUN protocol [RFC5389] plus the specific rules mentioned
here. The server checks the following: here. The server checks the following:
o If the TRANSACTION_TRANSMIT_COUNTER attribute is not recognized, o If the TRANSACTION_TRANSMIT_COUNTER attribute is not recognized,
ignore the attribute because its type indicates that it is ignore the attribute because its type indicates that it is
comprehension- optional. This should be the existing behavior as comprehension-optional. This should be the existing behavior as
explained in section 3.1 of [RFC5389]. explained in Section 7.3 of [RFC5389].
o The server that supports TRANSACTION_TRANSMIT_COUNTER attribute o The server that supports the TRANSACTION_TRANSMIT_COUNTER
MUST echo back the Req field in the response using a attribute MUST echo back the Req field in the response using a
TRANSACTION_TRANSMIT_COUNTER attribute. TRANSACTION_TRANSMIT_COUNTER attribute.
o If the server is stateless or does not want to remember the o If the server is stateless or does not want to remember the
transaction ID then it would populate value 0 for the Resp field transaction ID, then it populates value 0 for the Resp field in
in TRANSACTION_TRANSMIT_COUNTER attribute sent in the response. the TRANSACTION_TRANSMIT_COUNTER attribute sent in the response.
If the server is stateful then it populates the Resp field with If the server is stateful, then it populates the Resp field with
the number of responses it has sent for the STUN request. the number of responses it has sent for the STUN request.
A client that receives a STUN response with a A client that receives a STUN response with a
TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to
accurately calculate the RTT if retransmits are occurring. accurately calculate the RTT if retransmits are occurring.
If the server sending the STUN response is stateless the value of the If the server sending the STUN response is stateless, the value of
Resp field will always be 0. If the server keeps state of the the Resp field will always be 0. If the server keeps state of the
numbers of STUN request with that same transaction id the value will numbers of STUN requests with that same transaction ID, the value
reflect how many packets the server have seen and responded to. This will reflect how many packets the server has seen and responded to.
gives the client a hint of which direction loss occurred. See This gives the client a hint about in which direction loss occurred.
section Section 3.4 for more details. See Section 3.4 for more details.
3.4. Example Operation 3.4. Example Operation
Example operation, when a server is stateful, is described in An example operation, when a server is stateful, is described in
Figure 2. In the first case, all the requests and responses are Figure 2. In the first case, all the requests and responses are
received correctly. received correctly.
In the upstream loss case, the first request is lost, but the second In the case of upstream loss, the first request is lost, but the
one is received correctly, the client on receiving the response notes second one is received correctly. The client, upon receiving the
that while 2 requests were sent, only one was received by the server. response, notes that while two requests were sent, only one was
The server also realizes that the value in the Req field does not received by the server. The server also realizes that the value in
match the number of received requests, therefore 1 request was lost. the Req field does not match the number of received requests,
This may also occur at startup in the presence firewalls or NATs that therefore one request was lost. This may also occur at startup in
block unsolicited incoming traffic. the presence of firewalls or NATs that block unsolicited incoming
traffic.
In the downstream loss case, the responses get lost, client expecting In the case of downstream loss, the responses get lost, the client
multiple responses, notes that while the server responded to 3 expecting multiple responses notes that, while the server responded
requests but only 1 response was received. to three requests, only one response was received.
In the both loss case, requests and responses get lost in tandem, the In the case of loss in both directions, requests and responses get
server notes one request packet was not received, while the client lost in tandem, the server notes that one request packet was not
expecting 3 responses received only one, it notes that one request received, while the client expecting three responses received only
and response packets were lost. one, and then it notes that one request and response packet were
lost.
| Normal | Upstream loss | Downstream loss | Both loss | | Normal | Upstream loss | Downstream loss | Both upstream &|
| Client Server | Client Server | Client Server | Client Server | | | | | downstream loss|
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Client Server | Client Server | Client Server | Client Server |
| 1 1,1 | 1 x | 1 1,1 | 1 x | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| 1,1 | | x | | | 1 1,1 | 1 x | 1 1,1 | 1 x |
| | 2 2,1 | 2 2,2 | 2 2,1 | | 1,1 | | x | |
| | 2,1 | x | x | | | 2 2,1 | 2 2,2 | 2 2,1 |
| | | 3 3,3 | 3 3,2 | | | 2,1 | x | x |
| | | 3,3 | 3,2 | | | | 3 3,3 | 3 3,2 |
| | | 3,3 | 3,2 |
Figure 2: Retransmit Operation between client and Server Figure 2: Retransmit Operation between Client and Server
Another example could be the client sends two requests but the second Another example is when the client sends two requests but the second
request arrives at the server before the first request because of out request arrives at the server before the first request because of
of order delivery. In this case, the stateful server populates value out-of-order delivery. In this case, the stateful server populates
1 for the Resp field in TRANSACTION_TRANSMIT_COUNTER attribute sent value 1 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER
in response to the second request and value 2 for the Resp field in attribute sent in response to the second request and value 2 for the
TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the first Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in
request. response to the first request.
The intention with this mechanism is not to carry out comprehensive The intention with this mechanism is not to carry out comprehensive
and accurate measurements regarding in what direction loss is and accurate measurements regarding in what direction loss is
occurring. In some cases, it might not be able to distinguish the occurring. In some cases, it might not be able to distinguish the
difference between downstream loss and packet reordering. difference between downstream loss and packet reordering.
4. IANA Considerations 4. IANA Considerations
[Paragraphs in braces should be removed by the RFC Editor upon
publication]
[The TRANSACTION_TRANSMIT_COUNTER attribute requires that IANA
allocate a value in the "STUN attributes Registry" from the
comprehension-optional range (0x8000-0xBFFF), to be replaced for TBD-
CA throughout this document]
This document defines the TRANSACTION_TRANSMIT_COUNTER STUN This document defines the TRANSACTION_TRANSMIT_COUNTER STUN
attribute, described in Section 3. IANA has allocated the attribute, described in Section 3. IANA has allocated the
comprehension-optional codepoint TBD-CA for this attribute. comprehension-optional codepoint 0x8025 for this attribute.
5. 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 that the 96-bit transaction ID 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 TRANSACTION_TRANSMIT_COUNTER response or modify the values in the TRANSACTION_TRANSMIT_COUNTER
attribute to mislead the client and server. This attack can be attribute to mislead the client and server. This attack can be
mitigated using STUN authentication. As TRANSACTION_TRANSMIT_COUNTER mitigated using STUN authentication. As the
is expected to be used between peers using ICE, and ICE uses STUN TRANSACTION_TRANSMIT_COUNTER is expected to be used between peers
short-term credential mechanism the risk of on-path attack using ICE, and ICE uses a STUN short-term credential mechanism, the
influencing the messages is minimal. If TRANSACTION_TRANSMIT_COUNTER risk of an on-path attack influencing the messages is minimal. If
is used with Allocate request then STUN long-term credential the TRANSACTION_TRANSMIT_COUNTER is used with an Allocate request,
mechanism or STUN Extension for Third-Party Authorization [RFC7635] one of the following mechanisms can be used to prevent attackers from
or (D)TLS connection can be used between the TURN client and the TURN trying to impersonate a TURN server and sending a bogus
server to prevent attackers from trying to impersonate a TURN server TRANSACTION_TRANSMIT_COUNTER attribute in the Allocate response:
and sending bogus TRANSACTION_TRANSMIT_COUNTER attribute in the 1) the STUN long-term credential mechanism, 2) the STUN Extension for
Allocate response. However, an attacker could corrupt, remove, or Third-Party Authorization [RFC7635], or 3) a TLS or DTLS connection
delay an ICE request or response, in order to discourage that path between the TURN client and the TURN server. However, an attacker
from being used. could corrupt, remove, or delay an ICE request or response, in order
to discourage that path from being used.
The information sent in any STUN packet if not encrypted can If not encrypted, the information sent in any STUN packet can
potentially be observed passively and used for reconnaissance and potentially be observed passively and used for reconnaissance and
later attacks. later attacks.
6. Acknowledgements 6. References
Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin
Thomson, Oleg Moskalenko, Ram Mohan R, Spencer Dawkins, Suresh
Krishnan, Ben Campbell, Mirja Kuhlewind, Lionel Morand, Kathleen
Moriarty and Alissa Cooper for valuable inputs and comments.
7. References
7.1. Normative References 6.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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/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, DOI Traversal for Offer/Answer Protocols", RFC 5245,
10.17487/RFC5245, April 2010, DOI 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>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, DOI Traversal Utilities for NAT (STUN)", RFC 5766,
10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>. <http://www.rfc-editor.org/info/rfc5766>.
7.2. Informative References 6.2. Informative References
[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, DOI 10.17487/ Third-Party Authorization", RFC 7635,
RFC7635, August 2015, DOI 10.17487/RFC7635, August 2015,
<http://www.rfc-editor.org/info/rfc7635>. <http://www.rfc-editor.org/info/rfc7635>.
Acknowledgements
Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin
Thomson, Oleg Moskalenko, Ram Mohan Ravindranath, Spencer Dawkins,
Suresh Krishnan, Ben Campbell, Mirja Kuehlewind, Lionel Morand,
Kathleen Moriarty, and Alissa Cooper for their valuable input and
comments.
Authors' Addresses Authors' Addresses
Paal-Erik Martinsen Paal-Erik Martinsen
Cisco Systems, Inc. Cisco Systems, Inc.
Philip Pedersens vei 22 Philip Pedersens vei 22
Lysaker, Akershus 1325 Lysaker, Akershus 1325
Norway Norway
Email: palmarti@cisco.com 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
skipping to change at page 9, line 14 skipping to change at page 10, line 25
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.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com Email: dwing-ietf@fuggles.com
Varun Singh Varun Singh
CALLSTATS I/O Oy CALLSTATS I/O Oy
Runeberginkatu 4c A 4 Runeberginkatu 4c A 4
Helsinki 00100 Helsinki 00100
Finland Finland
Email: varun@callstats.io Email: varun@callstats.io
URI: https://www.callstats.io/about URI: https://www.callstats.io/about
 End of changes. 57 change blocks. 
176 lines changed or deleted 168 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/