draft-ietf-tram-turnbis-19.txt   draft-ietf-tram-turnbis-20.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Obsoletes: 5766,6156 (if approved) A. Johnston, Ed. Obsoletes: 5766,6156 (if approved) A. Johnston, Ed.
Intended status: Standards Track Rowan University Intended status: Standards Track Rowan University
Expires: December 5, 2018 P. Matthews Expires: April 14, 2019 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
June 03, 2018 October 11, 2018
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-19 draft-ietf-tram-turnbis-20
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 December 5, 2018. This Internet-Draft will expire on April 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25 7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25
7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27 7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27
7.3. Receiving an Allocate Success Response . . . . . . . . . 32 7.3. Receiving an Allocate Success Response . . . . . . . . . 32
7.4. Receiving an Allocate Error Response . . . . . . . . . . 33 7.4. Receiving an Allocate Error Response . . . . . . . . . . 33
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 35 8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 35
8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35 8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35
8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 36 8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 36
8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 37
9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38 10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a CreatePermission Request . . . . . . . . . . . 38 10.1. Forming a CreatePermission Request . . . . . . . . . . . 39
10.2. Receiving a CreatePermission Request . . . . . . . . . . 39 10.2. Receiving a CreatePermission Request . . . . . . . . . . 39
10.3. Receiving a CreatePermission Response . . . . . . . . . 40 10.3. Receiving a CreatePermission Response . . . . . . . . . 40
11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 40 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 40
11.1. Forming a Send Indication . . . . . . . . . . . . . . . 40 11.1. Forming a Send Indication . . . . . . . . . . . . . . . 40
11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40 11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40
11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 41 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 41
11.4. Receiving a Data Indication . . . . . . . . . . . . . . 42 11.4. Receiving a Data Indication . . . . . . . . . . . . . . 42
11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 42 11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 42
11.6. Receiving a Data Indication with an ICMP attribute . . . 43 11.6. Receiving a Data Indication with an ICMP attribute . . . 43
12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45 12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45
12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 46 12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 46
12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 47
12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47 12.4. The ChannelData Message . . . . . . . . . . . . . . . . 47
12.5. Sending a ChannelData Message . . . . . . . . . . . . . 48 12.5. Sending a ChannelData Message . . . . . . . . . . . . . 48
12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 49
12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 50
13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 50 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 50
13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 50 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 50
13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 51 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 51
13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 53
14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 53 14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 53
15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 55 15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 55
16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 55 16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 55
16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55 16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 56
16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 56 16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 56
16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 56 16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 56
16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 56 16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 56
16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56 16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 57
16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56 16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 57
16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 57 16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 57
16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57 16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 58
16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 58 16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 58
16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 58 16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 58
16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 58 16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 58
16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58 16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 59
16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 59 16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 59
17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59 17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 60
18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60 18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 61
19. Security Considerations . . . . . . . . . . . . . . . . . . . 68 19. Security Considerations . . . . . . . . . . . . . . . . . . . 69
19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68 19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 69
19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68 19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 69
19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68 19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 69
19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69 19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 70
19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69 19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 70
19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70 19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 71
19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70 19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 71
19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 71 19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 72
19.2. Firewall Considerations . . . . . . . . . . . . . . . . 71 19.2. Firewall Considerations . . . . . . . . . . . . . . . . 72
19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 72 19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 73
19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 73 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 . . . . . . . . 74
19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73 19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 74
19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 73 19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 74
19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 74 19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 75
19.3.3. Manipulating Other Allocations . . . . . . . . . . . 74 19.3.3. Manipulating Other Allocations . . . . . . . . . . . 75
19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 74 19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 75
19.5. Other Considerations . . . . . . . . . . . . . . . . . . 75 19.5. Other Considerations . . . . . . . . . . . . . . . . . . 76
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 76 21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 77
22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 78 22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 79
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 79
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
24.1. Normative References . . . . . . . . . . . . . . . . . . 79 24.1. Normative References . . . . . . . . . . . . . . . . . . 80
24.2. Informative References . . . . . . . . . . . . . . . . . 80 24.2. Informative References . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84
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 11, line 8 skipping to change at page 11, line 8
NOTE: While the terminology used in this document refers to NOTE: While the terminology used in this document refers to
5-tuples, the TURN server can store whatever identifier it likes 5-tuples, the TURN server can store whatever identifier it likes
that yields identical results. Specifically, an implementation that yields identical results. Specifically, an implementation
may use a file-descriptor in place of a 5-tuple to represent a TCP may use a file-descriptor in place of a 5-tuple to represent a TCP
connection. connection.
TURN TURN Peer Peer TURN TURN Peer Peer
client server A B client server A B
|-- Allocate request --------------->| | | |-- Allocate request --------------->| | |
| (invalid or missing credentials) | | |
| | | | | | | |
|<--------------- Allocate failure --| | | |<--------------- Allocate failure --| | |
| (401 Unauthenticated) | | | | (401 Unauthenticated) | | |
| | | | | | | |
|-- Allocate request --------------->| | | |-- Allocate request --------------->| | |
| (valid credentials) | | |
| | | | | | | |
|<---------- Allocate success resp --| | | |<---------- Allocate success resp --| | |
| (192.0.2.15:50000) | | | | (192.0.2.15:50000) | | |
// // // // // // // //
| | | | | | | |
|-- Refresh request ---------------->| | | |-- Refresh request ---------------->| | |
| | | | | | | |
|<----------- Refresh success resp --| | | |<----------- Refresh success resp --| | |
| | | | | | | |
Figure 2 Figure 2
In Figure 2, the client sends an Allocate request to the server In Figure 2, the client sends an Allocate request to the server with
without credentials. Since the server requires that all requests be invalid or missing credentials. Since the server requires that all
authenticated using STUN's long-term credential mechanism, the server requests be authenticated using STUN's long-term credential
rejects the request with a 401 (Unauthorized) error code. The client mechanism, the server rejects the request with a 401 (Unauthorized)
then tries again, this time including credentials (not shown). This error code. The client then tries again, this time including
time, the server accepts the Allocate request and returns an Allocate credentials. This time, the server accepts the Allocate request and
success response containing (amongst other things) the relayed returns an Allocate success response containing (amongst other
transport address assigned to the allocation. Sometime later, the things) the relayed transport address assigned to the allocation.
client decides to refresh the allocation and thus sends a Refresh Sometime later, the client decides to refresh the allocation and thus
request to the server. The refresh is accepted and the server sends a Refresh request to the server. The refresh is accepted and
replies with a Refresh success response. the server replies with a Refresh success response.
2.3. Permissions 2.3. Permissions
To ease concerns amongst enterprise IT administrators that TURN could To ease concerns amongst enterprise IT administrators that TURN could
be used to bypass corporate firewall security, TURN includes the be used to bypass corporate firewall security, TURN includes the
notion of permissions. TURN permissions mimic the address-restricted notion of permissions. TURN permissions mimic the address-restricted
filtering mechanism of NATs that comply with [RFC4787]. filtering mechanism of NATs that comply with [RFC4787].
An allocation can have zero or more permissions. Each permission An allocation can have zero or more permissions. Each permission
consists of an IP address and a lifetime. When the server receives a consists of an IP address and a lifetime. When the server receives a
UDP datagram on the allocation's relayed transport address, it first UDP datagram on the allocation's relayed transport address, there are
checks the list of permissions. If the source IP address of the two conditions that cause it to forward that packet: permissions or
datagram matches a permission, the application data is relayed to the TURN server configuration. It first checks the list of permissions.
client, otherwise the UDP datagram is silently discarded. A TURN If the source IP address of the datagram matches a permission, the
server can be configured to permit inbound STUN packets on the application data is relayed to the client, otherwise the UDP datagram
allocation's relayed address even if the source IP addresses of the is silently discarded. Second, a TURN server can be configured to
STUN packets do not match the permissions installed. The filtering permit inbound STUN packets on the allocation's relayed address even
rule to block all traffic except STUN packets speeds up STUN if the source IP addresses of the STUN packets do not match the
connectivity checks, addressing the race condition that exists when permissions installed. The filtering rule to block all traffic
the remote peer sends connectivity checks before the client has had a except STUN packets speeds up STUN connectivity checks, addressing
chance to create permissions in the TURN server for the remote peer the race condition that exists when the remote peer sends
IP addresses. connectivity checks before the client has had a chance to create
permissions in the TURN server for the remote peer IP addresses.
A permission expires after 5 minutes if it is not refreshed, and A permission expires after 5 minutes if it is not refreshed, and
there is no way to explicitly delete a permission. This behavior was there is no way to explicitly delete a permission. This behavior was
selected to match the behavior of a NAT that complies with [RFC4787]. selected to match the behavior of a NAT that complies with [RFC4787].
The client can install or refresh a permission using either a The client can install or refresh a permission using either a
CreatePermission request or a ChannelBind request. Using the CreatePermission request or a ChannelBind request. Using the
CreatePermission request, multiple permissions can be installed or CreatePermission request, multiple permissions can be installed or
refreshed with a single request -- this is important for applications refreshed with a single request -- this is important for applications
that use ICE. For security reasons, permissions can only be that use ICE. For security reasons, permissions can only be
skipping to change at page 38, line 5 skipping to change at page 38, line 4
a permission. A given permission may be initially installed and/or a permission. A given permission may be initially installed and/or
refreshed with a CreatePermission request, and then later refreshed refreshed with a CreatePermission request, and then later refreshed
with a ChannelBind request, or vice versa. with a ChannelBind request, or vice versa.
A TURN server MUST have a configuration knob to allow inbound STUN A TURN server MUST have a configuration knob to allow inbound STUN
packets on the allocation's relayed address even if the source IP packets on the allocation's relayed address even if the source IP
addresses of the STUN packets do not match the permissions installed. addresses of the STUN packets do not match the permissions installed.
This configuration knob MUST default to drop the inbound STUN packets This configuration knob MUST default to drop the inbound STUN packets
on the allocation's relayed address if the source IP addresses of the on the allocation's relayed address if the source IP addresses of the
STUN packets do not match the permissions installed unless explicitly STUN packets do not match the permissions installed unless explicitly
configured to do otherwise. configured to do otherwise. The default configuration to drop
inbound packets not matching the permissions installed resembles
firewall default behavior to block unsolicited inbound traffic.
When a UDP datagram arrives at the relayed transport address for the When a UDP datagram arrives at the relayed transport address for the
allocation, the server extracts the source IP address from the IP allocation, the server extracts the source IP address from the IP
header. The server then compares this address with the IP address header. The server then compares this address with the IP address
associated with each permission in the list of permissions for the associated with each permission in the list of permissions for the
allocation. If no match is found and the received datagram is not a allocation. Note that only addresses are compared and port numbers
STUN packet, the permission check is considered to have failed. If are not considered. If no match is found and the received datagram
an exact match is found, the permission check is considered to have is not a STUN packet, the permission check is considered to have
succeeded. If no match is found and the received datagram is a STUN failed. If an exact match is found, the permission check is
packet, the permission check is considered to have failed unless the considered to have succeeded. If no match is found and the received
server is configured to allow STUN packets without explicit datagram is a STUN packet and the server is configured to allow STUN
permission, in which case the permission check is considered to have packets without explicit permission, the permission check is
succeeded. If the permission check fails, relaying is not permitted considered to have succeeded. If no match is found and the received
and the server silently discards the UDP datagram. If the permission datagram is a STUN packet and the server is not configured to allow
check succeeds, the services continues to process the UDP datagram as STUN packets without explicit permission, the permission check is
specified elsewhere (Section 11.3). Note that only addresses are considered to have failed. If the permission check fails, relaying
compared and port numbers are not considered. is not permitted and the server silently discards the UDP datagram.
If the permission check succeeds, the services continues to process
the UDP datagram as specified elsewhere (Section 11.3).
The permissions for one allocation are totally unrelated to the The permissions for one allocation are totally unrelated to the
permissions for a different allocation. If an allocation expires, permissions for a different allocation. If an allocation expires,
all its permissions expire with it. all its permissions expire with it.
NOTE: Though TURN permissions expire after 5 minutes, many NATs NOTE: Though TURN permissions expire after 5 minutes, many NATs
deployed at the time of publication expire their UDP bindings deployed at the time of publication expire their UDP bindings
considerably faster. Thus, an application using TURN will considerably faster. Thus, an application using TURN will
probably wish to send some sort of keep-alive traffic at a much probably wish to send some sort of keep-alive traffic at a much
faster rate. Applications using ICE should follow the keep-alive faster rate. Applications using ICE should follow the keep-alive
skipping to change at page 78, line 47 skipping to change at page 79, line 47
23. Acknowledgements 23. Acknowledgements
Most of the text in this note comes from the original TURN Most of the text in this note comes from the original TURN
specification, [RFC5766]. The authors would like to thank Rohan Mahy specification, [RFC5766]. The authors would like to thank Rohan Mahy
co-author of original TURN specification and everyone who had co-author of original TURN specification and everyone who had
contributed to that document. The authors would also like to contributed to that document. The authors would also like to
acknowledge that this document inherits material from [RFC6156]. acknowledge that this document inherits material from [RFC6156].
Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang
and Simon Perreault for their help on SSODA mechanism. Authors would and Simon Perreault for their help on the ADDITIONAL-ADDRESS-FAMILY
like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox, mechanism. Authors would like to thank Gonzalo Salgueiro, Simon
Brandon Williams, Karl Stahl, Noriyuki Torii, Nils Ohlmeier, Justin Perreault, Jonathan Lennox, Brandon Williams, Karl Stahl, Noriyuki
Uberti and Oleg Moskalenko for comments and review. The authors Torii, Nils Ohlmeier, Dan Wing, Justin Uberti and Oleg Moskalenko for
would like to thank Marc for his contributions to the text. Thanks comments and review. The authors would like to thank Marc for his
to Eric Rescorla for proposing the update to allow the TURN server to contributions to the text. Thanks to Eric Rescorla for proposing the
forward inbound STUN connectivity checks without permission. update to allow the TURN server to forward inbound STUN connectivity
checks without permission.
24. References 24. References
24.1. Normative References 24.1. Normative References
[I-D.ietf-tram-stunbis] [I-D.ietf-tram-stunbis]
Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", draft-ietf-tram-stunbis-18 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-18
(work in progress), May 2018. (work in progress), May 2018.
skipping to change at page 80, line 43 skipping to change at page 81, line 43
24.2. Informative References 24.2. Informative References
[Frag-Harmful] [Frag-Harmful]
"Fragmentation Considered Harmful", <Proc. SIGCOMM '87, "Fragmentation Considered Harmful", <Proc. SIGCOMM '87,
vol. 17, No. 5, October 1987>. vol. 17, No. 5, October 1987>.
[I-D.ietf-tram-stun-pmtud] [I-D.ietf-tram-stun-pmtud]
Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft- Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-08 (work in progress), May 2018. ietf-tram-stun-pmtud-10 (work in progress), September
2018.
[I-D.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008. nonsip-01 (work in progress), July 2008.
[Port-Numbers] [Port-Numbers]
"IANA Port Numbers Registry", 2005, "IANA Port Numbers Registry", 2005,
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
 End of changes. 20 change blocks. 
86 lines changed or deleted 95 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/