draft-ietf-tram-turnbis-08.txt   draft-ietf-tram-turnbis-09.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Johnston, Ed. Intended status: Standards Track A. Johnston, Ed.
Expires: July 11, 2016 Avaya Expires: May 3, 2017 Unaffiliated
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
January 8, 2016 October 30, 2016
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-08 draft-ietf-tram-turnbis-09
Abstract Abstract
If a host is located behind a NAT, then in certain situations it can If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use (peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using operation of the relay and to exchange packets with its peers using
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 11, 2016. This Internet-Draft will expire on May 3, 2017.
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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
18.3.3. Manipulating Other Allocations . . . . . . . . . . . 71 18.3.3. Manipulating Other Allocations . . . . . . . . . . . 71
18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 71 18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 71
18.5. Other Considerations . . . . . . . . . . . . . . . . . . 72 18.5. Other Considerations . . . . . . . . . . . . . . . . . . 72
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 73 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 73
21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 75 21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 75
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 75 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 75
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 76 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 76
23.1. Normative References . . . . . . . . . . . . . . . . . . 76 23.1. Normative References . . . . . . . . . . . . . . . . . . 76
23.2. Informative References . . . . . . . . . . . . . . . . . 77 23.2. Informative References . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
1. Introduction 1. Introduction
A host behind a NAT may wish to exchange packets with other hosts, A host behind a NAT may wish to exchange packets with other hosts,
some of which may also be behind NATs. To do this, the hosts some of which may also be behind NATs. To do this, the hosts
involved can use "hole punching" techniques (see [RFC5128]) in an involved can use "hole punching" techniques (see [RFC5128]) in an
attempt discover a direct communication path; that is, a attempt discover a direct communication path; that is, a
communication path that goes from one host to another through communication path that goes from one host to another through
intervening NATs and routers, but does not traverse any relays. intervening NATs and routers, but does not traverse any relays.
skipping to change at page 23, line 37 skipping to change at page 23, line 37
identify the allocation. identify the allocation.
The authentication information (e.g., username, password, realm, and The authentication information (e.g., username, password, realm, and
nonce) is used to both verify subsequent requests and to compute the nonce) is used to both verify subsequent requests and to compute the
message integrity of responses. The username, realm, and nonce message integrity of responses. The username, realm, and nonce
values are initially those used in the authenticated Allocate request values are initially those used in the authenticated Allocate request
that creates the allocation, though the server can change the nonce that creates the allocation, though the server can change the nonce
value during the lifetime of the allocation using a 438 (Stale Nonce) value during the lifetime of the allocation using a 438 (Stale Nonce)
reply. Note that, rather than storing the password explicitly, for reply. Note that, rather than storing the password explicitly, for
security reasons, it may be desirable for the server to store the key security reasons, it may be desirable for the server to store the key
value, which is an MD5 hash over the username, realm, and password value, which is an secure hash over the username, realm, and password
(see [RFC5389]). (see [I-D.ietf-tram-stunbis]).
Editor's Note: Remove MD5 based on the changes in STUN bis draft.
The time-to-expiry is the time in seconds left until the allocation The time-to-expiry is the time in seconds left until the allocation
expires. Each Allocate or Refresh transaction sets this timer, which expires. Each Allocate or Refresh transaction sets this timer, which
then ticks down towards 0. By default, each Allocate or Refresh then ticks down towards 0. By default, each Allocate or Refresh
transaction resets this timer to the default lifetime value of 600 transaction resets this timer to the default lifetime value of 600
seconds (10 minutes), but the client can request a different value in seconds (10 minutes), but the client can request a different value in
the Allocate and Refresh request. Allocations can only be refreshed the Allocate and Refresh request. Allocations can only be refreshed
using the Refresh request; sending data to a peer does not refresh an using the Refresh request; sending data to a peer does not refresh an
allocation. When an allocation expires, the state data associated allocation. When an allocation expires, the state data associated
with the allocation can be freed. with the allocation can be freed.
skipping to change at page 77, line 11 skipping to change at page 77, line 11
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>. <http://www.rfc-editor.org/info/rfc792>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
[I-D.ietf-tram-stunbis]
Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", draft-ietf-tram-stunbis-08
(work in progress), June 2016.
23.2. Informative References 23.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
skipping to change at page 79, line 8 skipping to change at page 79, line 14
[I-D.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008. nonsip-01 (work in progress), July 2008.
[I-D.ietf-tram-stun-pmtud] [I-D.ietf-tram-stun-pmtud]
Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft- Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-00 (work in progress), November 2015. ietf-tram-stun-pmtud-03 (work in progress), October 2016.
[I-D.ietf-tram-turn-server-discovery] [I-D.ietf-tram-turn-server-discovery]
Patil, P., Reddy, T., and D. Wing, "TURN Server Auto Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
Discovery", draft-ietf-tram-turn-server-discovery-06 (work Discovery", draft-ietf-tram-turn-server-discovery-10 (work
in progress), January 2016. in progress), October 2016.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[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, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
skipping to change at page 80, line 4 skipping to change at page 80, line 15
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Varthur Hobl Cessna Business Park, Varthur Hobl
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
Alan Johnston (editor) Alan Johnston (editor)
Avaya Unaffiliated
St. Louis, MO Bellevue, WA
USA USA
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Philip Matthews Philip Matthews
Alcatel-Lucent Alcatel-Lucent
600 March Road 600 March Road
Ottawa, Ontario Ottawa, Ontario
Canada Canada
 End of changes. 11 change blocks. 
14 lines changed or deleted 19 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/