draft-ietf-tram-turnbis-20.txt   draft-ietf-tram-turnbis-21.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: April 14, 2019 P. Matthews Expires: August 22, 2019 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
October 11, 2018 February 18, 2019
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-20 draft-ietf-tram-turnbis-21
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 April 14, 2019. This Internet-Draft will expire on August 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 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 . . . . . . . . . . . . . . . . 17 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . 33 7.4. Receiving an Allocate Error Response . . . . . . . . . . 32
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 35 8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34
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 . . . . . . . . . . . . . . . 35
8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 36
9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38 10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a CreatePermission Request . . . . . . . . . . . 39 10.1. Forming a CreatePermission Request . . . . . . . . . . . 38
10.2. Receiving a CreatePermission Request . . . . . . . . . . 39 10.2. Receiving a CreatePermission Request . . . . . . . . . . 38
10.3. Receiving a CreatePermission Response . . . . . . . . . 40 10.3. Receiving a CreatePermission Response . . . . . . . . . 39
11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 40 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 39
11.1. Forming a Send Indication . . . . . . . . . . . . . . . 40 11.1. Forming a Send Indication . . . . . . . . . . . . . . . 39
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 . . . . . . . . . . . . . . . . 40
11.4. Receiving a Data Indication . . . . . . . . . . . . . . 42 11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41
11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 42 11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41
11.6. Receiving a Data Indication with an ICMP attribute . . . 43 11.6. Receiving a Data Indication with an ICMP attribute . . . 42
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 . . . . . . . . . . . . 45
12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 46
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 . . . . . . . . . . . . . 47
12.6. Receiving a ChannelData Message . . . . . . . . . . . . 49 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48
12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 50 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49
13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 50 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 49
13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 50 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 49
13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 51 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 50
13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 53 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52
14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 53 14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 52
15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 55 15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 54
16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 55 16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 54
16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 56 16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55
16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 56 16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 55
16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 56 16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 55
16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 56 16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 55
16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 57 16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56
16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 57 16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56
16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 57 16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56
16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 58 16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57
16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 58 16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 57
16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 58 16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 57
16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 58 16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57
16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 59 16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58
16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 59 16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58
17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 60 17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59
18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 61 18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60
19. Security Considerations . . . . . . . . . . . . . . . . . . . 69 19. Security Considerations . . . . . . . . . . . . . . . . . . . 68
19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 69 19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68
19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 69 19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68
19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 69 19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68
19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 70 19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69
19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 70 19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69
19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 71 19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70
19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 71 19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70
19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 72 19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 71
19.2. Firewall Considerations . . . . . . . . . . . . . . . . 72 19.2. Firewall Considerations . . . . . . . . . . . . . . . . 71
19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 73 19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 72
19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 74 19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 72
19.2.3. Running Servers on Well-Known Ports . . . . . . . . 74 19.2.3. Running Servers on Well-Known Ports . . . . . . . . 73
19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 74 19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73
19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 74 19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 73
19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 75 19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 73
19.3.3. Manipulating Other Allocations . . . . . . . . . . . 75 19.3.3. Manipulating Other Allocations . . . . . . . . . . . 74
19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 75 19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 74
19.5. Other Considerations . . . . . . . . . . . . . . . . . . 76 19.5. Other Considerations . . . . . . . . . . . . . . . . . . 75
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 77 21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 76
22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 79 22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 78
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 79 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
24.1. Normative References . . . . . . . . . . . . . . . . . . 80 24.1. Normative References . . . . . . . . . . . . . . . . . . 79
24.2. Informative References . . . . . . . . . . . . . . . . . 81 24.2. Informative References . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 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
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 5, line 16 skipping to change at page 5, line 16
A client using TURN must have some way to communicate the relayed A client using TURN must have some way to communicate the relayed
transport address to its peers, and to learn each peer's IP address transport address to its peers, and to learn each peer's IP address
and port (more precisely, each peer's server-reflexive transport and port (more precisely, each peer's server-reflexive transport
address, see Section 2). How this is done is out of the scope of the address, see Section 2). How this is done is out of the scope of the
TURN protocol. One way this might be done is for the client and TURN protocol. One way this might be done is for the client and
peers to exchange email messages. Another way is for the client and peers to exchange email messages. Another way is for the client and
its peers to use a special-purpose "introduction" or "rendezvous" its peers to use a special-purpose "introduction" or "rendezvous"
protocol (see [RFC5128] for more details). protocol (see [RFC5128] for more details).
If TURN is used with ICE [RFC5245], then the relayed transport If TURN is used with ICE [RFC8445], then the relayed transport
address and the IP addresses and ports of the peers are included in address and the IP addresses and ports of the peers are included in
the ICE candidate information that the rendezvous protocol must the ICE candidate information that the rendezvous protocol must
carry. For example, if TURN and ICE are used as part of a multimedia carry. For example, if TURN and ICE are used as part of a multimedia
solution using SIP [RFC3261], then SIP serves the role of the solution using SIP [RFC3261], then SIP serves the role of the
rendezvous protocol, carrying the ICE candidate information inside rendezvous protocol, carrying the ICE candidate information inside
the body of SIP messages. If TURN and ICE are used with some other the body of SIP messages. If TURN and ICE are used with some other
rendezvous protocol, then [I-D.rosenberg-mmusic-ice-nonsip] provides rendezvous protocol, then [I-D.rosenberg-mmusic-ice-nonsip] provides
guidance on the services the rendezvous protocol must perform. guidance on the services the rendezvous protocol must perform.
Though the use of a TURN server to enable communication between two Though the use of a TURN server to enable communication between two
skipping to change at page 11, line 48 skipping to change at page 11, line 48
2.3. Permissions 2.3. Permissions
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, there are UDP datagram on the allocation's relayed transport address, it first
two conditions that cause it to forward that packet: permissions or checks the list of permissions. If the source IP address of the
TURN server configuration. It first checks the list of permissions. datagram matches a permission, the application data is relayed to the
If the source IP address of the datagram matches a permission, the client, otherwise the UDP datagram is silently discarded.
application data is relayed to the client, otherwise the UDP datagram
is silently discarded. Second, 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, addressing
the race condition that exists when the remote peer sends
connectivity checks before the client has had a chance to create
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 18, line 49 skipping to change at page 18, line 28
request that the server allocate a relayed transport address with an request that the server allocate a relayed transport address with an
even port number, and to optionally request the server reserve the even port number, and to optionally request the server reserve the
next-highest port number for a subsequent allocation. next-highest port number for a subsequent allocation.
2.9. Happy Eyeballs for TURN 2.9. Happy Eyeballs for TURN
If an IPv4 path to reach a TURN server is found, but the TURN If an IPv4 path to reach a TURN server is found, but the TURN
server's IPv6 path is not working, a dual-stack TURN client can server's IPv6 path is not working, a dual-stack TURN client can
experience a significant connection delay compared to an IPv4-only experience a significant connection delay compared to an IPv4-only
TURN client. To overcome these connection setup problems, the TURN TURN client. To overcome these connection setup problems, the TURN
client MUST query both A and AAAA records for the TURN server client needs to query both A and AAAA records for the TURN server
specified using a domain name and try connecting to the TURN server specified using a domain name and try connecting to the TURN server
using both IPv6 and IPv4 addresses in a fashion similar to the Happy using both IPv6 and IPv4 addresses in a fashion similar to the Happy
Eyeballs mechanism defined in [RFC8305]. The TURN client performs Eyeballs mechanism defined in [RFC8305]. The TURN client performs
the following steps based on the transport protocol being used to the following steps based on the transport protocol being used to
connect to the TURN server. connect to the TURN server.
o For TCP or TLS-over-TCP, initiate TCP connection to both IP o For TCP or TLS-over-TCP, initiate TCP connection to both IP
address families as discussed in [RFC8305], and use the first TCP address families as discussed in [RFC8305], and use the first TCP
connection that is established. If connections are established on connection that is established. If connections are established on
both IP address families then terminate the TCP connection using both IP address families then terminate the TCP connection using
skipping to change at page 37, line 47 skipping to change at page 37, line 26
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 otherwise. The default configuration to drop
inbound packets not matching the permissions installed resembles
firewall default behavior to block unsolicited inbound traffic.
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. Note that only addresses are compared and port numbers allocation. Note that only addresses are compared and port numbers
are not considered. If no match is found and the received datagram are not considered. If no match is found, relaying is not permitted,
is not a STUN packet, the permission check is considered to have and the server silently discards the UDP datagram. If an exact match
failed. If an exact match is found, the permission check is is found, the permission check is considered to have succeeded and
considered to have succeeded. If no match is found and the received the server continues to process the UDP datagram as specified
datagram is a STUN packet and the server is configured to allow STUN elsewhere (Section 11.3).
packets without explicit permission, the permission check is
considered to have succeeded. If no match is found and the received
datagram is a STUN packet and the server is not configured to allow
STUN packets without explicit permission, the permission check is
considered to have failed. 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).
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
guidelines of ICE [RFC5245], and applications not using ICE are guidelines of ICE [RFC8445], and applications not using ICE are
advised to do something similar. advised to do something similar.
10. CreatePermission 10. CreatePermission
TURN supports two ways for the client to install or refresh TURN supports two ways for the client to install or refresh
permissions on the server. This section describes one way: the permissions on the server. This section describes one way: the
CreatePermission request. CreatePermission request.
A CreatePermission request may be used in conjunction with either the A CreatePermission request may be used in conjunction with either the
Send mechanism in Section 11 or the Channel mechanism in Section 12. Send mechanism in Section 11 or the Channel mechanism in Section 12.
skipping to change at page 73, 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 do not match the permissions installed, the TURN
server MUST have a security policy for inbound STUN packets from IP
addresses not matching the permissions installed in order to prevent
an attacker from flooding the TURN client with STUN-like packets.
The TURN server can limit forwarding to well-formed STUN connectivity
check packets by looking for the STUN attributes USERNAME and
MESSAGE-INTEGRITY and verifying that the message does not exceed a
specific configurable packet size. Additionally, the TURN server
policy can be configured with maximum rate-limits for the number of
STUN packets allowed in a TURN session, STUN packets allowed per
second, and IP addresses allowed to send STUN packets.
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 78, line 49 skipping to change at page 77, line 41
lifetime of the allocation. This is typically done using keep- lifetime of the allocation. This is typically done using keep-
alives. If this is not done, then the client will lose its alives. If this is not done, then the client will lose its
allocation and can no longer exchange data with its peers. allocation and can no longer exchange data with its peers.
Consideration 4: Identify requirements for longer-term, sound Consideration 4: Identify requirements for longer-term, sound
technical solutions; contribute to the process of finding the right technical solutions; contribute to the process of finding the right
longer-term solution. longer-term solution.
Response: The need for TURN will be reduced once NATs implement the Response: The need for TURN will be reduced once NATs implement the
recommendations for NAT UDP behavior documented in [RFC4787]. recommendations for NAT UDP behavior documented in [RFC4787].
Applications are also strongly urged to use ICE [RFC5245] to Applications are also strongly urged to use ICE [RFC8445] to
communicate with peers; though ICE uses TURN, it does so only as a communicate with peers; though ICE uses TURN, it does so only as a
last resort, and uses it in a controlled manner. last resort, and uses it in a controlled manner.
Consideration 5: Discussion of the impact of the noted practical Consideration 5: Discussion of the impact of the noted practical
issues with existing deployed NATs and experience reports. issues with existing deployed NATs and experience reports.
Response: Some NATs deployed today exhibit a mapping behavior other Response: Some NATs deployed today exhibit a mapping behavior other
than Endpoint-Independent mapping. These NATs are difficult to work than Endpoint-Independent mapping. These NATs are difficult to work
with, as they make it difficult or impossible for protocols like ICE with, as they make it difficult or impossible for protocols like ICE
to use server-reflexive transport addresses on those NATs. A client to use server-reflexive transport addresses on those NATs. A client
skipping to change at page 79, line 52 skipping to change at page 78, line 44
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 the ADDITIONAL-ADDRESS-FAMILY and Simon Perreault for their help on the ADDITIONAL-ADDRESS-FAMILY
mechanism. Authors would like to thank Gonzalo Salgueiro, Simon mechanism. Authors would like to thank Gonzalo Salgueiro, Simon
Perreault, Jonathan Lennox, Brandon Williams, Karl Stahl, Noriyuki Perreault, Jonathan Lennox, Brandon Williams, Karl Stahl, Noriyuki
Torii, Nils Ohlmeier, Dan Wing, Justin Uberti and Oleg Moskalenko for Torii, Nils Ohlmeier, Dan Wing, Justin Uberti 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. Thanks to Eric Rescorla for proposing the contributions to the text.
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-18 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-19
(work in progress), May 2018. (work in progress), October 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 83, line 32 skipping to change at page 82, line 27
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <https://www.rfc-editor.org/info/rfc5128>. 2008, <https://www.rfc-editor.org/info/rfc5128>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
[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,
<https://www.rfc-editor.org/info/rfc5766>. <https://www.rfc-editor.org/info/rfc5766>.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Resolution Mechanism", RFC 5928, (TURN) Resolution Mechanism", RFC 5928,
DOI 10.17487/RFC5928, August 2010, DOI 10.17487/RFC5928, August 2010,
<https://www.rfc-editor.org/info/rfc5928>. <https://www.rfc-editor.org/info/rfc5928>.
skipping to change at page 84, line 32 skipping to change at page 83, line 22
Updates for Secure Real-time Transport Protocol (SRTP) Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)", Extension for Datagram Transport Layer Security (DTLS)",
RFC 7983, DOI 10.17487/RFC7983, September 2016, RFC 7983, DOI 10.17487/RFC7983, September 2016,
<https://www.rfc-editor.org/info/rfc7983>. <https://www.rfc-editor.org/info/rfc7983>.
[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays
around NAT (TURN) Server Auto Discovery", RFC 8155, around NAT (TURN) Server Auto Discovery", RFC 8155,
DOI 10.17487/RFC8155, April 2017, DOI 10.17487/RFC8155, April 2017,
<https://www.rfc-editor.org/info/rfc8155>. <https://www.rfc-editor.org/info/rfc8155>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
 End of changes. 25 change blocks. 
140 lines changed or deleted 96 lines changed or added

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