draft-ietf-tram-stun-path-data-02.txt   draft-ietf-tram-stun-path-data-03.txt 
TRAM T. Reddy TRAM T. Reddy
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Standards Track P. Martinsen Intended status: Standards Track P. Martinsen
Expires: April 7, 2016 Cisco Expires: July 30, 2016 Cisco
V. Singh V. Singh
callstats.io callstats.io
October 5, 2015 January 27, 2016
Discovery of path characteristics using STUN Discovery of path characteristics using STUN
draft-ietf-tram-stun-path-data-02 draft-ietf-tram-stun-path-data-03
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 discover the
path characteristics using Session Traversal Utilities for NAT (STUN) path characteristics using Session Traversal Utilities for NAT (STUN)
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 7, 2016. This Internet-Draft will expire on July 30, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 41 skipping to change at page 2, line 41
1. Introduction 1. Introduction
The ICE [RFC5245] mechanism uses a prioritization formula to order The ICE [RFC5245] mechanism uses a prioritization formula to order
the candidate pairs and perform connectivity checks, in which the the candidate pairs and perform connectivity checks, in which the
most preferred address pairs are tested first and when a sufficiently most preferred address pairs are tested first and when a sufficiently
good pair is discovered, that pair is used for communications and good pair is discovered, that pair is used for communications and
further connectivity tests are stopped. This approach works well for further connectivity tests are stopped. This approach works well for
an endpoint with a single interface, but is too simplistic for an endpoint with a single interface, but is too simplistic for
endpoints with multiple interfaces, wherein a candidate pair with a endpoints with multiple interfaces, wherein a candidate pair with a
lower priority might infact have better path characteristics (e.g., lower priority might in fact have better path characteristics (e.g.,
round-trip time, loss, etc.). The ICE connectivity checks can assist round-trip time, loss, etc.). The ICE connectivity checks can assist
in measuring the path characteristics, but as currently defined, the in measuring the path characteristics, but as currently defined, the
STUN responses to re-transmitted requests are indistinguishable from STUN responses to re-transmitted requests are indistinguishable from
each other. each other.
This draft extends STUN [RFC5389] to distinguish STUN responses to This draft extends STUN [RFC5389] to distinguish STUN responses to
re-transmitted requests and this assists the client in determining re-transmitted requests and this assists the client in determining
the path characteristics like round-trip time (RTT) and packet loss the path characteristics like round-trip time (RTT) and packet loss
in each direction between endpoints. These metrics can then be used in each direction between endpoints. These metrics can then be used
by the controlling agent to influence the ICE candidate pair by the controlling agent to influence the ICE candidate pair
skipping to change at page 3, line 34 skipping to change at page 3, line 34
better candidate pairs as and when they appear. Hence, ICE endpoints better candidate pairs as and when they appear. Hence, ICE endpoints
will be capable of switching the application data to a candidate pair will be capable of switching the application data to a candidate pair
that becomes available later and offers better path characteristics. 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 note 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. Path characteristics determination mechanism
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) and sends ICE connectivity checks across each path (candidate pair) and
perhaps chooses the path with the lowest round trip time. Choosing perhaps chooses the path with the lowest round trip time. Choosing
the path with the lowest round trip time is a reasonable approach, the path with the lowest round trip time is a reasonable approach,
but re-transmits can cause an otherwise-good path to appear flawed. but re-transmits can cause an otherwise-good path to appear flawed.
However, STUN's retransmission algorithm [RFC5389] cannot determine However, STUN's retransmission algorithm [RFC5389] cannot determine
skipping to change at page 4, line 31 skipping to change at page 4, line 31
responses to determine the round-trip time (RTT). The server may responses to determine the round-trip time (RTT). The server may
also convey the number of responses it has sent for the STUN request also convey the number of responses it has sent for the STUN request
to the client. Further, this information enables the client to to the client. Further, this information enables the client to
determine packet loss in each direction. determine packet loss in each direction.
3.1. The PATH-CHARACTERISTIC attribute in request 3.1. The PATH-CHARACTERISTIC attribute in request
The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte
Value. When sending a STUN request, the PATH-CHARACTERISTIC Value. When sending a STUN request, the PATH-CHARACTERISTIC
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
determine path characteristics. If the client receives a STUN determine path characteristics. This document updates one the STUN
response with error code 420 (Unknown Attribute) and PATH- message structuring rules explained in Section 6 of [RFC5389] wherein
CHARACTERISTIC is listed in the UNKNOWN-ATTRIBUTE attribute of the resends of the same request reuse the same transaction ID and are
message, the client SHOULD retransmit the original request without bit-wise identical to the previous request. For idempotent packets
the PATH-CHARACTERISTIC attribute. However this case is not expected the ReTransCnt in the PATH-CHARACTERISTIC attribute will be
to occur, due to the use of the comprehension-optional attribute incremented by 1 for every re-transmission and the re-transmitted
type. STUN request MUST be bit-wise identical to the previous request
except for the ReTransCnt value.
This document updates one the STUN message structuring rules
explained in Section 6 of [RFC5389] wherein resends of the same
request reuse the same transaction ID and are bit-wise identical to
the previous request. For idempotent packets the ReTransCnt in the
PATH-CHARACTERISTIC attribute will be incremented by 1 for every re-
transmission and the re-transmitted STUN request MUST be bit-wise
identical to the previous request except for the ReTransCnt value.
The format of the value in PATH-CHARACTERISTIC attribute in the The format of the value in PATH-CHARACTERISTIC attribute in the
request is: 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, should be 0 | ReTransCnt | RespTransCnt | | Reserved, should be 0 | ReTransCnt | RespTransCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 21 skipping to change at page 7, line 15
The controlling agent can then assign the highest priority to The controlling agent can then assign the highest priority to
candidate pair which best fulfills the desired path candidate pair which best fulfills the desired path
characteristics. However, it should be noted that the path characteristics. However, it should be noted that the path
capacity or throughput is not determined by these STUN checks. If capacity or throughput is not determined by these STUN checks. If
an endpoint needs to pick paths based on capacity, it would have an endpoint needs to pick paths based on capacity, it would have
to send application data on those paths. to send application data on those paths.
o When a host has multiple interfaces available an MPRTP o When a host has multiple interfaces available an MPRTP
[I-D.ietf-avtcore-mprtp] application can choose the interfaces for [I-D.ietf-avtcore-mprtp] application can choose the interfaces for
the corresponding subflows according to the path characteristics the corresponding subflows according to the path characteristics
discovered using STUN. For example, the scheduling algorithm (loss and RTT) discovered using STUN. For example, the scheduling
described in [ACM-MPRTP] uses path capacity, latency, and loss algorithm described in [ACM-MPRTP] uses path capacity, latency,
rate for choosing the most suitable subset of paths. and loss rate for choosing the most suitable subset of paths.
o The STUN extension proposed in this document can also be used to o The STUN extension proposed in this document can also be used to
choose a TURN server that provides the best user experience choose a TURN server that provides the best user experience
(section 3.1 of [I-D.patil-tram-turn-serv-selection]). (section 3.1 of [I-D.patil-tram-turn-serv-selection]).
5. IANA Considerations 5. 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]
skipping to change at page 7, line 51 skipping to change at page 7, line 45
optional codepoint TBD-CA for this attribute. optional codepoint TBD-CA for this attribute.
6. Security Considerations 6. 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 PATH-CHARACTERISTIC attribute to
mislead the client and server, this attack can be mitigated using mislead the client and server. This attack can be mitigated using
STUN authentication. As PATH-CHARACTERISTIC is expected to be used STUN authentication. As PATH-CHARACTERISTIC is expected to be used
between peers using ICE, and ICE uses STUN short-term credential between peers using ICE, and ICE uses STUN short-term credential
mechanism the risk of on-path attack influencing the messages is mechanism the risk of on-path attack influencing the messages is
minimal. If PATH-CHARACTERISTIC is used with Allocate request then minimal. If PATH-CHARACTERISTIC is used with Allocate request then
STUN long-term credential mechanism or STUN Extension for Third-Party STUN long-term credential mechanism or STUN Extension for Third-Party
Authorization [RFC7635] or (D)TLS connection can be used between the Authorization [RFC7635] or (D)TLS connection can be used between the
TURN client and the TURN server to prevent attackers from trying to TURN client and the TURN server to prevent attackers from trying to
impersonate a TURN server and sending bogus PATH-CHARACTERISTIC impersonate a TURN server and sending bogus PATH-CHARACTERISTIC
attribute in the Allocate response. However, an attacker could attribute in the Allocate response. However, an attacker could
corrupt, remove, or delay an ICE request or response, in order to corrupt, remove, or delay an ICE request or response, in order to
discourage that path from being used. Unauthenticated STUN message discourage that path from being used. Unauthenticated STUN message
MUST NOT include the PATH-CHARACTERISTIC attribute in order to MUST NOT include the PATH-CHARACTERISTIC attribute in order to
prevent on-path attacker from influencing decision-making. prevent on-path attacker from influencing decision-making.
7. Acknowledgements 7. Acknowledgements
Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin
Thomson, Oleg Moskalenko and Ram Mohan R for valuable inputs and Thomson, Oleg Moskalenko, Ram Mohan R and Spencer Dawkins for
comments. valuable inputs and comments.
8. References 8. References
8.1. Normative References 8.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/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 11 change blocks. 
28 lines changed or deleted 21 lines changed or added

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