draft-ietf-tram-turnbis-16.txt   draft-ietf-tram-turnbis-17.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: September 28, 2018 P. Matthews Expires: October 25, 2018 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
March 27, 2018 April 23, 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-16 draft-ietf-tram-turnbis-17
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 September 28, 2018. This Internet-Draft will expire on October 25, 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 2, line 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 17
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18 2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 21 4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 21
4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 21 4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 21
5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21 5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21
6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25 7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25
7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25 7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25
7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27 7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27
7.3. Receiving an Allocate Success Response . . . . . . . . . 32 7.3. Receiving an Allocate Success Response . . . . . . . . . 32
7.4. Receiving an Allocate Error Response . . . . . . . . . . 32 7.4. Receiving an Allocate Error Response . . . . . . . . . . 33
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . 35 8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 36
8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 36 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37
9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . 38 10.2. Receiving a CreatePermission Request . . . . . . . . . . 39
10.3. Receiving a CreatePermission Response . . . . . . . . . 39 10.3. Receiving a CreatePermission Response . . . . . . . . . 39
11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 39 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 40
11.1. Forming a Send Indication . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . 40 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 41
11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41 11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41
11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41 11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 42
11.6. Receiving a Data Indication with an ICMP attribute . . . 42 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 . . . . . . . . . . . . 45 12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 46
12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 46 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47
12.4. The ChannelData Message . . . . . . . . . . . . . . . . 46 12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47
12.5. Sending a ChannelData Message . . . . . . . . . . . . . 47 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
13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 49 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 50
13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 49 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 50
13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 50 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 51
13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52
14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 52 14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 53
15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 54 15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 55
16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 54 16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 55
16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55 16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55
16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 55 16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 56
16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 55 16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 56
16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 55 16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 56
16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56 16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56
16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56 16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56
16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56 16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 57
16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57 16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57
16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 57 16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 58
16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 57 16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 58
16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57 16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 58
16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58 16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58
16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58 16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 59
17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59 17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59
18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60 18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60
19. Security Considerations . . . . . . . . . . . . . . . . . . . 68 19. Security Considerations . . . . . . . . . . . . . . . . . . . 68
19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68 19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68
19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68 19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68
19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68 19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68
19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69 19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69
19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69 19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69
19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70 19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70
19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70 19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70
19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 71 19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 71
19.2. Firewall Considerations . . . . . . . . . . . . . . . . 71 19.2. Firewall Considerations . . . . . . . . . . . . . . . . 71
19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 72 19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 72
19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 72 19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 73
19.2.3. Running Servers on Well-Known Ports . . . . . . . . 73 19.2.3. Running Servers on Well-Known Ports . . . . . . . . 73
19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73 19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73
19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 73 19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 73
19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 73 19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 74
19.3.3. Manipulating Other Allocations . . . . . . . . . . . 74 19.3.3. Manipulating Other Allocations . . . . . . . . . . . 74
19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 74 19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 74
19.5. Other Considerations . . . . . . . . . . . . . . . . . . 75 19.5. Other Considerations . . . . . . . . . . . . . . . . . . 75
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 76 21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 76
22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 78 22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 78
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
24.1. Normative References . . . . . . . . . . . . . . . . . . 78 24.1. Normative References . . . . . . . . . . . . . . . . . . 79
24.2. Informative References . . . . . . . . . . . . . . . . . 80 24.2. Informative References . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
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
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. client, otherwise the UDP datagram is silently discarded. However, a
TURN server can be configured to permit inbound STUN packets on the
allocation's relayed address even if the source IP addresses of the
STUN packets do not match the permissions installed. The filtering
rule to block all traffic except STUN packets speeds up STUN
connectivity checks, while the client creates permissions in the TURN
server for the remote peer IP addresses, the remote peer can initiate
connectivity checks to the client.
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 26 skipping to change at page 37, line 47
The Permission Lifetime MUST be 300 seconds (= 5 minutes). The Permission Lifetime MUST be 300 seconds (= 5 minutes).
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
packets on the allocation's relayed address even if the source IP
addresses of the STUN packets do not match the permissions installed,
this configuration knob MUST default to drop the inbound STUN packets
on the allocation's relayed address if the source IP addresses of the
STUN packets do not match the permissions installed unless explicitly
configured to do so 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, relaying is not permitted, and the allocation. If no match is found and the received datagram is not a
server silently discards the UDP datagram. If an exact match is STUN packet, relaying is not permitted, and the server silently
found, then the permission check is considered to have succeeded and discards the UDP datagram. If an exact match is found or the
the server continues to process the UDP datagram as specified received datagram is a STUN packet, then the permission check is
elsewhere (Section 11.3). Note that only addresses are compared and considered to have succeeded and the server continues to process the
port numbers are not considered. 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 43, line 28 skipping to change at page 44, line 5
0x4000 through 0x4FFF: These values are the allowed channel 0x4000 through 0x4FFF: These values are the allowed channel
numbers (4096 possible values). numbers (4096 possible values).
0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision 0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision
avoidance, see [RFC7983]. avoidance, see [RFC7983].
According to [RFC7983], ChannelData messages can be distinguished According to [RFC7983], ChannelData messages can be distinguished
from other multiplexed protocols by examining the first byte of the from other multiplexed protocols by examining the first byte of the
message: message:
[0..3] STUN +------------+------------------------------+
| [0..3] | STUN |
[16..19] ZRTP | | |
+-------------------------------------------+
[20..63] DTLS | [16..19] | ZRTP |
| | |
[64..79] TURN Channel +-------------------------------------------+
| [20..63] | DTLS |
[128..191] RTP/RTCP | | |
+-------------------------------------------+
others Reserved, MUST be dropped and an alert MAY be logged | [64..79] | TURN Channel |
| | |
+-------------------------------------------+
| [128..191] | RTP/RTCP |
| | |
+-------------------------------------------+
| Others | Reserved, MUST be dropped |
| | and an alert MAY be logged |
+-------------------------------------------+
Reserved values may be used in the future by other protocols. When Reserved values may be used in the future by other protocols. When
the client uses channel binding, it MUST comply with the the client uses channel binding, it MUST comply with the
demultiplexing scheme discussed above. demultiplexing scheme discussed above.
Channel bindings are always initiated by the client. The client can Channel bindings are always initiated by the client. The client can
bind a channel to a peer at any time during the lifetime of the bind a channel to a peer at any time during the lifetime of the
allocation. The client may bind a channel to a peer before allocation. The client may bind a channel to a peer before
exchanging data with it, or after exchanging data with it (using Send exchanging data with it, or after exchanging data with it (using Send
and Data indications) for some time, or may choose never to bind a and Data indications) for some time, or may choose never to bind a
skipping to change at page 45, line 35 skipping to change at page 46, line 17
12.2. Receiving a ChannelBind Request 12.2. Receiving a ChannelBind Request
When the server receives a ChannelBind request, it processes as per When the server receives a ChannelBind request, it processes as per
Section 5 plus the specific rules mentioned here. Section 5 plus the specific rules mentioned here.
The server checks the following: The server checks the following:
o The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS o The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS
attribute; attribute;
o The channel number is in the range 0x4000 through 0x7FFE o The channel number is in the range 0x4000 through 0x4FFF
(inclusive); (inclusive);
o The channel number is not currently bound to a different transport o The channel number is not currently bound to a different transport
address (same transport address is OK); address (same transport address is OK);
o The transport address is not currently bound to a different o The transport address is not currently bound to a different
channel number. channel number.
o If the XOR-PEER-ADDRESS attribute contains an address of an o If the XOR-PEER-ADDRESS attribute contains an address of an
address family that is not the same as that of a relayed transport address family that is not the same as that of a relayed transport
skipping to change at page 48, line 10 skipping to change at page 48, line 40
field of the ChannelData message, so the actual size of a ChannelData field of the ChannelData message, so the actual size of a ChannelData
message (including padding) is (4 + Length) rounded up to the nearest message (including padding) is (4 + Length) rounded up to the nearest
multiple of 4. Over UDP, the padding is not required but MAY be multiple of 4. Over UDP, the padding is not required but MAY be
included. included.
The ChannelData message is then sent on the 5-tuple associated with The ChannelData message is then sent on the 5-tuple associated with
the allocation. the allocation.
12.6. Receiving a ChannelData Message 12.6. Receiving a ChannelData Message
The receiver of the ChannelData message uses the first two bits to The receiver of the ChannelData message uses the first byte to
distinguish it from STUN-formatted messages, as described above. If distinguish it from other multiplexed protocols, as described above.
the message uses a value in the reserved range (0x8000 through If the message uses a value in the reserved range (0x5000 through
0xFFFF), then the message is silently discarded. 0xFFFF), then the message is silently discarded.
If the ChannelData message is received in a UDP datagram, and if the If the ChannelData message is received in a UDP datagram, and if the
UDP datagram is too short to contain the claimed length of the UDP datagram is too short to contain the claimed length of the
ChannelData message (i.e., the UDP header length field value is less ChannelData message (i.e., the UDP header length field value is less
than the ChannelData header length field value + 4 + 8), then the than the ChannelData header length field value + 4 + 8), then the
message is silently discarded. message is silently discarded.
If the ChannelData message is received over TCP or over TLS-over-TCP, If the ChannelData message is received over TCP or over TLS-over-TCP,
then the actual length of the ChannelData message is as described in then the actual length of the ChannelData message is as described in
skipping to change at page 72, line 28 skipping to change at page 72, line 28
client, unless the client has tried to contact the attacker first. client, unless the client has tried to contact the attacker first.
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
the allocation's relayed address even if the source IP addresses of
the STUN packets does not match the permissions installed, in order
to prevent an attacker from flooding the TURN client with STUN-like
packets, the TURN server can look for STUN attributes USERNAME and
MESSAGE-INTEGRITY in the STUN message to only allow STUN connectivity
check packet. A TURN server MUST have a security policy for inbound
STUN packets from IP addresses not matching the permissions
installed, the policy can be configured to only allow STUN packets
not exceeding a specific packet size, maximum number of STUN packets
allowed in a TURN session, rate-limit the number of STUN packets
allowed per second, restrict the maximum number of IP addresses
allowed to send STUN packets that do not match the permissions
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 76, line 28 skipping to change at page 76, line 36
IANA has allocated the SRV service name of "turn" for TURN over UDP IANA has allocated the SRV service name of "turn" for TURN over UDP
or TCP, and the service name of "turns" for TURN over (D)TLS. or TCP, and the service name of "turns" for TURN over (D)TLS.
IANA has created a registry for TURN channel numbers, initially IANA has created a registry for TURN channel numbers, initially
populated as follows: populated as follows:
o 0x0000 through 0x3FFF: Reserved and not available for use, since o 0x0000 through 0x3FFF: Reserved and not available for use, since
they conflict with the STUN header. they conflict with the STUN header.
o 0x4000 through 0x7FFF: A TURN implementation is free to use o 0x4000 through 0x4FFF: A TURN implementation is free to use
channel numbers in this range. channel numbers in this range.
o 0x8000 through 0xFFFF: Unassigned. o 0x5000 through 0xFFFF: Unassigned.
Any change to this registry must be made through an IETF Standards Any change to this registry must be made through an IETF Standards
Action. Action.
21. IAB Considerations 21. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing" The IAB has studied the problem of "Unilateral Self Address Fixing"
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol-reflection mechanism [RFC3424]. The through a collaborative protocol-reflection mechanism [RFC3424]. The
skipping to change at page 78, line 43 skipping to change at page 78, line 51
specification, [RFC5766]. The authors would like to thank Rohan Mahy specification, [RFC5766]. The authors would like to thank Rohan Mahy
co-author of original TURN specification and everyone who had co-author of original TURN specification and everyone who had
contributed to that document. The authors would also like to contributed to that document. The authors would also like to
acknowledge that this document inherits material from [RFC6156]. acknowledge that this document inherits material from [RFC6156].
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, Jonathan Lennox, like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox,
Brandon Williams, Karl Stahl, Noriyuki Torii and Oleg Moskalenko for Brandon Williams, Karl Stahl, Noriyuki Torii and Oleg Moskalenko for
comments and review. The authors would like to thank Marc for his comments and review. The authors would like to thank Marc for his
contributions to the text. contributions to the text. Thanks to Eric Rescorla for proposing the
update to allow the TURN server to forward inbound STUN connectivity
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-16
(work in progress), March 2018. (work in progress), March 2018.
 End of changes. 31 change blocks. 
63 lines changed or deleted 104 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/