draft-ietf-tram-turnbis-14.txt   draft-ietf-tram-turnbis-15.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: August 26, 2018 P. Matthews Expires: September 19, 2018 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
February 22, 2018 March 18, 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-14 draft-ietf-tram-turnbis-15
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 August 26, 2018. This Internet-Draft will expire on September 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18 2.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 21 4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 21
4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 21 4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 21
5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21 5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21
6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25 7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25
7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25 7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25
7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27 7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27
7.3. Receiving an Allocate Success Response . . . . . . . . . 31 7.3. Receiving an Allocate Success Response . . . . . . . . . 32
7.4. Receiving an Allocate Error Response . . . . . . . . . . 32 7.4. Receiving an Allocate Error Response . . . . . . . . . . 32
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34 8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34
8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35 8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 35
8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 35 8.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 35
8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 36 8.3. Receiving a Refresh Response . . . . . . . . . . . . . . 36
9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 37 10. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a CreatePermission Request . . . . . . . . . . . 38 10.1. Forming a CreatePermission Request . . . . . . . . . . . 38
10.2. Receiving a CreatePermission Request . . . . . . . . . . 38 10.2. Receiving a CreatePermission Request . . . . . . . . . . 38
10.3. Receiving a CreatePermission Response . . . . . . . . . 39 10.3. Receiving a CreatePermission Response . . . . . . . . . 39
11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 39 11. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 39
11.1. Forming a Send Indication . . . . . . . . . . . . . . . 39 11.1. Forming a Send Indication . . . . . . . . . . . . . . . 39
11.2. Receiving a Send Indication . . . . . . . . . . . . . . 39 11.2. Receiving a Send Indication . . . . . . . . . . . . . . 40
11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40
11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41 11.4. Receiving a Data Indication . . . . . . . . . . . . . . 41
11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41 11.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41
11.6. Receiving a Data Indication with an ICMP attribute . . . 42 11.6. Receiving a Data Indication with an ICMP attribute . . . 42
12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 42 12. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44 12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 45
12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 45 12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 45
12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 46 12.3. Receiving a ChannelBind Response . . . . . . . . . . . . 46
12.4. The ChannelData Message . . . . . . . . . . . . . . . . 46 12.4. The ChannelData Message . . . . . . . . . . . . . . . . 46
12.5. Sending a ChannelData Message . . . . . . . . . . . . . 47 12.5. Sending a ChannelData Message . . . . . . . . . . . . . 47
12.6. Receiving a ChannelData Message . . . . . . . . . . . . 47 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 48
12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 49
13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 49 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 49
13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 49 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 49
13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 50 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 50
13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 51 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 52
14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 52 14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 52
15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 54 15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 54
16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 54 16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 54
16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 54 16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 55
16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 55 16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 55
16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 55 16.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 55
16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 55 16.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 55
16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 55 16.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 56
16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55 16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 56
16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56 16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56
16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56 16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 57
16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 57 16.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 57
16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 57 16.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 57
16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57 16.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57
16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 57 16.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 58
16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58 16.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58
17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 58 17. STUN Error Response Codes . . . . . . . . . . . . . . . . . . 59
18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 59 18. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60
19. Security Considerations . . . . . . . . . . . . . . . . . . . 67 19. Security Considerations . . . . . . . . . . . . . . . . . . . 68
19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 67 19.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68
19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 67 19.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68
19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 67 19.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68
19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 68 19.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69
19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 68 19.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69
19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 69 19.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70
19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 69 19.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70
19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 70 19.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 71
19.2. Firewall Considerations . . . . . . . . . . . . . . . . 70 19.2. Firewall Considerations . . . . . . . . . . . . . . . . 71
19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 71 19.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 72
19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 71 19.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 72
19.2.3. Running Servers on Well-Known Ports . . . . . . . . 72 19.2.3. Running Servers on Well-Known Ports . . . . . . . . 73
19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 72 19.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73
19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 72 19.3.1. DoS against TURN Server . . . . . . . . . . . . . . 73
19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 72 19.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 73
19.3.3. Manipulating Other Allocations . . . . . . . . . . . 73 19.3.3. Manipulating Other Allocations . . . . . . . . . . . 74
19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 73 19.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 74
19.5. Other Considerations . . . . . . . . . . . . . . . . . . 74 19.5. Other Considerations . . . . . . . . . . . . . . . . . . 75
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75 21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 76
22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 77 22. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 78
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
24.1. Normative References . . . . . . . . . . . . . . . . . . 77 24.1. Normative References . . . . . . . . . . . . . . . . . . 78
24.2. Informative References . . . . . . . . . . . . . . . . . 79 24.2. Informative References . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
1. Introduction 1. Introduction
A host behind a NAT may wish to exchange packets with other hosts, A host behind a NAT may wish to exchange packets with other hosts,
some of which may also be behind NATs. To do this, the hosts some of which may also be behind NATs. To do this, the hosts
involved can use "hole punching" techniques (see [RFC5128]) in an involved can use "hole punching" techniques (see [RFC5128]) in an
attempt discover a direct communication path; that is, a attempt discover a direct communication path; that is, a
communication path that goes from one host to another through communication path that goes from one host to another through
intervening NATs and routers, but does not traverse any relays. intervening NATs and routers, but does not traverse any relays.
skipping to change at page 23, line 19 skipping to change at page 23, line 19
UDP and TCP, and 5349 for TURN over (D)TLS. However, TURN has its UDP and TCP, and 5349 for TURN over (D)TLS. However, TURN has its
own set of Service Record (SRV) names: "turn" for UDP and TCP, and own set of Service Record (SRV) names: "turn" for UDP and TCP, and
"turns" for (D)TLS. Either the DNS resolution procedures or the "turns" for (D)TLS. Either the DNS resolution procedures or the
ALTERNATE-SERVER procedures, both described in Section 7, can be used ALTERNATE-SERVER procedures, both described in Section 7, can be used
to run TURN on a different port. to run TURN on a different port.
To ensure interoperability, a TURN server MUST support the use of UDP To ensure interoperability, a TURN server MUST support the use of UDP
transport between the client and the server, and SHOULD support the transport between the client and the server, and SHOULD support the
use of TCP, TLS-over-TCP and DTLS-over-UDP transports. use of TCP, TLS-over-TCP and DTLS-over-UDP transports.
When UDP transport is used between the client and the server, the When UDP or DTLS-over-UDP transport is used between the client and
client will retransmit a request if it does not receive a response the server, the client will retransmit a request if it does not
within a certain timeout period. Because of this, the server may receive a response within a certain timeout period. Because of this,
receive two (or more) requests with the same 5-tuple and same the server may receive two (or more) requests with the same 5-tuple
transaction id. STUN requires that the server recognize this case and same transaction id. STUN requires that the server recognize
and treat the request as idempotent (see [I-D.ietf-tram-stunbis]). this case and treat the request as idempotent (see
Some implementations may choose to meet this requirement by [I-D.ietf-tram-stunbis]). Some implementations may choose to meet
remembering all received requests and the corresponding responses for this requirement by remembering all received requests and the
40 seconds. Other implementations may choose to reprocess the corresponding responses for 40 seconds. Other implementations may
request and arrange that such reprocessing returns essentially the choose to reprocess the request and arrange that such reprocessing
same response. To aid implementors who choose the latter approach returns essentially the same response. To aid implementors who
(the so-called "stateless stack approach"), this specification choose the latter approach (the so-called "stateless stack
includes some implementation notes on how this might be done. approach"), this specification includes some implementation notes on
Implementations are free to choose either approach or choose some how this might be done. Implementations are free to choose either
other approach that gives the same results. approach or choose some other approach that gives the same results.
When TCP transport is used between the client and the server, it is When TCP transport is used between the client and the server, it is
possible that a bit error will cause a length field in a TURN packet possible that a bit error will cause a length field in a TURN packet
to become corrupted, causing the receiver to lose synchronization to become corrupted, causing the receiver to lose synchronization
with the incoming stream of TURN messages. A client or server that with the incoming stream of TURN messages. A client or server that
detects a long sequence of invalid TURN messages over TCP transport detects a long sequence of invalid TURN messages over TCP transport
SHOULD close the corresponding TCP connection to help the other end SHOULD close the corresponding TCP connection to help the other end
detect this situation more rapidly. detect this situation more rapidly.
To mitigate either intentional or unintentional denial-of-service To mitigate either intentional or unintentional denial-of-service
skipping to change at page 27, line 13 skipping to change at page 27, line 13
client MUST omit the EVEN-PORT attribute. client MUST omit the EVEN-PORT attribute.
Once constructed, the client sends the Allocate request on the Once constructed, the client sends the Allocate request on the
5-tuple. 5-tuple.
7.2. Receiving an Allocate Request 7.2. Receiving an Allocate Request
When the server receives an Allocate request, it performs the When the server receives an Allocate request, it performs the
following checks: following checks:
1. The server MUST require that the request be authenticated. This 1. The server SHOULD require that the request be authenticated.
authentication MUST be done using the long-term credential The authentication of the request is optional to allow TURN
mechanism of [I-D.ietf-tram-stunbis] unless the client and servers provided by the local or access network to accept
server agree to use another mechanism through some procedure Allocation requests from new and/or guest users in the network
outside the scope of this document. who do not necessarily possess long term credentials for STUN
authentication and its security implications are discussed in
[RFC8155]. If the request is authenticated, the authentication
MUST be done using the long-term credential mechanism of
[I-D.ietf-tram-stunbis] unless the client and server agree to
use another mechanism through some procedure outside the scope
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, the server rejects the
skipping to change at page 28, line 40 skipping to change at page 28, line 48
server can partially meet the request, i.e. if it can only server can partially meet the request, i.e. if it can only
allocate one relayed transport address of a specific address allocate one relayed transport address of a specific address
type, then it includes ADDRESS-ERROR-CODE attribute in the type, then it includes ADDRESS-ERROR-CODE attribute in the
response to inform the client the reason for partial failure of response to inform the client the reason for partial failure of
the request. The error code value signaled in the ADDRESS- the request. The error code value signaled in the ADDRESS-
ERROR-CODE attribute could be 440 (Address Family not Supported) ERROR-CODE attribute could be 440 (Address Family not Supported)
or 508 (Insufficient Capacity). If the server can fully meet or 508 (Insufficient Capacity). If the server can fully meet
the request, then the server allocates one IPv4 and one IPv6 the request, then the server allocates one IPv4 and one IPv6
relay address, and returns an Allocate success response relay address, and returns an Allocate success response
containing the relayed transport addresses assigned to the dual containing the relayed transport addresses assigned to the dual
allocation. allocation in two XOR-RELAYED-ADDRESS attributes.
10. At any point, the server MAY choose to reject the request with a 10. At any point, the server MAY choose to reject the request with a
486 (Allocation Quota Reached) error if it feels the client is 486 (Allocation Quota Reached) error if it feels the client is
trying to exceed some locally defined allocation quota. The trying to exceed some locally defined allocation quota. The
server is free to define this allocation quota any way it server is free to define this allocation quota any way it
wishes, but SHOULD define it based on the username used to wishes, but SHOULD define it based on the username used to
authenticate the request, and not on the client's transport authenticate the request, and not on the client's transport
address. address.
11. Also at any point, the server MAY choose to reject the request 11. Also at any point, the server MAY choose to reject the request
skipping to change at page 43, line 5 skipping to change at page 43, line 18
data using ChannelData messages, which have less overhead than Send data using ChannelData messages, which have less overhead than Send
and Data indications. and Data indications.
The ChannelData message (see Section 12.4) starts with a two-byte The ChannelData message (see Section 12.4) starts with a two-byte
field that carries the channel number. The values of this field are field that carries the channel number. The values of this field are
allocated as follows: allocated as follows:
0x0000 through 0x3FFF: These values can never be used for channel 0x0000 through 0x3FFF: These values can never be used for channel
numbers. numbers.
0x4000 through 0x7FFF: These values are the allowed channel 0x4000 through 0x4FFF: These values are the allowed channel
numbers (16,384 possible values). numbers (16,384 possible values).
0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision
avoidance, see [RFC7983].
0x8000 through 0xFFFF: These values are reserved for future use. 0x8000 through 0xFFFF: These values are reserved for future use.
Because of this division, ChannelData messages can be distinguished Because of this division, ChannelData messages can be distinguished
from STUN-formatted messages (e.g., Allocate request, Send from STUN-formatted messages (e.g., Allocate request, Send
indication, etc.) by examining the first two bits of the message: indication, etc.) by examining the first two bits of the message:
0b00: STUN-formatted message (since the first two bits of a STUN- 0b00: STUN-formatted message (since the first two bits of a STUN-
formatted message are always zero). formatted message are always zero).
0b01: ChannelData message (since the channel number is the first 0b01: ChannelData message (since the channel number is the first
skipping to change at page 60, line 32 skipping to change at page 61, line 32
| | | | | | | |
|--- 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="obMatJos2AAABadl7W7PeDU4hKE72jda" | | | NONCE="obMatJos2AAABadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | | | PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| MESSAGE-INTEGRITY-SHA256=... | | | | 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 | |
skipping to change at page 77, line 40 skipping to change at page 78, line 40
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 SSODA mechanism. Authors would
like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox and like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox,
Oleg Moskalenko for comments and review. The authors would like to Brandon Williams, Karl Stahl, Noriyuki Torii and Oleg Moskalenko for
thank Marc for his contributions to the text. comments and review. The authors would like to thank Marc for his
contributions to the text.
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-15 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-16
(work in progress), January 2018. (work in progress), March 2018.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 79, line 39 skipping to change at page 80, line 39
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-06 (work in progress), September ietf-tram-stun-pmtud-07 (work in progress), March 2018.
2017.
[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. 24 change blocks. 
75 lines changed or deleted 85 lines changed or added

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