draft-ietf-tram-stun-path-data-01.txt   draft-ietf-tram-stun-path-data-02.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: October 9, 2015 Cisco Expires: April 7, 2016 Cisco
V. Singh V. Singh
callstats.io callstats.io
April 7, 2015 October 5, 2015
Discovery of path characteristics using STUN Discovery of path characteristics using STUN
draft-ietf-tram-stun-path-data-01 draft-ietf-tram-stun-path-data-02
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 October 9, 2015. This Internet-Draft will expire on April 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
based on the path characteristics depends on the number of candidate based on the path characteristics depends on the number of candidate
pairs, time interval for pacing ICE connectivity checks and the pairs, time interval for pacing ICE connectivity checks and the
corresponding RTO values. By picking appropriate values, the corresponding RTO values. By picking appropriate values, the
endpoints will not observe any noticeable impact in the media setup endpoints will not observe any noticeable impact in the media setup
time. time.
The technique described in this document can also be used with the The technique described in this document can also be used with the
ICE continuous nomination procedure explained in ICE continuous nomination procedure explained in
[I-D.uberti-mmusic-nombis] which allows the application to pick [I-D.uberti-mmusic-nombis] which allows the application to pick
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 media stream 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 note uses terminology defined in ICE [RFC5245] and STUN
[RFC5389]. [RFC5389].
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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
the round-trip time (RTT) if a STUN request packet is re-transmitted, the round-trip time (RTT) if a STUN request packet is re-transmitted,
because each request and retransmission packet is identical. because each request and retransmission packet is identical.
Further, several STUN requests may be sent before the connectivity Further, several STUN requests may be sent before the connectivity
between candidate pairs is ascertained (see Section 16 of [RFC5245]). between candidate pairs is ascertained (see Section 16 of [RFC5245]).
To resolve the issue of identical request and response packets in a To resolve the issue of identical request and response packets in a
STUN transaction, this document changes that retransmission behavior STUN transaction, this document changes the retransmission behavior
for idempotent packets. In addition to determining RTT, it is also for idempotent packets. In addition to determining RTT, it is also
desirable to detect which path direction caused packet loss, desirable to detect which path direction caused packet loss,
described as "bi-directional path characteristics," below. This is described as "bi-directional path characteristics," below. This is
achieved by defining a new STUN attribute and requires compliant STUN achieved by defining a new STUN attribute and requires compliant STUN
(TURN, ICE) endpoints to count request packets. (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- PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN Type TBD-
CA. This type is in the comprehension-optional range, which means CA. This type is in the comprehension-optional range, which means
that STUN agents can safely ignore the attribute if they do not that STUN agents can safely ignore the attribute if they do not
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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. If the client receives a STUN
response with error code 420 (Unknown Attribute) and PATH- response with error code 420 (Unknown Attribute) and PATH-
CHARACTERISTIC is listed in the UNKNOWN-ATTRIBUTE attribute of the CHARACTERISTIC is listed in the UNKNOWN-ATTRIBUTE attribute of the
message, the client SHOULD retransmit the original request without message, the client SHOULD retransmit the original request without
the PATH-CHARACTERISTIC attribute. However this case is not expected the PATH-CHARACTERISTIC attribute. However this case is not expected
to occur, due to the use of the comprehension-optional attribute to occur, due to the use of the comprehension-optional attribute
type. type.
This document updates one the STUN message structuring rules This document updates one the STUN message structuring rules
explained in Section 6 of [RFC5389] that resends of the same request explained in Section 6 of [RFC5389] wherein resends of the same
reuse the same transaction ID and are bit-wise identical to the request reuse the same transaction ID and are bit-wise identical to
previous request. For idempotent packets the ReTransCnt in the PATH- the previous request. For idempotent packets the ReTransCnt in the
CHARACTERISTIC attribute will be incremented by 1 for every re- PATH-CHARACTERISTIC attribute will be incremented by 1 for every re-
transmission and the re-transmitted STUN request MUST be bit-wise transmission and the re-transmitted STUN request MUST be bit-wise
identical to the previous request except for the ReTransCnt value. 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 6, line 12 skipping to change at page 6, line 12
The fields are described below: The fields are described below:
ReTransCnt: Copied from request. ReTransCnt: Copied from request.
RespTransCnt: Number of responses sent to the client for the same RespTransCnt: Number of responses sent to the client for the same
transaction ID. transaction ID.
3.3. Example Operation 3.3. Example Operation
The operation is described in Figure 3. In the first case, all the The example operation is described in Figure 3. In the first case,
requests and responses are received correctly. In the upstream loss all the requests and responses are received correctly. In the
case, the first request is lost, but the second one is received upstream loss case, the first request is lost, but the second one is
correctly, the client on receiving the response notes that while 2 received correctly, the client on receiving the response notes that
requests were sent, only one was received by the server, also the while 2 requests were sent, only one was received by the server, also
server realizes that the RespTransCnt does not match the ReTransCnt, the server realizes that the RespTransCnt does not match the
therefore 1 request was lost. This may also occur at startup in the ReTransCnt, therefore 1 request was lost. This may also occur at
presence firewalls or NATs that block unsolicited incoming traffic. startup in the presence firewalls or NATs that block unsolicited
In the downstream loss case, the responses get lost, client expecting incoming traffic. In the downstream loss case, the responses get
multiple response notes that while the server responded to 3 requests lost, client expecting multiple response notes that while the server
but only 1 response was received. In the both loss case, requests responded to 3 requests but only 1 response was received. In the
and responses get lost in tandem, the server notes one request packet both loss case, requests and responses get lost in tandem, the server
was not received, while the client expecting 3 responses received notes one request packet was not received, while the client expecting
only one, it notes that one request and response packets were lost. 3 responses received only one, it notes that one request and response
packets were lost.
Normal | Upstream loss | Downstream loss| Both loss | Normal | Upstream loss | Downstream loss| Both loss |
Client Server | Client Server | Client Server | Client Server | Client Server | Client Server | Client Server | Client Server |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
1 1,1 | 1 x | 1 1,1 | 1 x | 1 1,1 | 1 x | 1 1,1 | 1 x |
1,1 | | x | | 1,1 | | x | |
2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 |
2,2 | 2,1 | x | x | 2,2 | 2,1 | x | x |
3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 |
3,3 | 3,2 | 3,3 | 3,2 | 3,3 | 3,2 | 3,3 | 3,2 |
Figure 3: Retransmit Operation between client and Server Figure 3: Retransmit Operation between client and Server
Another example could be the client sends two requests but the second
request arrives at the server before the first request because of out
of order delivery. In this case the stateful server populates value
1 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in
response to the second request and value 2 for the RespTransCnt field
in PATH-CHARACTERISTIC attribute sent in response to the first
request.
4. Usecases 4. Usecases
The STUN attribute defined in this document can be used by The STUN attribute defined in this document can be used by
applications in the following scenarios: applications in the following scenarios:
o When an endpoint has multiple interfaces (for example 3G, 4G, o When an endpoint has multiple interfaces (for example 3G, 4G,
WiFi, VPN, etc.), an ICE agent can choose the interfaces for media WiFi, VPN, etc.), an ICE agent can choose the interfaces for
streams according to the path characteristics. After STUN application data according to the path characteristics. After
responses to STUN checks are received, the ICE agent using regular STUN responses to STUN checks are received, the ICE agent using
nomination can sort the ICE candidate pairs according to the path regular nomination can sort the ICE candidate pairs according to
characteristics (loss and RTT) discovered using STUN. The the path characteristics (loss and RTT) discovered using STUN.
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 media 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 discovered using STUN. For example, the scheduling algorithm
described in [ACM-MPRTP] uses path capacity, latency, and loss described in [ACM-MPRTP] uses path capacity, latency, and loss
rate for choosing the most suitable subset of paths. 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
skipping to change at page 7, line 45 skipping to change at page 8, line 6
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. However, an attacker could corrupt, remove, or delay an ICE minimal. If PATH-CHARACTERISTIC is used with Allocate request then
request or response, in order to discourage that path from being STUN long-term credential mechanism or STUN Extension for Third-Party
used. Unauthenticated STUN message MUST NOT include the PATH- Authorization [RFC7635] or (D)TLS connection can be used between the
CHARACTERISTIC attribute in order to prevent on-path attacker from TURN client and the TURN server to prevent attackers from trying to
influencing decision-making. impersonate a TURN server and sending bogus PATH-CHARACTERISTIC
attribute in the Allocate response. However, an attacker could
corrupt, remove, or delay an ICE request or response, in order to
discourage that path from being used. Unauthenticated STUN message
MUST NOT include the PATH-CHARACTERISTIC attribute in order to
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 and Oleg Moskalenko for valuable inputs and comments. Thomson, Oleg Moskalenko and Ram Mohan R for 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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<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,
October 2008. DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
8.2. Informative References 8.2. Informative References
[ACM-MPRTP] [ACM-MPRTP]
Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath
considerations for real-time media", in Proc. of ACM considerations for real-time media", in Proc. of ACM
Multimedia Systems, MMSys, 2013. Multimedia Systems, MMSys, 2013.
[I-D.ietf-avtcore-mprtp] [I-D.ietf-avtcore-mprtp]
Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. Varun, V., Karkkainen, T., Ott, J., Ahsan, S., and L.
Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore- Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore-
mprtp-00 (work in progress), December 2014. mprtp-01 (work in progress), July 2015.
[I-D.patil-tram-turn-serv-selection] [I-D.patil-tram-turn-serv-selection]
Patil, P., Reddy, T., and G. Salgueiro, "Traversal Using Patil, P., Reddy, T., and G. Salgueiro, "Traversal Using
Relays around NAT (TURN) Server Selection", draft-patil- Relays around NAT (TURN) Server Selection", draft-patil-
tram-turn-serv-selection-00 (work in progress), October tram-turn-serv-selection-00 (work in progress), October
2014. 2014.
[I-D.uberti-mmusic-nombis] [I-D.uberti-mmusic-nombis]
Uberti, J. and J. Lennox, "Improvements to ICE Candidate Uberti, J. and J. Lennox, "Improvements to ICE Candidate
Nomination", draft-uberti-mmusic-nombis-00 (work in Nomination", draft-uberti-mmusic-nombis-00 (work in
progress), March 2015. progress), March 2015.
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti,
"Session Traversal Utilities for NAT (STUN) Extension for
Third-Party Authorization", RFC 7635,
DOI 10.17487/RFC7635, August 2015,
<http://www.rfc-editor.org/info/rfc7635>.
Authors' Addresses Authors' Addresses
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
 End of changes. 19 change blocks. 
43 lines changed or deleted 68 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/