draft-ietf-tram-turnbis-23.txt   draft-ietf-tram-turnbis-24.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 Villanova University Intended status: Standards Track Villanova University
Expires: September 1, 2019 P. Matthews Expires: October 27, 2019 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
February 28, 2019 April 25, 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-23 draft-ietf-tram-turnbis-24
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 1, 2019. This Internet-Draft will expire on October 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 13
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 17
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 17 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 17
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 19
2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18 2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 19
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 20
4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 21 4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 22
4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 21 4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 22
5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21 5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 22
6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25 7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 26
7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25 7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 26
7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27 7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 28
7.3. Receiving an Allocate Success Response . . . . . . . . . 32 7.3. Receiving an Allocate Success Response . . . . . . . . . 33
7.4. Receiving an Allocate Error Response . . . . . . . . . . 33 7.4. Receiving an Allocate Error Response . . . . . . . . . . 34
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 35 8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 36
8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35 8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 36
8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 36 8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 37
8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 38
9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 38
10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38 10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Forming a CreatePermission Request . . . . . . . . . . . 38 10.1. Forming a CreatePermission Request . . . . . . . . . . . 39
10.2. Receiving a CreatePermission Request . . . . . . . . . . 39 10.2. Receiving a CreatePermission Request . . . . . . . . . . 40
10.3. Receiving a CreatePermission Response . . . . . . . . . 39 10.3. Receiving a CreatePermission Response . . . . . . . . . 40
11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 39 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 41
11.1. Forming a Send Indication . . . . . . . . . . . . . . . 40 11.1. Forming a Send Indication . . . . . . . . . . . . . . . 41
11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40 11.2. Receiving a Send Indication . . . . . . . . . . . . . . 41
11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 41 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 42
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 . . . . . . . . . . . . . . . . 43
11.6. Receiving a Data Indication with an ICMP attribute . . . 43 11.6. Receiving a Data Indication with an ICMP attribute . . . 44
12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45 12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 46
12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 46 12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 47
12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 48
12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47 12.4. The ChannelData Message . . . . . . . . . . . . . . . . 48
12.5. Sending a ChannelData Message . . . . . . . . . . . . . 48 12.5. Sending a ChannelData Message . . . . . . . . . . . . . 49
12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 49
12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 50
13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 50 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 51
13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 50 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 51
13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 51 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 52
13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 53
14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 53 14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 54
15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 55 15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 56
16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 55 16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 56
16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55 16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 57
16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 56 16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 57
16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 56 16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 57
16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 56 16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 57
16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56 16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 57
16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56 16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 58
16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 57 16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 58
16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57 16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 59
16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 58 16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 59
16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 58 16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 59
16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 58 16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 59
16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58 16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 60
16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 59 16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 60
17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59 17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 61
18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60 18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 62
19. Security Considerations . . . . . . . . . . . . . . . . . . . 68 19. Security Considerations . . . . . . . . . . . . . . . . . . . 70
19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68 19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 70
19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68 19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 70
19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68 19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 70
19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69 19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 71
19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69 19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 71
19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70 19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 72
19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70 19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 72
19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 71 19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 73
19.2. Firewall Considerations . . . . . . . . . . . . . . . . 71 19.2. Firewall Considerations . . . . . . . . . . . . . . . . 73
19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 72 19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 74
19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 72 19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 74
19.2.3. Running Servers on Well-Known Ports . . . . . . . . 73 19.2.3. Running Servers on Well-Known Ports . . . . . . . . 75
19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73 19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 75
19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 73 19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 75
19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 73 19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 75
19.3.3. Manipulating Other Allocations . . . . . . . . . . . 74 19.3.3. Manipulating Other Allocations . . . . . . . . . . . 76
19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 74 19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 76
19.5. Other Considerations . . . . . . . . . . . . . . . . . . 75 19.5. Other Considerations . . . . . . . . . . . . . . . . . . 77
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 76 21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 78
22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 78 22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 80
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
24.1. Normative References . . . . . . . . . . . . . . . . . . 79 24.1. Normative References . . . . . . . . . . . . . . . . . . 81
24.2. Informative References . . . . . . . . . . . . . . . . . 80 24.2. Informative References . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
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 4, line 49 skipping to change at page 4, line 49
packets. This relay typically sits in the public Internet and relays packets. This relay typically sits in the public Internet and relays
packets between two hosts that both sit behind NATs. packets between two hosts that both sit behind NATs.
This specification defines a protocol, called TURN, that allows a This specification defines a protocol, called TURN, that allows a
host behind a NAT (called the TURN client) to request that another host behind a NAT (called the TURN client) to request that another
host (called the TURN server) act as a relay. The client can arrange host (called the TURN server) act as a relay. The client can arrange
for the server to relay packets to and from certain other hosts for the server to relay packets to and from certain other hosts
(called peers) and can control aspects of how the relaying is done. (called peers) and can control aspects of how the relaying is done.
The client does this by obtaining an IP address and port on the The client does this by obtaining an IP address and port on the
server, called the relayed transport address. When a peer sends a server, called the relayed transport address. When a peer sends a
packet to the relayed transport address, the server relays the packet packet to the relayed transport address, the server relays the
to the client. When the client sends a data packet to the server, transport protocol data from the packet to the client. The client
the server relays it to the appropriate peer using the relayed knows the peer from which the transport protocol data was relayed by
transport address as the source. the server. If the server receives an ICMP error packet, the server
also relays certain layer 3/4 header fields from the ICMP header to
the client. When the client sends a packet to the server, the server
relays the transport protocol data from the packet to the appropriate
peer using the relayed transport address as the source.
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).
skipping to change at page 9, line 49 skipping to change at page 9, line 49
rules. Also, TCP has explicit connection teardown; while for UDP, rules. Also, TCP has explicit connection teardown; while for UDP,
the firewall has to use timers to guess when the flow is finished. the firewall has to use timers to guess when the flow is finished.
TURN supports TLS-over-TCP transport and DTLS-over-UDP transport TURN supports TLS-over-TCP transport and DTLS-over-UDP transport
between the client and the server because (D)TLS provides additional between the client and the server because (D)TLS provides additional
security properties not provided by TURN's default digest security properties not provided by TURN's default digest
authentication; properties that some clients may wish to take authentication; properties that some clients may wish to take
advantage of. In particular, (D)TLS provides a way for the client to advantage of. In particular, (D)TLS provides a way for the client to
ascertain that it is talking to the correct server, and provides for ascertain that it is talking to the correct server, and provides for
confidentiality of TURN control messages. If (D)TLS transport is confidentiality of TURN control messages. If (D)TLS transport is
used between the TURN client and the TURN server, the guidance given used between the TURN client and the TURN server, the cipher suites
in [RFC7525] MUST be followed to avoid attacks on (D)TLS. TURN does discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis] and the
not require (D)TLS because the overhead of using (D)TLS is higher guidance given in [RFC7525] MUST be followed to avoid attacks on
than that of digest authentication; for example, using (D)TLS likely (D)TLS. TURN does not require (D)TLS because the overhead of using
means that most application data will be doubly encrypted (once by (D)TLS is higher than that of digest authentication; for example,
(D)TLS and once to ensure it is still encrypted in the UDP datagram). using (D)TLS likely means that most application data will be doubly
encrypted (once by (D)TLS and once to ensure it is still encrypted in
the UDP datagram).
There is an extension to TURN for TCP transport between the server There is an extension to TURN for TCP transport between the server
and the peers [RFC6062]. For this reason, allocations that use UDP and the peers [RFC6062]. For this reason, allocations that use UDP
between the server and the peers are known as UDP allocations, while between the server and the peers are known as UDP allocations, while
allocations that use TCP between the server and the peers are known allocations that use TCP between the server and the peers are known
as TCP allocations. This specification describes only UDP as TCP allocations. This specification describes only UDP
allocations. allocations.
In some applications for TURN, the client may send and receive In some applications for TURN, the client may send and receive
packets other than TURN packets on the host transport address it uses packets other than TURN packets on the host transport address it uses
skipping to change at page 17, line 18 skipping to change at page 17, line 45
Future work may specify alternate TURN semantics that address these Future work may specify alternate TURN semantics that address these
limitations. limitations.
2.7. Avoiding IP Fragmentation 2.7. Avoiding IP Fragmentation
For reasons described in [Frag-Harmful], applications, especially For reasons described in [Frag-Harmful], applications, especially
those sending large volumes of data, should try hard to avoid having those sending large volumes of data, should try hard to avoid having
their packets fragmented. Applications using TCP can more or less their packets fragmented. Applications using TCP can more or less
ignore this issue because fragmentation avoidance is now a standard ignore this issue because fragmentation avoidance is now a standard
part of TCP, but applications using UDP (and thus any application part of TCP, but applications using UDP (and thus any application
using this version of TURN) must handle fragmentation avoidance using this version of TURN) need to handle fragmentation avoidance
themselves. themselves.
The application running on the client and the peer can take one of The application running on the client and the peer can take one of
two approaches to avoid IP fragmentation. two approaches to avoid IP fragmentation.
The first approach is to avoid sending large amounts of application The first approach is to avoid sending large amounts of application
data in the TURN messages/UDP datagrams exchanged between the client data in the TURN messages/UDP datagrams exchanged between the client
and the peer. This is the approach taken by most VoIP (Voice-over- and the peer. This is the approach taken by most VoIP (Voice-over-
IP) applications. In this approach, the application exploits the IP) applications. In this approach, the application MUST assume a
fact that the IP specification [RFC0791] specifies that IP packets up PMTU of 1280 bytes, as IPv6 requires that every link in the Internet
to 576 bytes should never need to be fragmented. have an MTU of 1280 octets or greater as specified in [RFC8200]. If
IPv4 support on legacy or otherwise unusual networks is a
consideration, the application MAY assume on a PMTU of 576 bytes for
IPv4 datagrams, as every IPv4 host must be capable of receiving a
packet whose length is equal to 576 bytes as discussed in [RFC0791].
The exact amount of application data that can be included while The exact amount of application data that can be included while
avoiding fragmentation depends on the details of the TURN session avoiding fragmentation depends on the details of the TURN session
between the client and the server: whether UDP, TCP, or (D)TLS between the client and the server: whether UDP, TCP, or (D)TLS
transport is used, whether ChannelData messages or Send/Data transport is used, whether ChannelData messages or Send/Data
indications are used, and whether any additional attributes (such as indications are used, and whether any additional attributes (such as
the DONT-FRAGMENT attribute) are included. Another factor, which is the DONT-FRAGMENT attribute) are included. Another factor, which is
hard to determine, is whether the MTU is reduced somewhere along the hard to determine, is whether the MTU is reduced somewhere along the
path for other reasons, such as the use of IP-in-IP tunneling. path for other reasons, such as the use of IP-in-IP tunneling.
skipping to change at page 18, line 26 skipping to change at page 19, line 8
[I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that
uses STUN to discover the path MTU, and so might be a suitable uses STUN to discover the path MTU, and so might be a suitable
approach to be used in conjunction with a TURN server that supports approach to be used in conjunction with a TURN server that supports
the DONT-FRAGMENT attribute. When the client includes the DONT- the DONT-FRAGMENT attribute. When the client includes the DONT-
FRAGMENT attribute in a Send indication, this tells the server to set FRAGMENT attribute in a Send indication, this tells the server to set
the DF bit in the resulting UDP datagram that it sends to the peer. the DF bit in the resulting UDP datagram that it sends to the peer.
Since some servers may be unable to set the DF bit, the client should Since some servers may be unable to set the DF bit, the client should
also include this attribute in the Allocate request -- any server also include this attribute in the Allocate request -- any server
that does not support the DONT-FRAGMENT attribute will indicate this that does not support the DONT-FRAGMENT attribute will indicate this
by rejecting the Allocate request. by rejecting the Allocate request. If the TURN server carrying out
packet translation from IPv4-to-IPv6 cannot get the Don't Fragment
(DF) bit in the IPv4 header, it MUST reject the Allocate request with
DONT-FRAGMENT attribute.
2.8. RTP Support 2.8. RTP Support
One of the envisioned uses of TURN is as a relay for clients and One of the envisioned uses of TURN is as a relay for clients and
peers wishing to exchange real-time data (e.g., voice or video) using peers wishing to exchange real-time data (e.g., voice or video) using
RTP. To facilitate the use of TURN for this purpose, TURN includes RTP. To facilitate the use of TURN for this purpose, TURN includes
some special support for older versions of RTP. some special support for older versions of RTP.
Old versions of RTP [RFC3550] required that the RTP stream be on an Old versions of RTP [RFC3550] required that the RTP stream be on an
even port number and the associated RTP Control Protocol (RTCP) even port number and the associated RTP Control Protocol (RTCP)
skipping to change at page 20, line 25 skipping to change at page 21, line 10
peer(s). The peer does not interact with the TURN server using peer(s). The peer does not interact with the TURN server using
the protocol defined in this document; rather, the peer receives the protocol defined in this document; rather, the peer receives
data sent by the TURN server and the peer sends data towards the data sent by the TURN server and the peer sends data towards the
TURN server. TURN server.
Transport Address: The combination of an IP address and a port. Transport Address: The combination of an IP address and a port.
Host Transport Address: A transport address on a client or a peer. Host Transport Address: A transport address on a client or a peer.
Server-Reflexive Transport Address: A transport address on the Server-Reflexive Transport Address: A transport address on the
"public side" of a NAT. This address is allocated by the NAT to "external side" of a NAT. This address is allocated by the NAT to
correspond to a specific host transport address. correspond to a specific host transport address.
Relayed Transport Address: A transport address on the TURN server Relayed Transport Address: A transport address on the TURN server
that is used for relaying packets between the client and a peer. that is used for relaying packets between the client and a peer.
A peer sends to this address on the TURN server, and the packet is A peer sends to this address on the TURN server, and the packet is
then relayed to the client. then relayed to the client.
TURN Server Transport Address: A transport address on the TURN TURN Server Transport Address: A transport address on the TURN
server that is used for sending TURN messages to the server. This server that is used for sending TURN messages to the server. This
is the transport address that the client uses to communicate with is the transport address that the client uses to communicate with
skipping to change at page 20, line 48 skipping to change at page 21, line 33
Peer Transport Address: The transport address of the peer as seen by Peer Transport Address: The transport address of the peer as seen by
the server. When the peer is behind a NAT, this is the peer's the server. When the peer is behind a NAT, this is the peer's
server-reflexive transport address. server-reflexive transport address.
Allocation: The relayed transport address granted to a client Allocation: The relayed transport address granted to a client
through an Allocate request, along with related state, such as through an Allocate request, along with related state, such as
permissions and expiration timers. permissions and expiration timers.
5-tuple: The combination (client IP address and port, server IP 5-tuple: The combination (client IP address and port, server IP
address and port, and transport protocol (currently one of UDP, address and port, and transport protocol (currently one of UDP,
TCP, or (D)TLS)) used to communicate between the client and the TCP, DTLS/UDP or TLS/TCP) used to communicate between the client
server. The 5-tuple uniquely identifies this communication and the server. The 5-tuple uniquely identifies this
stream. The 5-tuple also uniquely identifies the Allocation on communication stream. The 5-tuple also uniquely identifies the
the server. Allocation on the server.
Transport Protocol: The protocols above IP that carries TURN
Requests, Responses, and Indications as well as providing
identifiable flows using a 5-tuple. In this specification, UDP
and TCP are defined as transport protocols, as well as their
combination with a security layer using DTLS and TLS respectively.
Channel: A channel number and associated peer transport address. Channel: A channel number and associated peer transport address.
Once a channel number is bound to a peer's transport address, the Once a channel number is bound to a peer's transport address, the
client and server can use the more bandwidth-efficient ChannelData client and server can use the more bandwidth-efficient ChannelData
message to exchange data. message to exchange data.
Permission: The IP address and transport protocol (but not the port) Permission: The IP address and transport protocol (but not the port)
of a peer that is permitted to send traffic to the TURN server and of a peer that is permitted to send traffic to the TURN server and
have that traffic relayed to the TURN client. The TURN server have that traffic relayed to the TURN client. The TURN server
will only forward traffic to its client from peers that match an will only forward traffic to its client from peers that match an
skipping to change at page 21, line 32 skipping to change at page 22, line 23
change the nonce regularly. change the nonce regularly.
(D)TLS: This term is used for statements that apply to both (D)TLS: This term is used for statements that apply to both
Transport Layer Security [RFC8446] and Datagram Transport Layer Transport Layer Security [RFC8446] and Datagram Transport Layer
Security [RFC6347]. Security [RFC6347].
4. Discovery of TURN server 4. Discovery of TURN server
Methods of TURN server discovery, including using anycast, are Methods of TURN server discovery, including using anycast, are
described in [RFC8155]. The syntax of the "turn" and "turns" URIs described in [RFC8155]. The syntax of the "turn" and "turns" URIs
are defined in Section 3.1 of [RFC7065]. are defined in Section 3.1 of [RFC7065]. DTLS as a transport
protocol for TURN is defined in [RFC7350].
4.1. TURN URI Scheme Semantics 4.1. TURN URI Scheme Semantics
The "turn" and "turns" URI schemes are used to designate a TURN The "turn" and "turns" URI schemes are used to designate a TURN
server (also known as a relay) on Internet hosts accessible using the server (also known as a relay) on Internet hosts accessible using the
TURN protocol. The TURN protocol supports sending messages over UDP, TURN protocol. The TURN protocol supports sending messages over UDP,
TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be
used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the
"turn" scheme MUST be used otherwise. The required <host> part of "turn" scheme MUST be used otherwise. The required <host> part of
the "turn" URI denotes the TURN server host. The <port> part, if the "turn" URI denotes the TURN server host. The <port> part, if
skipping to change at page 22, line 32 skipping to change at page 23, line 25
authenticated, then the server's administrator MUST choose a realm authenticated, then the server's administrator MUST choose a realm
value that will uniquely identify the username and password value that will uniquely identify the username and password
combination that the client must use, even if the client uses combination that the client must use, even if the client uses
multiple servers under different administrations. The server's multiple servers under different administrations. The server's
administrator MAY choose to allocate a unique username to each administrator MAY choose to allocate a unique username to each
client, or MAY choose to allocate the same username to more than one client, or MAY choose to allocate the same username to more than one
client (for example, to all clients from the same department or client (for example, to all clients from the same department or
company). For each Allocate request, the server SHOULD generate a company). For each Allocate request, the server SHOULD generate a
new random nonce when the allocation is first attempted following the new random nonce when the allocation is first attempted following the
randomness recommendations in [RFC4086] and SHOULD expire the nonce randomness recommendations in [RFC4086] and SHOULD expire the nonce
at least once every hour during the lifetime of the allocation. at least once every hour during the lifetime of the allocation. To
indicate that the server supports [I-D.ietf-tram-stunbis], the server
prepends the NONCE attribute value with the "nonce cookie"
(Section 9.2 of [I-D.ietf-tram-stunbis]).
All requests after the initial Allocate must use the same username as All requests after the initial Allocate must use the same username as
that used to create the allocation, to prevent attackers from that used to create the allocation, to prevent attackers from
hijacking the client's allocation. Specifically, if the server hijacking the client's allocation. Specifically, if the server
requires the use of the long-term credential mechanism, and if a non- requires the use of the long-term credential mechanism, and if a non-
Allocate request passes authentication under this mechanism, and if Allocate request passes authentication under this mechanism, and if
the 5-tuple identifies an existing allocation, but the request does the 5-tuple identifies an existing allocation, but the request does
not use the same username as used to create the allocation, then the not use the same username as used to create the allocation, then the
request MUST be rejected with a 441 (Wrong Credentials) error. request MUST be rejected with a 441 (Wrong Credentials) error.
skipping to change at page 25, line 16 skipping to change at page 26, line 11
across all allocations, so either one can be used to uniquely across all allocations, so either one can be used to uniquely
identify the allocation, and an allocation in this context can be identify the allocation, and an allocation in this context can be
either a single or dual allocation. either a single or dual allocation.
The authentication information (e.g., username, password, realm, and The authentication information (e.g., username, password, realm, and
nonce) is used to both verify subsequent requests and to compute the nonce) is used to both verify subsequent requests and to compute the
message integrity of responses. The username, realm, and nonce message integrity of responses. The username, realm, and nonce
values are initially those used in the authenticated Allocate request values are initially those used in the authenticated Allocate request
that creates the allocation, though the server can change the nonce that creates the allocation, though the server can change the nonce
value during the lifetime of the allocation using a 438 (Stale Nonce) value during the lifetime of the allocation using a 438 (Stale Nonce)
reply. Note that, rather than storing the password explicitly, for reply. For security reasons, the server MUST NOT store the password
security reasons, it may be desirable for the server to store the key explicitly and MUST store the key value, which is a secure hash over
value, which is a secure hash over the username, realm, and password the username, realm, and password (see Section 16.1.3 in
(see [I-D.ietf-tram-stunbis]). [I-D.ietf-tram-stunbis]).
The time-to-expiry is the time in seconds left until the allocation The time-to-expiry is the time in seconds left until the allocation
expires. Each Allocate or Refresh transaction sets this timer, which expires. Each Allocate or Refresh transaction sets this timer, which
then ticks down towards 0. By default, each Allocate or Refresh then ticks down towards 0. By default, each Allocate or Refresh
transaction resets this timer to the default lifetime value of 600 transaction resets this timer to the default lifetime value of 600
seconds (10 minutes), but the client can request a different value in seconds (10 minutes), but the client can request a different value in
the Allocate and Refresh request. Allocations can only be refreshed the Allocate and Refresh request. Allocations can only be refreshed
using the Refresh request; sending data to a peer does not refresh an using the Refresh request; sending data to a peer does not refresh an
allocation. When an allocation expires, the state data associated allocation. When an allocation expires, the state data associated
with the allocation can be freed. with the allocation can be freed.
skipping to change at page 25, line 44 skipping to change at page 26, line 39
7. Creating an Allocation 7. Creating an Allocation
An allocation on the server is created using an Allocate transaction. An allocation on the server is created using an Allocate transaction.
7.1. Sending an Allocate Request 7.1. Sending an Allocate Request
The client forms an Allocate request as follows. The client forms an Allocate request as follows.
The client first picks a host transport address. It is RECOMMENDED The client first picks a host transport address. It is RECOMMENDED
that the client pick a currently unused transport address, typically that the client pick a currently unused transport address, typically
by allowing the underlying OS to pick a currently unused port for a by allowing the underlying OS to pick a currently unused port.
new socket.
The client then picks a transport protocol to use between the client The client then picks a transport protocol to use between the client
and the server. The transport protocol MUST be one of UDP, TCP, TLS- and the server based on the transport protocols supported by the
over-TCP or DTLS-over-UDP. Since this specification only allows UDP server. The transport protocol MUST be one of UDP, TCP, TLS-over-TCP
between the server and the peers, it is RECOMMENDED that the client or DTLS-over-UDP. Since this specification only allows UDP between
pick UDP unless it has a reason to use a different transport. One the server and the peers, it is RECOMMENDED that the client pick UDP
reason to pick a different transport would be that the client unless it has a reason to use a different transport. One reason to
believes, either through configuration or by experiment, that it is pick a different transport would be that the client believes, either
through configuration or discovery or by experiment, that it is
unable to contact any TURN server using UDP. See Section 2.1 for unable to contact any TURN server using UDP. See Section 2.1 for
more discussion. more discussion.
The client also picks a server transport address, which SHOULD be The client also picks a server transport address, which SHOULD be
done as follows. The client uses one or more procedures described in done as follows. The client uses one or more procedures described in
[RFC8155] to discover a TURN server and uses the TURN server [RFC8155] to discover a TURN server and uses the TURN server
resolution mechanism defined in [RFC5928] to get a list of server resolution mechanism defined in [RFC5928] and [RFC7350] to get a list
transport addresses that can be tried to create a TURN allocation. of server transport addresses that can be tried to create a TURN
allocation.
The client MUST include a REQUESTED-TRANSPORT attribute in the The client MUST include a REQUESTED-TRANSPORT attribute in the
request. This attribute specifies the transport protocol between the request. This attribute specifies the transport protocol between the
server and the peers (note that this is NOT the transport protocol server and the peers (note that this is NOT the transport protocol
that appears in the 5-tuple). In this specification, the REQUESTED- that appears in the 5-tuple). In this specification, the REQUESTED-
TRANSPORT type is always UDP. This attribute is included to allow TRANSPORT type is always UDP. This attribute is included to allow
future extensions to specify other protocols. future extensions to specify other protocols.
If the client wishes to obtain a relayed transport address of a If the client wishes to obtain a relayed transport address of a
specific address type then it includes a REQUESTED-ADDRESS-FAMILY specific address type then it includes a REQUESTED-ADDRESS-FAMILY
attribute in the request. This attribute indicates the specific attribute in the request. This attribute indicates the specific
address type the client wishes the TURN server to allocate. Clients address type the client wishes the TURN server to allocate. Clients
MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in
an Allocate request. Clients MUST NOT include a REQUESTED-ADDRESS- an Allocate request. Clients MUST NOT include a REQUESTED-ADDRESS-
FAMILY attribute in an Allocate request that contains a RESERVATION- FAMILY attribute in an Allocate request that contains a RESERVATION-
TOKEN attribute, for the reasons outlined in [RFC6156]. TOKEN attribute, for the reason that the server uses the previously
reserved transport address corresponding to the included token and
the client cannot obtain a relayed transport address of a specific
address type.
If the client wishes to obtain one IPv6 and one IPv4 relayed If the client wishes to obtain one IPv6 and one IPv4 relayed
transport address then it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it includes an ADDITIONAL-ADDRESS-FAMILY
attribute in the request. This attribute specifies that the server attribute in the request. This attribute specifies that the server
must allocate both address types. The attribute value in the must allocate both address types. The attribute value in the
ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family).
Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
ADDRESS-FAMILY attributes in the same request. Clients MUST NOT ADDRESS-FAMILY attributes in the same request. Clients MUST NOT
include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
that contains a RESERVATION-TOKEN attribute. Clients MUST NOT that contains a RESERVATION-TOKEN attribute. Clients MUST NOT
skipping to change at page 28, line 4 skipping to change at page 28, line 52
of this document. of this document.
2. The server checks if the 5-tuple is currently in use by an 2. The server checks if the 5-tuple is currently in use by an
existing allocation. If yes, the server rejects the request existing allocation. If yes, the server rejects the request
with a 437 (Allocation Mismatch) error. with a 437 (Allocation Mismatch) error.
3. The server checks if the request contains a REQUESTED-TRANSPORT 3. The server checks if the request contains a REQUESTED-TRANSPORT
attribute. If the REQUESTED-TRANSPORT attribute is not included attribute. If the REQUESTED-TRANSPORT attribute is not included
or is malformed, the server rejects the request with a 400 (Bad or is malformed, the server rejects the request with a 400 (Bad
Request) error. Otherwise, if the attribute is included but Request) error. Otherwise, if the attribute is included but
specifies a protocol other that UDP, the server rejects the specifies a protocol other that UDP that is not supported by the
request with a 442 (Unsupported Transport Protocol) error. server, the server rejects the request with a 442 (Unsupported
Transport Protocol) error.
4. The request may contain a DONT-FRAGMENT attribute. If it does, 4. The request may contain a DONT-FRAGMENT attribute. If it does,
but the server does not support sending UDP datagrams with the but the server does not support sending UDP datagrams with the
DF bit set to 1 (see Section 14), then the server treats the DF bit set to 1 (see Section 14), then the server treats the
DONT-FRAGMENT attribute in the Allocate request as an unknown DONT-FRAGMENT attribute in the Allocate request as an unknown
comprehension-required attribute. comprehension-required attribute.
5. The server checks if the request contains a RESERVATION-TOKEN 5. The server checks if the request contains a RESERVATION-TOKEN
attribute. If yes, and the request also contains an EVEN-PORT attribute. If yes, and the request also contains an EVEN-PORT
or REQUESTED-ADDRESS-FAMILY or ADDITIONAL-ADDRESS-FAMILY or REQUESTED-ADDRESS-FAMILY or ADDITIONAL-ADDRESS-FAMILY
skipping to change at page 37, line 10 skipping to change at page 38, line 10
retransmitted Refresh request with a zero "desired lifetime" will retransmitted Refresh request with a zero "desired lifetime" will
cause a 437 (Allocation Mismatch) response if the allocation has cause a 437 (Allocation Mismatch) response if the allocation has
already been deleted, but the client will treat this as equivalent already been deleted, but the client will treat this as equivalent
to a success response (see below). to a success response (see below).
8.3. Receiving a Refresh Response 8.3. Receiving a Refresh Response
If the client receives a success response to its Refresh request with If the client receives a success response to its Refresh request with
a non-zero lifetime, it updates its copy of the allocation data a non-zero lifetime, it updates its copy of the allocation data
structure with the time-to-expiry value contained in the response. structure with the time-to-expiry value contained in the response.
If the client receives a 437 (Allocation Mismatch) error response to
its request to refresh the allocation, it should consider the
allocation no longer exists. If the client receives a 438 (Stale
Nonce) error to its request to refresh the allocation, it should
reattempt the request with the new nonce value.
If the client receives a 437 (Allocation Mismatch) error response to If the client receives a 437 (Allocation Mismatch) error response to
a request to delete the allocation, then the allocation no longer a request to delete the allocation, then the allocation no longer
exists and it should consider its request as having effectively exists and it should consider its request as having effectively
succeeded. succeeded.
9. Permissions 9. Permissions
For each allocation, the server keeps a list of zero or more For each allocation, the server keeps a list of zero or more
permissions. Each permission consists of an IP address and an permissions. Each permission consists of an IP address and an
skipping to change at page 42, line 20 skipping to change at page 43, line 26
Section 11.6. Section 11.6.
If the Data indication passes the above checks, the client delivers If the Data indication passes the above checks, the client delivers
the data octets inside the DATA attribute to the application, along the data octets inside the DATA attribute to the application, along
with an indication that they were received from the peer whose with an indication that they were received from the peer whose
transport address is given by the XOR-PEER-ADDRESS attribute. transport address is given by the XOR-PEER-ADDRESS attribute.
11.5. Receiving an ICMP Packet 11.5. Receiving an ICMP Packet
When the server receives an ICMP packet, the server verifies that the When the server receives an ICMP packet, the server verifies that the
type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2,
1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the IP
IP packet in the ICMP packet payload contains a UDP header. If packet in the ICMP packet payload contains a UDP header. If either
either of these conditions fail, then the ICMP packet is silently of these conditions fail, then the ICMP packet is silently dropped.
dropped.
The server looks up the allocation whose relayed transport address The server looks up the allocation whose relayed transport address
corresponds to the encapsulated packet's source IP address and UDP corresponds to the encapsulated packet's source IP address and UDP
port. If no such allocation exists, the packet is silently dropped. port. If no such allocation exists, the packet is silently dropped.
The server then checks to see whether the set of permissions for the The server then checks to see whether the set of permissions for the
allocation allows the relaying of the ICMP packet. For ICMP packets, allocation allows the relaying of the ICMP packet. For ICMP packets,
the source IP address MUST NOT be checked against the permissions the source IP address MUST NOT be checked against the permissions
list as it would be for UDP packets. Instead, the server extracts list as it would be for UDP packets. Instead, the server extracts
the destination IP address from the encapsulated IP header. The the destination IP address from the encapsulated IP header. The
server then compares this address with the IP address associated with server then compares this address with the IP address associated with
skipping to change at page 50, line 22 skipping to change at page 51, line 22
As discussed in Section 2.6, translations in TURN are designed so As discussed in Section 2.6, translations in TURN are designed so
that a TURN server can be implemented as an application that runs in that a TURN server can be implemented as an application that runs in
userland under commonly available operating systems and that does not userland under commonly available operating systems and that does not
require special privileges. The translations specified in the require special privileges. The translations specified in the
following sections follow this principle. following sections follow this principle.
The descriptions below have two parts: a preferred behavior and an The descriptions below have two parts: a preferred behavior and an
alternate behavior. The server SHOULD implement the preferred alternate behavior. The server SHOULD implement the preferred
behavior. Otherwise, the server MUST implement the alternate behavior. Otherwise, the server MUST implement the alternate
behavior and MUST NOT do anything else for the reasons detailed in behavior and MUST NOT do anything else for the reasons detailed in
[RFC7915]. [RFC7915]. The TURN server solely relies on the DF bit in the IPv4
header and Fragmentation header in IPv6 header to handle
fragmentation and does not rely on the DONT-FRAGMENT attribute.
13.1. IPv4-to-IPv6 Translations 13.1. IPv4-to-IPv6 Translations
Traffic Class Traffic Class
Preferred behavior: As specified in Section 4 of [RFC7915]. Preferred behavior: As specified in Section 4 of [RFC7915].
Alternate behavior: The relay sets the Traffic Class to the Alternate behavior: The TURN server sets the Traffic Class to the
default value for outgoing packets. default value for outgoing packets.
Flow Label Flow Label
Preferred behavior: The relay sets the Flow label to 0. The relay Preferred behavior: The TURN server can use the 5-tuple of relayed
can choose to set the Flow label to a different value if it transport address, peer transport address and UDP protocol number
supports the IPv6 Flow Label field [RFC6437]. to identify each flow, generate and set the flow label value in
the IPv6 packet as discussed in Section 3 of [RFC6437]. If the
TURN server is incapable of generating the flow label value from
the IPv6 packet's 5-tuple, it sets the Flow label to 0.
Alternate behavior: The relay sets the Flow label to the default Alternate behavior: The TURN server sets the Flow label to the
value for outgoing packets. default value of zero for outgoing packets.
Hop Limit Hop Limit
Preferred behavior: As specified in Section 4 of [RFC7915]. Preferred behavior: As specified in Section 4 of [RFC7915].
Alternate behavior: The relay sets the Hop Limit to the default Alternate behavior: The TURN server sets the Hop Limit to the
value for outgoing packets. default value for outgoing packets.
Fragmentation Fragmentation
Preferred behavior: As specified in Section 4 of [RFC7915]. Preferred behavior: As specified in Section 4 of [RFC7915].
Alternate behavior: The relay assembles incoming fragments. The Alternate behavior: The TURN server assembles incoming fragments.
relay follows its default behavior to send outgoing packets. The TURN server follows its default behavior to send outgoing
packets.
For both preferred and alternate behavior, the DONT-FRAGMENT For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server. attribute MUST be ignored by the server.
Extension Headers Extension Headers
Preferred behavior: The relay sends outgoing packet without any Preferred behavior: The TURN server sends outgoing packet without
IPv6 extension headers, with the exception of the Fragmentation any IPv6 extension headers, with the exception of the
header as described above. Fragmentation header as described above.
Alternate behavior: Same as preferred. Alternate behavior: Same as preferred.
13.2. IPv6-to-IPv6 Translations 13.2. IPv6-to-IPv6 Translations
Flow Label Flow Label
The relay should consider that it is handling two different IPv6 The TURN server should consider that it is handling two different
flows. Therefore, the Flow label [RFC6437] SHOULD NOT be copied as IPv6 flows. Therefore, the Flow label [RFC6437] SHOULD NOT be copied
part of the translation. as part of the translation.
Preferred behavior: The relay sets the Flow label to 0. The relay Preferred behavior: The TURN server can use the 5-tuple of relayed
can choose to set the Flow label to a different value if it transport address, peer transport address and UDP protocol number
supports the IPv6 Flow Label field [RFC6437]. to identify each flow, generate and set the flow label value in
the IPv6 packet as discussed in Section 3 of [RFC6437]. If the
TURN server is incapable of generating the flow label value from
the IPv6 packet's 5-tuple, it sets the Flow label to 0.
Alternate behavior: The relay sets the Flow label to the default Alternate behavior: The TURN server sets the Flow label to the
value for outgoing packets. default value of zero for outgoing packets.
Hop Limit Hop Limit
Preferred behavior: The relay acts as a regular router with Preferred behavior: The TURN server acts as a regular router with
respect to decrementing the Hop Limit and generating an ICMPv6 respect to decrementing the Hop Limit and generating an ICMPv6
error if it reaches zero. error if it reaches zero.
Alternate behavior: The relay sets the Hop Limit to the default Alternate behavior: The TURN server sets the Hop Limit to the
value for outgoing packets. default value for outgoing packets.
Fragmentation Fragmentation
Preferred behavior: If the incoming packet did not include a Preferred behavior: If the incoming packet did not include a
Fragment header and the outgoing packet size does not exceed the Fragment header and the outgoing packet size does not exceed the
outgoing link's MTU, the relay sends the outgoing packet without a outgoing link's MTU, the TURN server sends the outgoing packet
Fragment header. without a Fragment header.
If the incoming packet did not include a Fragment header and the If the incoming packet did not include a Fragment header and the
outgoing packet size exceeds the outgoing link's MTU, the relay outgoing packet size exceeds the outgoing link's MTU, the TURN
drops the outgoing packet and send an ICMP message of type 2 code server drops the outgoing packet and send an ICMP message of type
0 ("Packet too big") to the sender of the incoming packet. If 2 code 0 ("Packet too big") to the sender of the incoming packet.
the packet is being sent to the peer, the relay reduces the MTU If the packet is being sent to the peer, the TURN server reduces
reported in the ICMP message by 48 bytes to allow room for the the MTU reported in the ICMP message by 48 bytes to allow room for
overhead of a Data indication. the overhead of a Data indication.
If the incoming packet included a Fragment header and the outgoing If the incoming packet included a Fragment header and the outgoing
packet size (with a Fragment header included) does not exceed the packet size (with a Fragment header included) does not exceed the
outgoing link's MTU, the relay sends the outgoing packet with a outgoing link's MTU, the TURN server sends the outgoing packet
Fragment header. The relay sets the fields of the Fragment header with a Fragment header. The TURN server sets the fields of the
as appropriate for a packet originating from the server. Fragment header as appropriate for a packet originating from the
server.
If the incoming packet included a Fragment header and the outgoing If the incoming packet included a Fragment header and the outgoing
packet size exceeds the outgoing link's MTU, the relay MUST packet size exceeds the outgoing link's MTU, the TURN server MUST
fragment the outgoing packet into fragments of no more than 1280 fragment the outgoing packet into fragments of no more than 1280
bytes. The relay sets the fields of the Fragment header as bytes. The TURN server sets the fields of the Fragment header as
appropriate for a packet originating from the server. appropriate for a packet originating from the server.
Alternate behavior: The relay assembles incoming fragments. The Alternate behavior: The TURN server assembles incoming fragments.
relay follows its default behavior to send outgoing packets. The TURN server follows its default behavior to send outgoing
packets.
For both preferred and alternate behavior, the DONT-FRAGMENT For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server. attribute MUST be ignored by the server.
Extension Headers Extension Headers
Preferred behavior: The relay sends outgoing packet without any Preferred behavior: The TURN server sends outgoing packet without
IPv6 extension headers, with the exception of the Fragmentation any IPv6 extension headers, with the exception of the
header as described above. Fragmentation header as described above.
Alternate behavior: Same as preferred. Alternate behavior: Same as preferred.
13.3. IPv6-to-IPv4 Translations 13.3. IPv6-to-IPv4 Translations
Type of Service and Precedence Type of Service and Precedence
Preferred behavior: As specified in Section 5 of [RFC7915]. Preferred behavior: As specified in Section 5 of [RFC7915].
Alternate behavior: The relay sets the Type of Service and Alternate behavior: The TURN server sets the Type of Service and
Precedence to the default value for outgoing packets. Precedence to the default value for outgoing packets.
Time to Live Time to Live
Preferred behavior: As specified in Section 5 of [RFC7915]. Preferred behavior: As specified in Section 5 of [RFC7915].
Alternate behavior: The relay sets the Time to Live to the default Alternate behavior: The TURN server sets the Time to Live to the
value for outgoing packets. default value for outgoing packets.
Fragmentation Fragmentation
Preferred behavior: As specified in Section 5 of [RFC7915]. Preferred behavior: As specified in Section 5 of [RFC7915].
Additionally, when the outgoing packet's size exceeds the outgoing Additionally, when the outgoing packet's size exceeds the outgoing
link's MTU, the relay needs to generate an ICMP error (ICMPv6 link's MTU, the TURN server needs to generate an ICMP error
Packet Too Big) reporting the MTU size. If the packet is being (ICMPv6 Packet Too Big) reporting the MTU size. If the packet is
sent to the peer, the relay SHOULD reduce the MTU reported in the being sent to the peer, the TURN server SHOULD reduce the MTU
ICMP message by 48 bytes to allow room for the overhead of a Data reported in the ICMP message by 48 bytes to allow room for the
indication. overhead of a Data indication.
Alternate behavior: The relay assembles incoming fragments. The Alternate behavior: The TURN server assembles incoming fragments.
relay follows its default behavior to send outgoing packets. The TURN server follows its default behavior to send outgoing
packets.
For both preferred and alternate behavior, the DONT-FRAGMENT For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server. attribute MUST be ignored by the server.
14. IP Header Fields 14. IP Header Fields
This section describes how the server sets various fields in the IP This section describes how the server sets various fields in the IP
header when relaying between the client and the peer or vice versa. header when relaying between the client and the peer or vice versa.
The descriptions in this section apply: (a) when the server sends a The descriptions in this section apply: (a) when the server sends a
UDP datagram to the peer, or (b) when the server sends a Data UDP datagram to the peer, or (b) when the server sends a Data
skipping to change at page 54, line 12 skipping to change at page 55, line 24
Alternate Behavior: Set the outgoing value to a fixed value, which Alternate Behavior: Set the outgoing value to a fixed value, which
by default is Best Effort unless configured otherwise. by default is Best Effort unless configured otherwise.
In both cases, if the server is immediately adjacent to a In both cases, if the server is immediately adjacent to a
differentiated services classifier and marker, then DSCP MAY be differentiated services classifier and marker, then DSCP MAY be
set to any arbitrary value in the direction towards the set to any arbitrary value in the direction towards the
classifier. classifier.
Explicit Congestion Notification (ECN) field [RFC3168] Explicit Congestion Notification (ECN) field [RFC3168]
Preferred Behavior: Set the outgoing value to the incoming value, Preferred Behavior: Set the outgoing value to the incoming value.
UNLESS the server is doing Active Queue Management, the incoming The server may perform Active Queue Management, in which case it
ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server SHOULD behave as a ECN aware router [RFC3168] and can mark traffic
wishes to indicate that congestion has been experienced, in which with Congestion Experienced (CE) instead of dropping the packet.
case set the outgoing value to CE (=0b11). The use of ECT(1) is subject to experimental usage [RFC8311].
Alternate Behavior: Set the outgoing value to Not-ECT (=0b00). Alternate Behavior: Set the outgoing value to Not-ECT (=0b00).
IPv4 Fragmentation fields IPv4 Fragmentation fields
Preferred Behavior: When the server sends a packet to a peer in Preferred Behavior: When the server sends a packet to a peer in
response to a Send indication containing the DONT-FRAGMENT response to a Send indication containing the DONT-FRAGMENT
attribute, then set the DF bit in the outgoing IP header to 1. In attribute, then set the DF bit in the outgoing IP header to 1. In
all other cases when sending an outgoing packet containing all other cases when sending an outgoing packet containing
application data (e.g., Data indication, ChannelData message, or application data (e.g., Data indication, ChannelData message, or
skipping to change at page 56, line 14 skipping to change at page 57, line 25
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | RFFU = 0 | | Channel Number | RFFU = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16.2. LIFETIME 16.2. LIFETIME
The LIFETIME attribute represents the duration for which the server The LIFETIME attribute represents the duration for which the server
will maintain an allocation in the absence of a refresh. The value will maintain an allocation in the absence of a refresh. The TURN
portion of this attribute is 4-bytes long and consists of a 32-bit client can include the LIFETIME attribute with the desired lifetime
unsigned integral value representing the number of seconds remaining in Allocate and Refresh requests. The value portion of this
until expiration. attribute is 4-bytes long and consists of a 32-bit unsigned integral
value representing the number of seconds remaining until expiration.
16.3. XOR-PEER-ADDRESS 16.3. XOR-PEER-ADDRESS
The XOR-PEER-ADDRESS specifies the address and port of the peer as The XOR-PEER-ADDRESS specifies the address and port of the peer as
seen from the TURN server. (For example, the peer's server-reflexive seen from the TURN server. (For example, the peer's server-reflexive
transport address if the peer is behind a NAT.) It is encoded in the transport address if the peer is behind a NAT.) It is encoded in the
same way as XOR-MAPPED-ADDRESS [I-D.ietf-tram-stunbis]. same way as XOR-MAPPED-ADDRESS [I-D.ietf-tram-stunbis].
16.4. DATA 16.4. DATA
skipping to change at page 57, line 31 skipping to change at page 58, line 45
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R| RFFU | |R| RFFU |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The value contains a single 1-bit flag: The value contains a single 1-bit flag:
R: If 1, the server is requested to reserve the next-higher port R: If 1, the server is requested to reserve the next-higher port
number (on the same IP address) for a subsequent allocation. If number (on the same IP address) for a subsequent allocation. If
0, no such reservation is requested. 0, no such reservation is requested.
RFFU: Reserved For Future Use.
The other 7 bits of the attribute's value must be set to zero on The other 7 bits of the attribute's value must be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
Since the length of this attribute is not a multiple of 4, padding Since the length of this attribute is not a multiple of 4, padding
must immediately follow this attribute. must immediately follow this attribute.
16.8. REQUESTED-TRANSPORT 16.8. REQUESTED-TRANSPORT
This attribute is used by the client to request a specific transport This attribute is used by the client to request a specific transport
protocol for the allocated transport address. The value of this protocol for the allocated transport address. The value of this
skipping to change at page 58, line 15 skipping to change at page 59, line 30
[Protocol-Numbers]. This specification only allows the use of [Protocol-Numbers]. This specification only allows the use of
codepoint 17 (User Datagram Protocol). codepoint 17 (User Datagram Protocol).
The RFFU field MUST be set to zero on transmission and MUST be The RFFU field MUST be set to zero on transmission and MUST be
ignored on reception. It is reserved for future uses. ignored on reception. It is reserved for future uses.
16.9. DONT-FRAGMENT 16.9. DONT-FRAGMENT
This attribute is used by the client to request that the server set This attribute is used by the client to request that the server set
the DF (Don't Fragment) bit in the IP header when relaying the the DF (Don't Fragment) bit in the IP header when relaying the
application data onward to the peer. This attribute has no value application data onward to the peer, and for determining the server
part and thus the attribute length field is 0. capability in Allocate requests. This attribute has no value part
and thus the attribute length field is 0.
16.10. RESERVATION-TOKEN 16.10. RESERVATION-TOKEN
The RESERVATION-TOKEN attribute contains a token that uniquely The RESERVATION-TOKEN attribute contains a token that uniquely
identifies a relayed transport address being held in reserve by the identifies a relayed transport address being held in reserve by the
server. The server includes this attribute in a success response to server. The server includes this attribute in a success response to
tell the client about the token, and the client includes this tell the client about the token, and the client includes this
attribute in a subsequent Allocate request to request the server use attribute in a subsequent Allocate request to request the server use
that relayed transport address for the allocation. that relayed transport address for the allocation.
skipping to change at page 58, line 47 skipping to change at page 60, line 14
16.12. ADDRESS-ERROR-CODE Attribute 16.12. ADDRESS-ERROR-CODE Attribute
This attribute is used by servers to signal the reason for not This attribute is used by servers to signal the reason for not
allocating the requested address family. The value portion of this allocating the requested address family. The value portion of this
attribute is variable length with the following format: attribute is variable length with the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Rsvd |Class| Number | | Family | Reserved |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) .. | Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: there are two values defined for this field and specified in Family: there are two values defined for this field and specified in
[I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and [I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and
0x02 for IPv6 addresses. 0x02 for IPv6 addresses.
Reserved: at this point, the 13 bits in the Reserved field MUST be Reserved: at this point, the 13 bits in the Reserved field MUST be
set to zero by the client and MUST be ignored by the server. set to zero by the client and MUST be ignored by the server.
skipping to change at page 59, line 22 skipping to change at page 60, line 36
Class: The Class represents the hundreds digit of the error code and Class: The Class represents the hundreds digit of the error code and
is defined in section 14.8 of [I-D.ietf-tram-stunbis]. is defined in section 14.8 of [I-D.ietf-tram-stunbis].
Number: this 8-bit field contains the reason server cannot allocate Number: this 8-bit field contains the reason server cannot allocate
one of the requested address types. The error code values could one of the requested address types. The error code values could
be either 440 (unsupported address family) or 508 (insufficient be either 440 (unsupported address family) or 508 (insufficient
capacity). The number representation is defined in section 14.8 capacity). The number representation is defined in section 14.8
of [I-D.ietf-tram-stunbis]. of [I-D.ietf-tram-stunbis].
Reason Phrase: The recommended reason phrases for error codes 440 Reason Phrase: The recommended reason phrases for error codes 440
and 508 are explained in Section 17. and 508 are explained in Section 17. The reason phrase MUST be a
UTF-8 [RFC3629] encoded sequence of less than 128 characters
(which can be as long as 509 bytes when encoding them or 763 bytes
when decoding them).
16.13. ICMP Attribute 16.13. ICMP Attribute
This attribute is used by servers to signal the reason an UDP packet This attribute is used by servers to signal the reason an UDP packet
was dropped. The following is the format of the ICMP attribute. was dropped. The following is the format of the ICMP attribute.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ICMP Type | ICMP Code | | Reserved | ICMP Type | ICMP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This field MUST be set to 0 when sent, and MUST be ignored Reserved: This field MUST be set to 0 when sent, and MUST be ignored
when received. when received.
ICMP Type: The field contains the value in the ICMP type. Its ICMP Type: The field contains the value in the ICMP type. Its
interpretation depends whether the ICMP was received over IPv4 or interpretation depends whether the ICMP was received over IPv4 or
IPv6. IPv6.
ICMP Code: The field contains the value in the ICMP code. Its ICMP Code: The field contains the value in the ICMP code. Its
interpretation depends whether the ICMP was received over IPv4 or interpretation depends whether the ICMP was received over IPv4 or
IPv6. IPv6.
Error Data: This field size is 4 bytes long. If the ICMPv6 type is
2 (Packet Too Big Message) or ICMPv4 type is 3 ( Destination
Unreachable) and Code is 4 (fragmentation needed and DF set), the
Error Data field will be set to the Maximum Transmission Unit of
the next-hop link (Section 3.2 of [RFC4443]) and Section 4 of
[RFC1191]). For other ICMPv6 types and ICMPv4 types and codes,
Error Data field MUST be set to zero.
17. STUN Error Response Codes 17. STUN Error Response Codes
This document defines the following error response codes: This document defines the following error response codes:
403 (Forbidden): The request was valid but cannot be performed due 403 (Forbidden): The request was valid but cannot be performed due
to administrative or similar restrictions. to administrative or similar restrictions.
437 (Allocation Mismatch): A request was received by the server that 437 (Allocation Mismatch): A request was received by the server that
requires an allocation to be in place, but no allocation exists, requires an allocation to be in place, but no allocation exists,
or a request was received that requires no allocation, but an or a request was received that requires no allocation, but an
skipping to change at page 67, line 7 skipping to change at page 68, line 29
client containing the data from the UDP datagram. The server knows client containing the data from the UDP datagram. The server knows
to which client to send the ChannelData message because of the to which client to send the ChannelData message because of the
relayed transport address at which the UDP datagram arrived, and relayed transport address at which the UDP datagram arrived, and
knows to use channel 0x4000 because this is the channel bound to knows to use channel 0x4000 because this is the channel bound to
192.0.2.210:49191. Note that if there had not been any channel 192.0.2.210:49191. Note that if there had not been any channel
number bound to that address, the server would have used a Data number bound to that address, the server would have used a Data
indication instead. indication instead.
TURN TURN Peer Peer TURN TURN Peer Peer
client server A B client server A B
|--- ChannelBind request ----------->| | |
| Transaction-Id=0xE5913A8F46091637EF7D3328 | |
| CHANNEL-NUMBER=0x4000 | | |
| XOR-PEER-ADDRESS=192.0.2.210:49191 | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- ChannelBind success response ---| | |
| Transaction-Id=0xE5913A8F46091637EF7D3328 | |
| MESSAGE-INTEGRITY=... | | |
The channel binding lasts for 10 minutes unless refreshed. The TURN
client refreshes the binding by sending ChannelBind request rebinding
the channel to the same peer (Peer B's IP address). The server
processes the ChannelBind request, rebinds the channel to the same
peer and resets the time-to-expiry timer back to 10 minutes.
TURN TURN Peer Peer
client server A B
|--- Refresh request --------------->| | | |--- Refresh request --------------->| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | | | Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example client 1.03" | | | | SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | | | USERNAME="George" | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| | | | | | | |
|<-- Refresh error response ---------| | | |<-- Refresh error response ---------| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | | | Transaction-Id=0x0864B3C27ADE9354B4312414 | |
skipping to change at page 74, line 36 skipping to change at page 76, line 36
necessarily need to be the tunnel endpoint's address). Suppose he necessarily need to be the tunnel endpoint's address). Suppose he
then spoofs two packets from this address: then spoofs two packets from this address:
1. An Allocate request asking for a v4 address, and 1. An Allocate request asking for a v4 address, and
2. A ChannelBind request establishing a channel to the IPv4 address 2. A ChannelBind request establishing a channel to the IPv4 address
of the tunnel endpoint of the tunnel endpoint
Then he has set up an amplification attack: Then he has set up an amplification attack:
o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it o The TURN server will re-encapsulate IPv6 UDP data in v4 and send
to the tunnel endpoint it to the tunnel endpoint
o The tunnel endpoint will de-encapsulate packets from the v4 o The tunnel endpoint will de-encapsulate packets from the v4
interface and send them to v6 interface and send them to v6
So if the attacker sends a packet of the following form... So if the attacker sends a packet of the following form...
IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 IPv6: src=2001:DB8:1::1 dst=2001:DB8::2
UDP: <ports> UDP: <ports>
TURN: <channel id> TURN: <channel id>
IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 IPv6: src=2001:DB8:1::1 dst=2001:DB8::2
UDP: <ports> UDP: <ports>
TURN: <channel id> TURN: <channel id>
IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 IPv6: src=2001:DB8:1::1 dst=2001:DB8::2
UDP: <ports> UDP: <ports>
TURN: <channel id> TURN: <channel id>
... ...
Then the TURN relay and the tunnel endpoint will send it back and Then the TURN server and the tunnel endpoint will send it back and
forth until the last TURN header is consumed, at which point the TURN forth until the last TURN header is consumed, at which point the TURN
relay will send an empty packet, which the tunnel endpoint will drop. server will send an empty packet, which the tunnel endpoint will
drop.
The amplification potential here is limited by the MTU, so it's not The amplification potential here is limited by the MTU, so it's not
huge: IPv6+UDP+TURN takes 334 bytes, so a four-to-one amplification huge: IPv6+UDP+TURN takes 334 bytes, so a four-to-one amplification
out of a 1500-byte packet is possible. But the attacker could still out of a 1500-byte packet is possible. But the attacker could still
increase traffic volume by sending multiple packets or by increase traffic volume by sending multiple packets or by
establishing multiple channels spoofed from different addresses establishing multiple channels spoofed from different addresses
behind the same tunnel endpoint. behind the same tunnel endpoint.
The attack is mitigated as follows. It is RECOMMENDED that TURN The attack is mitigated as follows. It is RECOMMENDED that TURN
relays not accept allocation or channel binding requests from servers not accept allocation or channel binding requests from
addresses known to be tunneled, and that they not forward data to addresses known to be tunneled, and that they not forward data to
such addresses. In particular, a TURN relay MUST NOT accept Teredo such addresses. In particular, a TURN server MUST NOT accept Teredo
or 6to4 addresses in these requests. or 6to4 addresses in these requests.
19.5. Other Considerations 19.5. Other Considerations
Any relay addresses learned through an Allocate request will not Any relay addresses learned through an Allocate request will not
operate properly with IPsec Authentication Header (AH) [RFC4302] in operate properly with IPsec Authentication Header (AH) [RFC4302] in
transport or tunnel mode. However, tunnel-mode IPsec Encapsulating transport or tunnel mode. However, tunnel-mode IPsec Encapsulating
Security Payload (ESP) [RFC4303] should still operate. Security Payload (ESP) [RFC4303] should still operate.
20. IANA Considerations 20. IANA Considerations
skipping to change at page 78, line 46 skipping to change at page 80, line 47
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. contributions to the text.
Special thanks to Magnus Westerlund for the detailed AD review.
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-19 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21
(work in progress), October 2018. (work in progress), March 2019.
[Protocol-Numbers]
"IANA Protocol Numbers Registry", 2005,
<http://www.iana.org/assignments/protocol-numbers>.
[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 79, line 37 skipping to change at page 81, line 44
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
skipping to change at page 80, line 15 skipping to change at page 82, line 24
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P.
Jones, "Traversal Using Relays around NAT (TURN) Uniform Jones, "Traversal Using Relays around NAT (TURN) Uniform
Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065, Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065,
November 2013, <https://www.rfc-editor.org/info/rfc7065>. November 2013, <https://www.rfc-editor.org/info/rfc7065>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>. <https://www.rfc-editor.org/info/rfc7915>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
24.2. Informative References 24.2. Informative References
skipping to change at page 81, line 9 skipping to change at page 83, line 27
[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>.
[Protocol-Numbers]
"IANA Protocol Numbers Registry", 2005,
<http://www.iana.org/assignments/protocol-numbers>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
skipping to change at page 83, line 27 skipping to change at page 85, line 42
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>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
McAfee, Inc. McAfee, Inc.
 End of changes. 70 change blocks. 
215 lines changed or deleted 320 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/