draft-ietf-tram-turnbis-10.txt   draft-ietf-tram-turnbis-11.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft Internet-Draft McAfee
Intended status: Standards Track A. Johnston, Ed. Intended status: Standards Track A. Johnston, Ed.
Expires: November 10, 2017 Unaffiliated Expires: December 3, 2017 Unaffiliated
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
May 9, 2017 June 1, 2017
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-10 draft-ietf-tram-turnbis-11
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 1, line 49 skipping to change at page 1, line 49
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 November 10, 2017. This Internet-Draft will expire on December 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 38 skipping to change at page 2, line 38
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. Discovery of TURN server . . . . . . . . . . . . . . . . 18 2.9. Discovery of TURN server . . . . . . . . . . . . . . . . 18
2.9.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . 18 2.9.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . 18
2.10. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18 2.10. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 24 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 26 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 26
6.3. Receiving an Allocate Success Response . . . . . . . . . 31 6.3. Receiving an Allocate Success Response . . . . . . . . . 31
6.4. Receiving an Allocate Error Response . . . . . . . . . . 31 6.4. Receiving an Allocate Error Response . . . . . . . . . . 32
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 34 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 34
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 34 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 35
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 35 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 35
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 37 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Forming a CreatePermission Request . . . . . . . . . . . 37 9.1. Forming a CreatePermission Request . . . . . . . . . . . 37
9.2. Receiving a CreatePermission Request . . . . . . . . . . 37 9.2. Receiving a CreatePermission Request . . . . . . . . . . 37
9.3. Receiving a CreatePermission Response . . . . . . . . . . 38 9.3. Receiving a CreatePermission Response . . . . . . . . . . 38
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 38 10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a Send Indication . . . . . . . . . . . . . . . 38 10.1. Forming a Send Indication . . . . . . . . . . . . . . . 38
10.2. Receiving a Send Indication . . . . . . . . . . . . . . 39 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 39
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40
10.4. Receiving a Data Indication with DATA attribute . . . . 40 10.4. Receiving a Data Indication with DATA attribute . . . . 40
10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40 10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41
10.6. Receiving a Data Indication with an ICMP attribute . . . 41 10.6. Receiving a Data Indication with an ICMP attribute . . . 41
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 44 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 44
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 45 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 45
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 45 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 46
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 46 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 46
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 47 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 47
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48
12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 48 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 48
12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 48 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 48
12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 49 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 49
12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 50 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 50
13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 51 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 51
14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 53 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 53
15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 53 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 53
skipping to change at page 3, line 40 skipping to change at page 3, line 40
15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55 15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55
15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 55 15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 55
15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56 15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56
15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 56 15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 56
15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 56 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 56
15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57
15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 57 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 57
15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58 15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58
16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 58 16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 58
17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 59 17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 59
18. Security Considerations . . . . . . . . . . . . . . . . . . . 66 18. Security Considerations . . . . . . . . . . . . . . . . . . . 67
18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 66 18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 67
18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 66 18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 67
18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 67 18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 67
18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 67 18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 68
18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 67 18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 68
18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 68 18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 69
18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 68 18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 69
18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 69 18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 70
18.2. Firewall Considerations . . . . . . . . . . . . . . . . 70 18.2. Firewall Considerations . . . . . . . . . . . . . . . . 70
18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 70 18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 71
18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 71 18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 71
18.2.3. Running Servers on Well-Known Ports . . . . . . . . 71 18.2.3. Running Servers on Well-Known Ports . . . . . . . . 72
18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 71 18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 72
18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 71 18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 72
18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 72 18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 72
18.3.3. Manipulating Other Allocations . . . . . . . . . . . 72 18.3.3. Manipulating Other Allocations . . . . . . . . . . . 73
18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 72 18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 73
18.5. Other Considerations . . . . . . . . . . . . . . . . . . 73 18.5. Other Considerations . . . . . . . . . . . . . . . . . . 74
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 74 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75
21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 76 21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 77
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
23.1. Normative References . . . . . . . . . . . . . . . . . . 77 23.1. Normative References . . . . . . . . . . . . . . . . . . 77
23.2. Informative References . . . . . . . . . . . . . . . . . 78 23.2. Informative References . . . . . . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
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 10 skipping to change at page 11, line 10
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 --------------->| | |
| | | | | | | |
|<--------------- Allocate failure --| | | |<--------------- Allocate failure --| | |
| (401 Unauthorized) | | | | (401 Unauthenticated) | | |
| | | | | | | |
|-- Allocate request --------------->| | | |-- Allocate request --------------->| | |
| | | | | | | |
|<---------- 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 --| | |
skipping to change at page 19, line 19 skipping to change at page 19, line 19
established. If connections are established on both IP address established. If connections are established on both IP address
families then terminate the TCP connection using the IP address families then terminate the TCP connection using the IP address
family with lower precedence [RFC6724]. family with lower precedence [RFC6724].
o For clear text UDP, send TURN Allocate requests to both IP address o For clear text UDP, send TURN Allocate requests to both IP address
families as discussed in [RFC6555], without authentication families as discussed in [RFC6555], without authentication
information. If the TURN server requires authentication, it will information. If the TURN server requires authentication, it will
send back a 401 unauthenticated response and the TURN client uses send back a 401 unauthenticated response and the TURN client uses
the first UDP connection on which a 401 error response is the first UDP connection on which a 401 error response is
received. If a 401 error response is received from both IP received. If a 401 error response is received from both IP
address families then the TURN client will silently abandon the address families then the TURN client can silently abandon the UDP
UDP connection on the IP address family with lower precedence. If connection on the IP address family with lower precedence. If the
the TURN server does not require authentication (as described in TURN server does not require authentication (as described in
Section 9 of [RFC8155]), it is possible for both Allocate requests Section 9 of [RFC8155]), it is possible for both Allocate requests
to succeed. In this case, the TURN client sends a Refresh with to succeed. In this case, the TURN client sends a Refresh with
LIFETIME value of 0 on the allocation using the IP address family LIFETIME value of 0 on the allocation using the IP address family
with lower precedence to delete the allocation. with lower precedence to delete the allocation.
o For DTLS over UDP, initiate DTLS handshake to both IP address o For DTLS over UDP, initiate DTLS handshake to both IP address
families as discussed in [RFC6555] and use the first DTLS session families as discussed in [RFC6555] and use the first DTLS session
that is established. If the DTLS session is established on both that is established. If the DTLS session is established on both
IP addresses families then the client sends DTLS close_notify IP addresses families then the client sends DTLS close_notify
alert to terminate the DTLS session using the IP address family alert to terminate the DTLS session using the IP address family
with lower precedence. with lower precedence. If TURN over DTLS server has been
configured to require a cookie exchange (Section 4.2 in [RFC6347])
and HelloVerifyRequest is received from the TURN servers on both
IP addresses families then the client can silently abandon the
connection on the IP address family with lower precedence.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Readers are expected to be familiar with [RFC5389] and the terms Readers are expected to be familiar with [RFC5389] and the terms
defined there. defined there.
skipping to change at page 59, line 41 skipping to change at page 59, line 41
diagram shown in the Overview (Figure 1). diagram shown in the Overview (Figure 1).
For each message, the attributes included in the message and their For each message, the attributes included in the message and their
values are shown. For convenience, values are shown in a human- values are shown. For convenience, values are shown in a human-
readable format rather than showing the actual octets; for example, readable format rather than showing the actual octets; for example,
"XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED- "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED-
ADDRESS attribute is included with an address of 192.0.2.15 and a ADDRESS attribute is included with an address of 192.0.2.15 and a
port of 9000, here the address and port are shown before the xor-ing port of 9000, here the address and port are shown before the xor-ing
is done. For attributes with string-like values (e.g., is done. For attributes with string-like values (e.g.,
SOFTWARE="Example client, version 1.03" and SOFTWARE="Example client, version 1.03" and
NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"), the value of the attribute NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda"), the value of the attribute
is shown in quotes for readability, but these quotes do not appear in is shown in quotes for readability, but these quotes do not appear in
the actual value. the actual value.
TURN TURN Peer Peer TURN TURN Peer Peer
client server A B client server A B
| | | | | | | |
|--- Allocate request -------------->| | | |--- Allocate request -------------->| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | | | Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example client, version 1.03" | | | SOFTWARE="Example client, version 1.03" | |
| LIFETIME=3600 (1 hour) | | | | LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | | | REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | | | DONT-FRAGMENT | | |
| | | | | | | |
|<-- Allocate error response --------| | | |<-- Allocate error response --------| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | | | Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example server, version 1.17" | | | SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=401 (Unauthorized) | | | | ERROR-CODE=401 (Unauthorized) | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| | | | | | | |
|--- Allocate request -------------->| | | |--- Allocate request -------------->| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | | | Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example client 1.03" | | | | SOFTWARE="Example client 1.03" | | |
| LIFETIME=3600 (1 hour) | | | | LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | | | REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | | | DONT-FRAGMENT | | |
| USERNAME="George" | | | | USERNAME="George" | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| MESSAGE-INTEGRITY-SHA256=... | | |
| | | | | | | |
|<-- Allocate success response ------| | | |<-- Allocate success response ------| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | | | Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example server, version 1.17" | | | SOFTWARE="Example server, version 1.17" | |
| LIFETIME=1200 (20 minutes) | | | | LIFETIME=1200 (20 minutes) | | |
| XOR-RELAYED-ADDRESS=192.0.2.15:50000 | | | XOR-RELAYED-ADDRESS=192.0.2.15:50000 | |
| XOR-MAPPED-ADDRESS=192.0.2.1:7000 | | | XOR-MAPPED-ADDRESS=192.0.2.1:7000 | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
The client begins by selecting a host transport address to use for The client begins by selecting a host transport address to use for
skipping to change at page 61, line 13 skipping to change at page 61, line 16
the allocation to have a longer lifetime than the default of 10 the allocation to have a longer lifetime than the default of 10
minutes; the value of this attribute is 3600 seconds, which minutes; the value of this attribute is 3600 seconds, which
corresponds to 1 hour. The client must always include a REQUESTED- corresponds to 1 hour. The client must always include a REQUESTED-
TRANSPORT attribute in an Allocate request and the only value allowed TRANSPORT attribute in an Allocate request and the only value allowed
by this specification is 17, which indicates UDP transport between by this specification is 17, which indicates UDP transport between
the server and the peers. The client also includes the DONT-FRAGMENT the server and the peers. The client also includes the DONT-FRAGMENT
attribute because it wishes to use the DONT-FRAGMENT attribute later attribute because it wishes to use the DONT-FRAGMENT attribute later
in Send indications; this attribute consists of only an attribute in Send indications; this attribute consists of only an attribute
header, there is no value part. We assume the client has not header, there is no value part. We assume the client has not
recently interacted with the server, thus the client does not include recently interacted with the server, thus the client does not include
USERNAME, REALM, NONCE, or MESSAGE-INTEGRITY attribute. Finally, USERNAME, USERHASH, REALM, NONCE, PASSWORD-ALGORITHMS, PASSWORD-
note that the order of attributes in a message is arbitrary (except ALGORITHM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
for the MESSAGE-INTEGRITY and FINGERPRINT attributes) and the client Finally, note that the order of attributes in a message is arbitrary
could have used a different order. (except for the MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256 and
FINGERPRINT attributes) and the client could have used a different
order.
Servers require any request to be authenticated. Thus, when the Servers require any request to be authenticated. Thus, when the
server receives the initial Allocate request, it rejects the request server receives the initial Allocate request, it rejects the request
because the request does not contain the authentication attributes. because the request does not contain the authentication attributes.
Following the procedures of the long-term credential mechanism of Following the procedures of the long-term credential mechanism of
STUN [RFC5389], the server includes an ERROR-CODE attribute with a STUN [RFC5389], the server includes an ERROR-CODE attribute with a
value of 401 (Unauthorized), a REALM attribute that specifies the value of 401 (Unauthorized), a REALM attribute that specifies the
authentication realm used by the server (in this case, the server's authentication realm used by the server (in this case, the server's
domain "example.com"), and a nonce value in a NONCE attribute. The domain "example.com"), and a nonce value in a NONCE attribute. The
NONCE attribute starts with the "nonce cookie" with the STUN Security
Feature "Password algorithm" bit set to 1. The server includes a
PASSWORD-ALGORITHMS attribute that specifies the list of algorithms
that the server can use to derive the long-term password. If the
server sets the STUN Security Feature "Username anonymity" bit to 1
then the client uses the USERHASH attribute instead of the USERNAME
attribute in the Allocate request to anonymise the username. The
server also includes a SOFTWARE attribute that gives information server also includes a SOFTWARE attribute that gives information
about the server's software. about the server's software.
The client, upon receipt of the 401 error, re-attempts the Allocate The client, upon receipt of the 401 error, re-attempts the Allocate
request, this time including the authentication attributes. The request, this time including the authentication attributes. The
client selects a new transaction id, and then populates the new client selects a new transaction id, and then populates the new
Allocate request with the same attributes as before. The client Allocate request with the same attributes as before. The client
includes a USERNAME attribute and uses the realm value received from includes a USERNAME attribute and uses the realm value received from
the server to help it determine which value to use; here the client the server to help it determine which value to use; here the client
is configured to use the username "George" for the realm is configured to use the username "George" for the realm
"example.com". The client also includes the REALM and NONCE "example.com". The client includes the PASSWORD-ALGORITHM attribute
indicating the algorithm that the server must use to derive the long-
term password. The client also includes the REALM and NONCE
attributes, which are just copied from the 401 error response. attributes, which are just copied from the 401 error response.
Finally, the client includes a MESSAGE-INTEGRITY attribute as the
last attribute in the message, whose value is a Hashed Message Finally, the client includes MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
Authentication Code - Secure Hash Algorithm 1 (HMAC-SHA1) hash over SHA256 attributes as the last attributes in the message, whose values
the contents of the message (shown as just "..." above); this HMAC- are Hashed Message Authentication Code - Secure Hash Algorithm 1
SHA1 computation includes a password value. Thus, an attacker cannot (HMAC-SHA1) hash and Hashed Message Authentication Code - Secure Hash
compute the message integrity value without somehow knowing the Algorithm 2 (HMAC-SHA2) hash over the contents of the message (shown
secret password. as just "..." above); this HMAC-SHA1 and HMAC-SHA2 computation
includes a password value. Thus, an attacker cannot compute the
message integrity value without somehow knowing the secret password.
The server, upon receipt of the authenticated Allocate request, The server, upon receipt of the authenticated Allocate request,
checks that everything is OK, then creates an allocation. The server checks that everything is OK, then creates an allocation. The server
replies with an Allocate success response. The server includes a replies with an Allocate success response. The server includes a
LIFETIME attribute giving the lifetime of the allocation; here, the LIFETIME attribute giving the lifetime of the allocation; here, the
server has reduced the client's requested 1-hour lifetime to just 20 server has reduced the client's requested 1-hour lifetime to just 20
minutes, because this particular server doesn't allow lifetimes minutes, because this particular server doesn't allow lifetimes
longer than 20 minutes. The server includes an XOR-RELAYED-ADDRESS longer than 20 minutes. The server includes an XOR-RELAYED-ADDRESS
attribute whose value is the relayed transport address of the attribute whose value is the relayed transport address of the
allocation. The server includes an XOR-MAPPED-ADDRESS attribute allocation. The server includes an XOR-MAPPED-ADDRESS attribute
whose value is the server-reflexive address of the client; this value whose value is the server-reflexive address of the client; this value
is not used otherwise in TURN but is returned as a convenience to the is not used otherwise in TURN but is returned as a convenience to the
client. The server includes a MESSAGE-INTEGRITY attribute to client. The server includes either a MESSAGE-INTEGRITY or MESSAGE-
authenticate the response and to ensure its integrity; note that the INTEGRITY-SHA256 attribute to authenticate the response and to ensure
response does not contain the USERNAME, REALM, and NONCE attributes. its integrity; note that the response does not contain the USERNAME,
The server also includes a SOFTWARE attribute. REALM, and NONCE attributes. The server also includes a SOFTWARE
attribute.
TURN TURN Peer Peer TURN TURN Peer Peer
client server A B client server A B
|--- CreatePermission request ------>| | | |--- CreatePermission request ------>| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | | | Transaction-Id=0xE5913A8F460956CA277D3319 | |
| XOR-PEER-ADDRESS=192.0.2.150:0 | | | | XOR-PEER-ADDRESS=192.0.2.150:0 | | |
| USERNAME="George" | | | | USERNAME="George" | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| | | | | | | |
|<-- CreatePermission success resp.--| | | |<-- CreatePermission success resp.--| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | | | Transaction-Id=0xE5913A8F460956CA277D3319 | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
The client then creates a permission towards Peer A in preparation The client then creates a permission towards Peer A in preparation
for sending it some application data. This is done through a for sending it some application data. This is done through a
CreatePermission request. The XOR-PEER-ADDRESS attribute contains CreatePermission request. The XOR-PEER-ADDRESS attribute contains
the IP address for which a permission is established (the IP address the IP address for which a permission is established (the IP address
skipping to change at page 62, line 44 skipping to change at page 63, line 12
0; also, note how the client uses Peer A's server-reflexive IP 0; also, note how the client uses Peer A's server-reflexive IP
address and not its (private) host address. The client uses the same address and not its (private) host address. The client uses the same
username, realm, and nonce values as in the previous request on the username, realm, and nonce values as in the previous request on the
allocation. Though it is allowed to do so, the client has chosen not allocation. Though it is allowed to do so, the client has chosen not
to include a SOFTWARE attribute in this request. to include a SOFTWARE attribute in this request.
The server receives the CreatePermission request, creates the The server receives the CreatePermission request, creates the
corresponding permission, and then replies with a CreatePermission corresponding permission, and then replies with a CreatePermission
success response. Like the client, the server chooses not to include success response. Like the client, the server chooses not to include
the SOFTWARE attribute in its reply. Again, note how success the SOFTWARE attribute in its reply. Again, note how success
responses contain a MESSAGE-INTEGRITY attribute (assuming the server responses contain a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
uses the long-term credential mechanism), but no USERNAME, REALM, and attribute (assuming the server uses the long-term credential
NONCE attributes. mechanism), but no USERNAME, REALM, and NONCE attributes.
TURN TURN Peer Peer TURN TURN Peer Peer
client server A B client server A B
|--- Send indication --------------->| | | |--- Send indication --------------->| | |
| Transaction-Id=0x1278E9ACA2711637EF7D3328 | | | Transaction-Id=0x1278E9ACA2711637EF7D3328 | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | | | XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DONT-FRAGMENT | | | | DONT-FRAGMENT | | |
| DATA=... | | | | DATA=... | | |
| |-- UDP dgm ->| | | |-- UDP dgm ->| |
| | data=... | | | | data=... | |
skipping to change at page 63, line 30 skipping to change at page 63, line 41
| DATA=... | | | | DATA=... | | |
The client now sends application data to Peer A using a Send The client now sends application data to Peer A using a Send
indication. Peer A's server-reflexive transport address is specified indication. Peer A's server-reflexive transport address is specified
in the XOR-PEER-ADDRESS attribute, and the application data (shown in the XOR-PEER-ADDRESS attribute, and the application data (shown
here as just "...") is specified in the DATA attribute. The client here as just "...") is specified in the DATA attribute. The client
is doing a form of path MTU discovery at the application layer and is doing a form of path MTU discovery at the application layer and
thus specifies (by including the DONT-FRAGMENT attribute) that the thus specifies (by including the DONT-FRAGMENT attribute) that the
server should set the DF bit in the UDP datagram to send to the peer. server should set the DF bit in the UDP datagram to send to the peer.
Indications cannot be authenticated using the long-term credential Indications cannot be authenticated using the long-term credential
mechanism of STUN, so no MESSAGE-INTEGRITY attribute is included in mechanism of STUN, so no MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
the message. An application wishing to ensure that its data is not SHA256 attribute is included in the message. An application wishing
altered or forged must integrity-protect its data at the application to ensure that its data is not altered or forged must integrity-
level. protect its data at the application level.
Upon receipt of the Send indication, the server extracts the Upon receipt of the Send indication, the server extracts the
application data and sends it in a UDP datagram to Peer A, with the application data and sends it in a UDP datagram to Peer A, with the
relayed transport address as the source transport address of the relayed transport address as the source transport address of the
datagram, and with the DF bit set as requested. Note that, had the datagram, and with the DF bit set as requested. Note that, had the
client not previously established a permission for Peer A's server- client not previously established a permission for Peer A's server-
reflexive IP address, then the server would have silently discarded reflexive IP address, then the server would have silently discarded
the Send indication instead. the Send indication instead.
Peer A then replies with its own UDP datagram containing application Peer A then replies with its own UDP datagram containing application
skipping to change at page 64, line 13 skipping to change at page 64, line 22
The resulting Data indication is then sent to the client. The resulting Data indication is then sent to the client.
TURN TURN Peer Peer TURN TURN Peer Peer
client server A B client server A B
|--- ChannelBind request ----------->| | | |--- ChannelBind request ----------->| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | | | Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| CHANNEL-NUMBER=0x4000 | | | | CHANNEL-NUMBER=0x4000 | | |
| XOR-PEER-ADDRESS=192.0.2.210:49191 | | | XOR-PEER-ADDRESS=192.0.2.210:49191 | |
| USERNAME="George" | | | | USERNAME="George" | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| | | | | | | |
|<-- ChannelBind success response ---| | | |<-- ChannelBind success response ---| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | | | Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
The client now binds a channel to Peer B, specifying a free channel The client now binds a channel to Peer B, specifying a free channel
number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's
transport address in the XOR-PEER-ADDRESS attribute. As before, the transport address in the XOR-PEER-ADDRESS attribute. As before, the
client re-uses the username, realm, and nonce from its last request client re-uses the username, realm, and nonce from its last request
skipping to change at page 65, line 22 skipping to change at page 66, line 12
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
|--- 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="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| | | | | | | |
|<-- Refresh error response ---------| | | |<-- Refresh error response ---------| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | | | Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example server, version 1.17" | | | SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=438 (Stale Nonce) | | | | ERROR-CODE=438 (Stale Nonce) | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | | | NONCE="obMatJos2AAABnpSw1Xw239bBwGYhjN" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| | | | | | | |
|--- Refresh request --------------->| | | |--- Refresh request --------------->| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | | | Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example client 1.03" | | | | SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | | | USERNAME="George" | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | | | NONCE="obMatJos2AAABnpSw1Xw239bBwGYhjNj" | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| | | | | | | |
|<-- Refresh success response -------| | | |<-- Refresh success response -------| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | | | Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example server, version 1.17" | | | SOFTWARE="Example server, version 1.17" | |
| LIFETIME=600 (10 minutes) | | | | LIFETIME=600 (10 minutes) | | |
Sometime before the 20 minute lifetime is up, the client refreshes Sometime before the 20 minute lifetime is up, the client refreshes
the allocation. This is done using a Refresh request. As before, the allocation. This is done using a Refresh request. As before,
the client includes the latest username, realm, and nonce values in the client includes the latest username, realm, and nonce values in
skipping to change at page 78, line 26 skipping to change at page 79, line 20
[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,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>. 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
23.2. Informative References 23.2. Informative References
[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,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[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,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
skipping to change at page 81, line 16 skipping to change at page 82, line 16
"Fragmentation Considered Harmful", <Proc. SIGCOMM '87, "Fragmentation Considered Harmful", <Proc. SIGCOMM '87,
vol. 17, No. 5, October 1987>. vol. 17, No. 5, October 1987>.
[Protocol-Numbers] [Protocol-Numbers]
"IANA Protocol Numbers Registry", 2005, "IANA Protocol Numbers Registry", 2005,
<http://www.iana.org/assignments/protocol-numbers>. <http://www.iana.org/assignments/protocol-numbers>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
Bangalore, Karnataka 560103 McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Alan Johnston (editor) Alan Johnston (editor)
Unaffiliated Unaffiliated
Bellevue, WA Bellevue, WA
USA USA
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
 End of changes. 37 change blocks. 
68 lines changed or deleted 97 lines changed or added

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