draft-ietf-tram-turn-server-discovery-00.txt   draft-ietf-tram-turn-server-discovery-01.txt 
TRAM P. Patil TRAM P. Patil
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: January 25, 2015 Cisco Expires: July 26, 2015 Cisco
July 24, 2014 January 22, 2015
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-00 draft-ietf-tram-turn-server-discovery-01
Abstract Abstract
Current Traversal Using Relays around NAT (TURN) server discovery Current Traversal Using Relays around NAT (TURN) server discovery
mechanisms are relatively static and limited to explicit mechanisms are relatively static and limited to explicit
configuration. These are usually under the administrative control of configuration. These are usually under the administrative control of
the application or TURN service provider, and not the enterprise or the application or TURN service provider, and not the enterprise or
the ISP, the network in which the client is located. Enterprises and the ISP, the network in which the client is located. Enterprises and
ISPs wishing to provide their own TURN servers need auto discovery ISPs wishing to provide their own TURN servers need auto discovery
mechanisms that a TURN client could use with no or minimal mechanisms that a TURN client could use with no or minimal
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 25, 2015. This Internet-Draft will expire on July 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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 36 skipping to change at page 2, line 36
7.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8.1. Service Resolution . . . . . . . . . . . . . . . . . . . 8 8.1. Service Resolution . . . . . . . . . . . . . . . . . . . 8
8.2. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.2. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10
A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 10 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
TURN [RFC5766] is a protocol that is often used to improve the TURN [RFC5766] is a protocol that is often used to improve the
connectivity of P2P applications. By providing a relay service, TURN connectivity of Peer-to-Peer (P2P) applications (as defined in
ensures that a connection can be established even when one or both section 2.7 of [RFC5128]). TURN allows a connection to be
sides is incapable of a direct P2P connection. It is an important established when one or both sides are incapable of a direct P2P
building block for interactive, real-time communication using audio, connection. It is an important building block for interactive, real-
video, collaboration etc. While TURN services are extensively used time communication using audio, video, collaboration etc. While TURN
today, the means to auto discover TURN servers do not exist. TURN services are extensively used today, the means to auto discover TURN
clients are usually explicitly configured with a well known TURN servers do not exist. TURN clients are usually explicitly configured
server. To allow TURN applications operate seamlessly across with a well known TURN server. To allow TURN applications operate
different types of networks and encourage the use of TURN without the seamlessly across different types of networks and encourage the use
need for manual configuration, it is important that there exists an of TURN without the need for manual configuration, it is important
auto discovery mechanism for TURN services. WebRTC usages and that there exists an auto discovery mechanism for TURN services. Web
related extensions, which are mostly based on web applications, need Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] usages
this immediately. and related extensions, which are mostly based on web applications,
need this immediately.
This document describes two discovery mechanisms. The reason for This document describes two discovery mechanisms. The reason for
providing two mechanisms is to maximize the opportunity for providing two mechanisms is to maximize the opportunity for
discovery, based on the network in the which the TURN client sees discovery, based on the network in the which the TURN client sees
itself. itself.
o A resolution mechanism based on straightforward Naming Authority o A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System Pointer (S-NAPTR) resource records in the Domain Name System
(DNS). [RFC5928] describes details on retrieving a list of server (DNS). [RFC5928] describes details on retrieving a list of server
transport addresses from DNS that can be used to create a TURN transport addresses from DNS that can be used to create a TURN
skipping to change at page 8, line 20 skipping to change at page 8, line 20
address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF
Protocol Assignments, as listed at Protocol Assignments, as listed at
<http://www.iana.org/assignments/iana-ipv4-special-registry/> and <http://www.iana.org/assignments/iana-ipv4-special-registry/> and
<http://www.iana.org/assignments/iana-ipv6-special-registry/> <http://www.iana.org/assignments/iana-ipv6-special-registry/>
8. Security Considerations 8. Security Considerations
In general, it is recommended that a TURN client authenticate with In general, it is recommended that a TURN client authenticate with
the TURN server to identify a rouge server. the TURN server to identify a rouge server. [RFC7350] can be
[I-D.petithuguenin-tram-turn-dtls] can be potentially used by a potentially used by a client to validate a previously unknown server.
client to validate a previously unknown server.
8.1. Service Resolution 8.1. Service Resolution
The primary attack against the methods described in this document is The primary attack against the methods described in this document is
one that would lead to impersonation of a TURN server. An attacker one that would lead to impersonation of a TURN server. An attacker
could attempt to compromise the S-NAPTR resolution. Security could attempt to compromise the S-NAPTR resolution. Security
considerations described in [RFC5928] are applicable here as well. considerations described in [RFC5928] are applicable here as well.
In addition to considerations related to S-NAPTR, it is important to In addition to considerations related to S-NAPTR, it is important to
recognize that the output of this is entirely dependent on its input. recognize that the output of this is entirely dependent on its input.
skipping to change at page 9, line 19 skipping to change at page 9, line 19
no route exists to said address. no route exists to said address.
Sensitive clients that do not wish to leak information about their Sensitive clients that do not wish to leak information about their
presence can set an IP TTL on their TURN requests that limits how far presence can set an IP TTL on their TURN requests that limits how far
they can travel into the public Internet. they can travel into the public Internet.
9. Acknowledgements 9. Acknowledgements
Discovery using Service Resolution described in Section 4 of this Discovery using Service Resolution described in Section 4 of this
document was derived from similar techniques described in ALTO Server document was derived from similar techniques described in ALTO Server
Discovery [I-D.ietf-alto-server-discovery] and Discovery [RFC7286] and [I-D.kist-alto-3pdisc].
[I-D.kist-alto-3pdisc].
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.petithuguenin-tram-turn-dtls]
Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Traversal Using
Relays around NAT (TURN)", draft-petithuguenin-tram-turn-
dtls-00 (work in progress), January 2014.
[I-D.wing-mmusic-ice-mobility]
Wing, D., Reddy, T., Patil, P., and P. Martinsen,
"Mobility with ICE (MICE)", draft-wing-mmusic-ice-
mobility-07 (work in progress), June 2014.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
skipping to change at page 10, line 16 skipping to change at page 10, line 5
(TURN) Resolution Mechanism", RFC 5928, August 2010. (TURN) Resolution Mechanism", RFC 5928, August 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, September Location Information Server (LIS)", RFC 5986, September
2010. 2010.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server [RFC7216] Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS", RFC (LIS) Discovery Using IP Addresses and Reverse DNS", RFC
7216, April 2014. 7216, April 2014.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, August 2014.
10.2. Informative References 10.2. Informative References
[I-D.ietf-alto-server-discovery] [I-D.ietf-rtcweb-overview]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and Alvestrand, H., "Overview: Real Time Protocols for
S. Yongchao, "ALTO Server Discovery", draft-ietf-alto- Browser-based Applications", draft-ietf-rtcweb-overview-13
server-discovery-10 (work in progress), September 2013. (work in progress), November 2014.
[I-D.kist-alto-3pdisc] [I-D.kist-alto-3pdisc]
Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
(work in progress), January 2014. (work in progress), January 2014.
[I-D.wing-mmusic-ice-mobility]
Wing, D., Reddy, T., Patil, P., and P. Martinsen,
"Mobility with ICE (MICE)", draft-wing-mmusic-ice-
mobility-07 (work in progress), June 2014.
[RFC3188] Hakala, J., "Using National Bibliography Numbers as [RFC3188] Hakala, J., "Using National Bibliography Numbers as
Uniform Resource Names", RFC 3188, October 2001. Uniform Resource Names", RFC 3188, October 2001.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, March 2008.
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "Application-Layer Traffic Optimization (ALTO)
Server Discovery", RFC 7286, November 2014.
Appendix A. Change History Appendix A. Change History
[Note to RFC Editor: Please remove this section prior to [Note to RFC Editor: Please remove this section prior to
publication.] publication.]
A.1. Change from draft-patil-tram-serv-disc-00 to -01 A.1. Change from draft-patil-tram-serv-disc-00 to -01
o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new
means to obtain domain names means to obtain domain names
 End of changes. 13 change blocks. 
39 lines changed or deleted 44 lines changed or added

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