draft-ietf-tram-turnbis-17.txt   draft-ietf-tram-turnbis-18.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Obsoletes: 5766,6156 (if approved) A. Johnston, Ed. Obsoletes: 5766,6156 (if approved) A. Johnston, Ed.
Intended status: Standards Track Rowan University Intended status: Standards Track Rowan University
Expires: October 25, 2018 P. Matthews Expires: November 30, 2018 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
April 23, 2018 May 29, 2018
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-17 draft-ietf-tram-turnbis-18
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 2, line 4 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 25, 2018. This Internet-Draft will expire on November 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 4 skipping to change at page 3, line 4
7.3. Receiving an Allocate Success Response . . . . . . . . . 32 7.3. Receiving an Allocate Success Response . . . . . . . . . 32
7.4. Receiving an Allocate Error Response . . . . . . . . . . 33 7.4. Receiving an Allocate Error Response . . . . . . . . . . 33
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 35 8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 35
8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35 8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35
8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 36 8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 36
8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37
9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38 10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a CreatePermission Request . . . . . . . . . . . 38 10.1. Forming a CreatePermission Request . . . . . . . . . . . 38
10.2. Receiving a CreatePermission Request . . . . . . . . . . 39 10.2. Receiving a CreatePermission Request . . . . . . . . . . 39
10.3. Receiving a CreatePermission Response . . . . . . . . . 39 10.3. Receiving a CreatePermission Response . . . . . . . . . 40
11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 40 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 40
11.1. Forming a Send Indication . . . . . . . . . . . . . . . 40 11.1. Forming a Send Indication . . . . . . . . . . . . . . . 40
11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40 11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40
11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 41 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 41
11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41 11.4. Receiving a Data Indication . . . . . . . . . . . . . . 42
11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 42 11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 42
11.6. Receiving a Data Indication with an ICMP attribute . . . 43 11.6. Receiving a Data Indication with an ICMP attribute . . . 43
12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45 12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45
12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 46 12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 46
12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47
12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47 12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47
12.5. Sending a ChannelData Message . . . . . . . . . . . . . 48 12.5. Sending a ChannelData Message . . . . . . . . . . . . . 48
12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48
12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49
skipping to change at page 11, line 49 skipping to change at page 11, line 49
To ease concerns amongst enterprise IT administrators that TURN could To ease concerns amongst enterprise IT administrators that TURN could
be used to bypass corporate firewall security, TURN includes the be used to bypass corporate firewall security, TURN includes the
notion of permissions. TURN permissions mimic the address-restricted notion of permissions. TURN permissions mimic the address-restricted
filtering mechanism of NATs that comply with [RFC4787]. filtering mechanism of NATs that comply with [RFC4787].
An allocation can have zero or more permissions. Each permission An allocation can have zero or more permissions. Each permission
consists of an IP address and a lifetime. When the server receives a consists of an IP address and a lifetime. When the server receives a
UDP datagram on the allocation's relayed transport address, it first UDP datagram on the allocation's relayed transport address, it first
checks the list of permissions. If the source IP address of the checks the list of permissions. If the source IP address of the
datagram matches a permission, the application data is relayed to the datagram matches a permission, the application data is relayed to the
client, otherwise the UDP datagram is silently discarded. However, a client, otherwise the UDP datagram is silently discarded. A TURN
TURN server can be configured to permit inbound STUN packets on the server can be configured to permit inbound STUN packets on the
allocation's relayed address even if the source IP addresses of the allocation's relayed address even if the source IP addresses of the
STUN packets do not match the permissions installed. The filtering STUN packets do not match the permissions installed. The filtering
rule to block all traffic except STUN packets speeds up STUN rule to block all traffic except STUN packets speeds up STUN
connectivity checks, while the client creates permissions in the TURN connectivity checks, allowing the remote peer to initiate
server for the remote peer IP addresses, the remote peer can initiate connectivity checks to the client while the client is creating
connectivity checks to the client. permissions in the TURN server for the remote peer IP addresses.
A permission expires after 5 minutes if it is not refreshed, and A permission expires after 5 minutes if it is not refreshed, and
there is no way to explicitly delete a permission. This behavior was there is no way to explicitly delete a permission. This behavior was
selected to match the behavior of a NAT that complies with [RFC4787]. selected to match the behavior of a NAT that complies with [RFC4787].
The client can install or refresh a permission using either a The client can install or refresh a permission using either a
CreatePermission request or a ChannelBind request. Using the CreatePermission request or a ChannelBind request. Using the
CreatePermission request, multiple permissions can be installed or CreatePermission request, multiple permissions can be installed or
refreshed with a single request -- this is important for applications refreshed with a single request -- this is important for applications
that use ICE. For security reasons, permissions can only be that use ICE. For security reasons, permissions can only be
skipping to change at page 37, line 49 skipping to change at page 37, line 49
Each permission's time-to-expiry decreases down once per second until Each permission's time-to-expiry decreases down once per second until
it reaches 0; at which point, the permission expires and is deleted. it reaches 0; at which point, the permission expires and is deleted.
CreatePermission and ChannelBind requests may be freely intermixed on CreatePermission and ChannelBind requests may be freely intermixed on
a permission. A given permission may be initially installed and/or a permission. A given permission may be initially installed and/or
refreshed with a CreatePermission request, and then later refreshed refreshed with a CreatePermission request, and then later refreshed
with a ChannelBind request, or vice versa. with a ChannelBind request, or vice versa.
A TURN server MUST have a configuration knob to allow inbound STUN A TURN server MUST have a configuration knob to allow inbound STUN
packets on the allocation's relayed address even if the source IP packets on the allocation's relayed address even if the source IP
addresses of the STUN packets do not match the permissions installed, addresses of the STUN packets do not match the permissions installed.
this configuration knob MUST default to drop the inbound STUN packets This configuration knob MUST default to drop the inbound STUN packets
on the allocation's relayed address if the source IP addresses of the on the allocation's relayed address if the source IP addresses of the
STUN packets do not match the permissions installed unless explicitly STUN packets do not match the permissions installed unless explicitly
configured to do so otherwise. configured to do otherwise.
When a UDP datagram arrives at the relayed transport address for the When a UDP datagram arrives at the relayed transport address for the
allocation, the server extracts the source IP address from the IP allocation, the server extracts the source IP address from the IP
header. The server then compares this address with the IP address header. The server then compares this address with the IP address
associated with each permission in the list of permissions for the associated with each permission in the list of permissions for the
allocation. If no match is found and the received datagram is not a allocation. If no match is found and the received datagram is not a
STUN packet, relaying is not permitted, and the server silently STUN packet, the permission check is considered to have failed. If
discards the UDP datagram. If an exact match is found or the an exact match is found, the permission check is considered to have
received datagram is a STUN packet, then the permission check is succeeded. If no match is found and the received datagram is a STUN
considered to have succeeded and the server continues to process the packet, the permission check is considered to have failed unless the
UDP datagram as specified elsewhere (Section 11.3). Note that only server is configured to allow STUN packets without explicit
addresses are compared and port numbers are not considered. permission, in which case the permission check is considered to have
succeeded. If the permission check fails, relaying is not permitted
and the server silently discards the UDP datagram. If the permission
check succeeds, the services continues to process the UDP datagram as
specified elsewhere (Section 11.3). Note that only addresses are
compared and port numbers are not considered.
The permissions for one allocation are totally unrelated to the The permissions for one allocation are totally unrelated to the
permissions for a different allocation. If an allocation expires, permissions for a different allocation. If an allocation expires,
all its permissions expire with it. all its permissions expire with it.
NOTE: Though TURN permissions expire after 5 minutes, many NATs NOTE: Though TURN permissions expire after 5 minutes, many NATs
deployed at the time of publication expire their UDP bindings deployed at the time of publication expire their UDP bindings
considerably faster. Thus, an application using TURN will considerably faster. Thus, an application using TURN will
probably wish to send some sort of keep-alive traffic at a much probably wish to send some sort of keep-alive traffic at a much
faster rate. Applications using ICE should follow the keep-alive faster rate. Applications using ICE should follow the keep-alive
skipping to change at page 72, line 30 skipping to change at page 72, line 30
It is important to note that some firewalls have policies that are It is important to note that some firewalls have policies that are
even more restrictive than address-dependent filtering. Firewalls even more restrictive than address-dependent filtering. Firewalls
can also be configured with address- and port-dependent filtering, or can also be configured with address- and port-dependent filtering, or
can be configured to disallow inbound traffic entirely. In these can be configured to disallow inbound traffic entirely. In these
cases, if a client is allowed to connect the TURN server, cases, if a client is allowed to connect the TURN server,
communications to the client will be less restrictive than what the communications to the client will be less restrictive than what the
firewall would normally allow. firewall would normally allow.
When a TURN server is configured to permit inbound STUN packets on When a TURN server is configured to permit inbound STUN packets on
the allocation's relayed address even if the source IP addresses of the allocation's relayed address even if the source IP addresses of
the STUN packets does not match the permissions installed, in order the STUN packets do not match the permissions installed, the TURN
to prevent an attacker from flooding the TURN client with STUN-like server MUST have a security policy for inbound STUN packets from IP
packets, the TURN server can look for STUN attributes USERNAME and addresses not matching the permissions installed in order to prevent
MESSAGE-INTEGRITY in the STUN message to only allow STUN connectivity an attacker from flooding the TURN client with STUN-like packets.
check packet. A TURN server MUST have a security policy for inbound The TURN server can limit forwarding to well-formed STUN connectivity
STUN packets from IP addresses not matching the permissions check packets by looking for the STUN atrributes USERNAME and
installed, the policy can be configured to only allow STUN packets MESSAGE-INTEGRITY and verifying that the message does not exceed a
not exceeding a specific packet size, maximum number of STUN packets specific configurable packet size. Additionally, the TURN server
allowed in a TURN session, rate-limit the number of STUN packets policy can be configured with maximum rate-limits for the number of
allowed per second, restrict the maximum number of IP addresses STUN packets allowed in a TURN session, STUN packets allowed per
allowed to send STUN packets that do not match the permissions second, and IP addresses allowed to send STUN packets.
installed in a TURN session.
19.2.1. Faked Permissions 19.2.1. Faked Permissions
In firewalls and NAT devices, permissions are granted implicitly In firewalls and NAT devices, permissions are granted implicitly
through the traversal of a packet from the inside of the network through the traversal of a packet from the inside of the network
towards the outside peer. Thus, a permission cannot, by definition, towards the outside peer. Thus, a permission cannot, by definition,
be created by any entity except one inside the firewall or NAT. With be created by any entity except one inside the firewall or NAT. With
TURN, this restriction no longer holds. Since the TURN server sits TURN, this restriction no longer holds. Since the TURN server sits
outside the firewall, at attacker outside the firewall can now send a outside the firewall, at attacker outside the firewall can now send a
message to the TURN server and try to create a permission for itself. message to the TURN server and try to create a permission for itself.
skipping to change at page 79, line 14 skipping to change at page 79, line 14
update to allow the TURN server to forward inbound STUN connectivity update to allow the TURN server to forward inbound STUN connectivity
checks without permission. checks without permission.
24. References 24. References
24.1. Normative References 24.1. Normative References
[I-D.ietf-tram-stunbis] [I-D.ietf-tram-stunbis]
Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", draft-ietf-tram-stunbis-16 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-18
(work in progress), March 2018. (work in progress), May 2018.
[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,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 80, line 43 skipping to change at page 80, line 43
24.2. Informative References 24.2. Informative References
[Frag-Harmful] [Frag-Harmful]
"Fragmentation Considered Harmful", <Proc. SIGCOMM '87, "Fragmentation Considered Harmful", <Proc. SIGCOMM '87,
vol. 17, No. 5, October 1987>. vol. 17, No. 5, October 1987>.
[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-07 (work in progress), March 2018. ietf-tram-stun-pmtud-08 (work in progress), May 2018.
[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.
[Port-Numbers] [Port-Numbers]
"IANA Port Numbers Registry", 2005, "IANA Port Numbers Registry", 2005,
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
 End of changes. 14 change blocks. 
35 lines changed or deleted 39 lines changed or added

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