draft-ietf-tram-turnbis-07.txt   draft-ietf-tram-turnbis-08.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: March 24, 2016 Avaya Expires: July 11, 2016 Avaya
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
September 21, 2015 January 8, 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-07 draft-ietf-tram-turnbis-08
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 March 24, 2016. This Internet-Draft will expire on July 11, 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 3, line 13 skipping to change at page 3, line 13
10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37 10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37
10.2. Receiving a Send Indication . . . . . . . . . . . . . . 38 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 38
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 39 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 39
10.4. Receiving a Data Indication with DATA attribute . . . . 39 10.4. Receiving a Data Indication with DATA attribute . . . . 39
10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40 10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40
10.6. Receiving a Data Indication with an ICMP attribute . . . 40 10.6. Receiving a Data Indication with an ICMP attribute . . . 40
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 43 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 43
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 43 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 43
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 44 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 44
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 44 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 45
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 45 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 45
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 46 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 46
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 47 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 47
12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 47 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 47
12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 47 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 47
12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 48 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 48
12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 49 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 49
13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 50 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 50
14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 52 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 52
15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 52 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 52
skipping to change at page 13, line 13 skipping to change at page 13, line 13
attribute and the data itself in a DATA attribute. Since the relayed attribute and the data itself in a DATA attribute. Since the relayed
transport address uniquely identified the allocation, the server transport address uniquely identified the allocation, the server
knows which client should receive the data. knows which client should receive the data.
Some ICMP (Internet Control Message Protocol) packets arriving at the Some ICMP (Internet Control Message Protocol) packets arriving at the
relayed transport address on the TURN server may be converted into relayed transport address on the TURN server may be converted into
Data indications and sent to the client, with the transport address Data indications and sent to the client, with the transport address
of the peer included in an XOR-PEER-ADDRESS attribute and the ICMP of the peer included in an XOR-PEER-ADDRESS attribute and the ICMP
type and code in a ICMP attribute. Data indications containing the type and code in a ICMP attribute. Data indications containing the
XOR-PEER-ADDRESS and ICMP attribute are also sent when using the XOR-PEER-ADDRESS and ICMP attribute are also sent when using the
channel machanism. channel mechanism.
Send and Data indications cannot be authenticated, since the long- Send and Data indications cannot be authenticated, since the long-
term credential mechanism of STUN does not support authenticating term credential mechanism of STUN does not support authenticating
indications. This is not as big an issue as it might first appear, indications. This is not as big an issue as it might first appear,
since the client-to-server leg is only half of the total path to the since the client-to-server leg is only half of the total path to the
peer. Applications that want proper security should encrypt the data peer. Applications that want proper security should encrypt the data
sent between the client and a peer. sent between the client and a peer.
Because Send indications are not authenticated, it is possible for an Because Send indications are not authenticated, it is possible for an
attacker to send bogus Send indications to the server, which will attacker to send bogus Send indications to the server, which will
skipping to change at page 16, line 32 skipping to change at page 16, line 32
o The value of the Diffserv field may not be preserved across the o The value of the Diffserv field may not be preserved across the
server; server;
o The Time to Live (TTL) field may be reset, rather than o The Time to Live (TTL) field may be reset, rather than
decremented, across the server; decremented, across the server;
o The Explicit Congestion Notification (ECN) field may be reset by o The Explicit Congestion Notification (ECN) field may be reset by
the server; the server;
o ICMP messages are not relayed by the server;
o There is no end-to-end fragmentation, since the packet is re- o There is no end-to-end fragmentation, since the packet is re-
assembled at the server. assembled at the server.
Future work may specify alternate TURN semantics that address these Future work may specify alternate TURN semantics that address these
limitations. limitations.
2.7. Avoiding IP Fragmentation 2.7. Avoiding IP Fragmentation
For reasons described in [Frag-Harmful], applications, especially For reasons described in [Frag-Harmful], applications, especially
those sending large volumes of data, should try hard to avoid having those sending large volumes of data, should try hard to avoid having
skipping to change at page 17, line 33 skipping to change at page 17, line 30
a UDP datagram (by the peer on the peer-to-server leg) will generally a UDP datagram (by the peer on the peer-to-server leg) will generally
avoid IP fragmentation. To further reduce the chance of avoid IP fragmentation. To further reduce the chance of
fragmentation, it is recommended that the client use ChannelData fragmentation, it is recommended that the client use ChannelData
messages when transferring significant volumes of data, since the messages when transferring significant volumes of data, since the
overhead of the ChannelData message is less than Send and Data overhead of the ChannelData message is less than Send and Data
indications. indications.
The second approach the client and peer can take to avoid The second approach the client and peer can take to avoid
fragmentation is to use a path MTU discovery algorithm to determine fragmentation is to use a path MTU discovery algorithm to determine
the maximum amount of application data that can be sent without the maximum amount of application data that can be sent without
fragmentation. fragmentation. The classic path MTU discovery algorithm defined in
[RFC1191] may not be able to discover the MTU of the transmission
path between the client and the peer since:
Unfortunately, because servers implementing this version of TURN are - a probe packet with DF bit set to test a path for a larger MTU
not required to relay ICMP messages, the classic path MTU discovery can be dropped by routers, or
algorithm defined in [RFC1191] is not able to discover the MTU of the
transmission path between the client and the peer.
So the client and server need to use a path MTU discovery algorithm - ICMP error messages can be dropped by middle boxes.
that does not require ICMP messages. The Packetized Path MTU
Discovery algorithm defined in [RFC4821] is one such algorithm.
[I-D.petithuguenin-tram-stun-pmtud] is an implementation of [RFC4821] As a result, the client and server need to use a path MTU discovery
that is using STUN to discover the PMTUD, and so may be a suitable algorithm that does not require ICMP messages. The Packetized Path
approach to be used in conjunction with a TURN server, together with MTU Discovery algorithm defined in [RFC4821] is one such algorithm.
the DONT-FRAGMENT attribute. When the client includes the DONT-
FRAGMENT attribute in a Send indication, this tells the server to set [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that is
the DF bit in the resulting UDP datagram that it sends to the peer. using STUN to discover the PMTUD, and so may be a suitable approach
Since some servers may be unable to set the DF bit, the client should to be used in conjunction with a TURN server, together with the DONT-
also include this attribute in the Allocate request -- any server FRAGMENT attribute. When the client includes the DONT-FRAGMENT
that does not support the DONT-FRAGMENT attribute will indicate this attribute in a Send indication, this tells the server to set the DF
by rejecting the Allocate request. bit in the resulting UDP datagram that it sends to the peer. Since
some servers may be unable to set the DF bit, the client should also
include this attribute in the Allocate request -- any server that
does not support the DONT-FRAGMENT attribute will indicate this by
rejecting the Allocate request.
2.8. RTP Support 2.8. RTP Support
One of the envisioned uses of TURN is as a relay for clients and One of the envisioned uses of TURN is as a relay for clients and
peers wishing to exchange real-time data (e.g., voice or video) using peers wishing to exchange real-time data (e.g., voice or video) using
RTP. To facilitate the use of TURN for this purpose, TURN includes RTP. To facilitate the use of TURN for this purpose, TURN includes
some special support for older versions of RTP. some special support for older versions of RTP.
Old versions of RTP [RFC3550] required that the RTP stream be on an Old versions of RTP [RFC3550] required that the RTP stream be on an
even port number and the associated RTP Control Protocol (RTCP) even port number and the associated RTP Control Protocol (RTCP)
skipping to change at page 40, line 31 skipping to change at page 40, line 31
the destination IP address from the encapsulated IP header. The the destination IP address from the encapsulated IP header. The
server then compares this address with the IP address associated with server then compares this address with the IP address associated with
each permission in the list of permissions for the allocation. If no each permission in the list of permissions for the allocation. If no
match is found, relaying is not permitted, and the server silently match is found, relaying is not permitted, and the server silently
discards the ICMP packet. Note that only addresses are compared and discards the ICMP packet. Note that only addresses are compared and
port numbers are not considered. port numbers are not considered.
If relaying is permitted then the server forms and sends a Data If relaying is permitted then the server forms and sends a Data
indication. The Data indication MUST contain both an XOR-PEER- indication. The Data indication MUST contain both an XOR-PEER-
ADDRESS and an ICMP attribute. The ICMP attribute is set to the ADDRESS and an ICMP attribute. The ICMP attribute is set to the
value of the type and code fields from the ICMP packet, and the XOR- value of the type and code fields from the ICMP packet. The IP
PEER-ADDRESS attribute is set to the destination IP address in the IP address portion of XOR-PEER-ADDRESS attribute is set to the
header and to the destination port in the UDP header. Both are found destination IP address in the encapsulated IP header. At the time of
in the ICMP packet payload. The Data indication is then sent on the writing of this specification, Socket APIs on some operating systems
5-tuple associated with the allocation. do not deliver the destination port in the encapsulated UDP header to
applications without superuser privileges. If destination port in
the encapsulated UDP header is available to the server then the port
portion of XOR-PEER-ADDRESS attribute is set to the destination port
otherwise the port portion is set to 0. The Data indication is then
sent on the 5-tuple associated with the allocation.
10.6. Receiving a Data Indication with an ICMP attribute 10.6. Receiving a Data Indication with an ICMP attribute
When the client receives a Data indication with an ICMP attribute, it When the client receives a Data indication with an ICMP attribute, it
checks that the Data indication contains an XOR-PEER-ADDRESS checks that the Data indication contains an XOR-PEER-ADDRESS
attribute, and discards the indication if it does not. The client attribute, and discards the indication if it does not. The client
SHOULD also check that the XOR-PEER-ADDRESS attribute value contains SHOULD also check that the XOR-PEER-ADDRESS attribute value contains
an IP address with an active permission, and discard the Data an IP address with an active permission, and discard the Data
indication otherwise. indication otherwise.
skipping to change at page 75, line 47 skipping to change at page 75, line 47
22. Acknowledgements 22. Acknowledgements
Most of the text in this note comes from the original TURN Most of the text in this note comes from the original TURN
specification, [RFC5766]. The authors would like to thank Rohan Mahy specification, [RFC5766]. The authors would like to thank Rohan Mahy
co-author of orginal TURN specification and everyone who had co-author of orginal TURN specification and everyone who had
contributed to that document. contributed to that document.
Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang
and Simon Perreault for their help on SSODA mechanism. Authors would and Simon Perreault for their help on SSODA mechanism. Authors would
like to thank Gonzalo Salgueiro, Simon Perreault and Jonathan Lennox like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox and
for comments and review. The authors would like to thank Marc for Oleg Moskalenko for comments and review. The authors would like to
his contributions to the text. thank Marc for his contributions to the text.
23. References 23. References
23.1. Normative References 23.1. Normative References
[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>.
skipping to change at page 79, line 5 skipping to change at page 79, line 5
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[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.petithuguenin-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-
petithuguenin-tram-stun-pmtud-01 (work in progress), July ietf-tram-stun-pmtud-00 (work in progress), November 2015.
2015.
[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-04 (work Discovery", draft-ietf-tram-turn-server-discovery-06 (work
in progress), July 2015. in progress), January 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,
 End of changes. 17 change blocks. 
40 lines changed or deleted 44 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/