draft-ietf-tram-turnbis-06.txt   draft-ietf-tram-turnbis-07.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Johnston, Ed. Intended status: Standards Track A. Johnston, Ed.
Expires: March 14, 2016 Avaya Expires: March 24, 2016 Avaya
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
September 11, 2015 September 21, 2015
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-06 draft-ietf-tram-turnbis-07
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 March 14, 2016. This Internet-Draft will expire on March 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 51 skipping to change at page 2, line 51
6.4. Receiving an Allocate Error Response . . . . . . . . . . 31 6.4. Receiving an Allocate Error Response . . . . . . . . . . 31
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 33 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 33
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 33 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 33
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 34 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 34
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 36 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Forming a CreatePermission Request . . . . . . . . . . . 36 9.1. Forming a CreatePermission Request . . . . . . . . . . . 36
9.2. Receiving a CreatePermission Request . . . . . . . . . . 36 9.2. Receiving a CreatePermission Request . . . . . . . . . . 36
9.3. Receiving a CreatePermission Response . . . . . . . . . . 37 9.3. Receiving a CreatePermission Response . . . . . . . . . . 37
10. Send, Data and SendError Methods . . . . . . . . . . . . . . 37 10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 37
10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37 10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37
10.2. Receiving a Send Indication . . . . . . . . . . . . . . 38 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 38
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 39 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 39
10.4. Receiving a Data Indication . . . . . . . . . . . . . . 39 10.4. Receiving a Data Indication with DATA attribute . . . . 39
10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40 10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40
10.6. Receiving a SendError Indication . . . . . . . . . . . . 40 10.6. Receiving a Data Indication with an ICMP attribute . . . 40
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 42 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 43
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 43 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 43
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 44 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 44
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 44 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 44
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 45 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 45
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 46 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 46
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 47 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 47
12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 47 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 47
12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 47 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 47
12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 48 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 48
12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 49 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 49
13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 50 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 50
14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 52 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 52
15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 52 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 52
15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 53 15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 53
15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 53 15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 53
15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 53 15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 53
15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 53 15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 53
15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 54 15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 53
15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 54 15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 54
15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 54 15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 54
15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 55 15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 55
15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 55 15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 55
15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 56 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 55
15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 56 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 56
15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 56 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 56
15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 57 15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 57
16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 58 16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 57
17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 58 17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 58
18. Security Considerations . . . . . . . . . . . . . . . . . . . 65 18. Security Considerations . . . . . . . . . . . . . . . . . . . 65
18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 65 18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 65
18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 65 18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 65
18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 66 18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 66
18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 66 18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 66
18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 66 18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 66
18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 67 18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 67
18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 67 18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 67
18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 68 18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 68
skipping to change at page 13, line 9 skipping to change at page 13, line 9
In the reverse direction, UDP datagrams arriving at the relayed In the reverse direction, UDP datagrams arriving at the relayed
transport address on the TURN server are converted into Data transport address on the TURN server are converted into Data
indications and sent to the client, with the server-reflexive indications and sent to the client, with the server-reflexive
transport address of the peer included in an XOR-PEER-ADDRESS transport address of the peer included in an XOR-PEER-ADDRESS
attribute and the data itself in a DATA attribute. Since the relayed attribute and the data itself in a DATA attribute. Since the relayed
transport address uniquely identified the allocation, the server transport address uniquely identified the allocation, the server
knows which client should receive the data. knows which client should receive the data.
Some ICMP (Internet Control Message Protocol) packets arriving at the Some ICMP (Internet Control Message Protocol) packets arriving at the
relayed transport address on the TURN server may be converted into relayed transport address on the TURN server may be converted into
SendError indications and sent to the client, with the transport Data indications and sent to the client, with the transport address
address of the peer included in an XOR-PEER-ADDRESS attribute and the of the peer included in an XOR-PEER-ADDRESS attribute and the ICMP
ICMP type and code in a ICMP attribute. SendError indications are type and code in a ICMP attribute. Data indications containing the
also sent when using the channel machanism. XOR-PEER-ADDRESS and ICMP attribute are also sent when using the
channel machanism.
Send and Data indications cannot be authenticated, since the long- Send and Data indications cannot be authenticated, since the long-
term credential mechanism of STUN does not support authenticating term credential mechanism of STUN does not support authenticating
indications. This is not as big an issue as it might first appear, indications. This is not as big an issue as it might first appear,
since the client-to-server leg is only half of the total path to the since the client-to-server leg is only half of the total path to the
peer. Applications that want proper security should encrypt the data peer. Applications that want proper security should encrypt the data
sent between the client and a peer. sent between the client and a peer.
Because Send indications are not authenticated, it is possible for an Because Send indications are not authenticated, it is possible for an
attacker to send bogus Send indications to the server, which will attacker to send bogus Send indications to the server, which will
skipping to change at page 37, line 37 skipping to change at page 37, line 37
idempotency of CreatePermission requests over UDP using the idempotency of CreatePermission requests over UDP using the
"stateless stack approach". Retransmitted CreatePermission "stateless stack approach". Retransmitted CreatePermission
requests will simply refresh the permissions. requests will simply refresh the permissions.
9.3. Receiving a CreatePermission Response 9.3. Receiving a CreatePermission Response
If the client receives a valid CreatePermission success response, If the client receives a valid CreatePermission success response,
then the client updates its data structures to indicate that the then the client updates its data structures to indicate that the
permissions have been installed or refreshed. permissions have been installed or refreshed.
10. Send, Data and SendError Methods 10. Send and Data Methods
TURN supports two mechanisms for sending and receiving data from TURN supports two mechanisms for sending and receiving data from
peers. This section describes the use of the Send and Data peers. This section describes the use of the Send and Data
mechanisms, while Section 11 describes the use of the Channel mechanisms, while Section 11 describes the use of the Channel
mechanism. mechanism.
10.1. Forming a Send Indication 10.1. Forming a Send Indication
The client can use a Send indication to pass data to the server for The client can use a Send indication to pass data to the server for
relaying to a peer. A client may use a Send indication even if a relaying to a peer. A client may use a Send indication even if a
skipping to change at page 39, line 31 skipping to change at page 39, line 31
described in Section 11.7. described in Section 11.7.
If relaying is permitted but no channel is bound to the peer, then If relaying is permitted but no channel is bound to the peer, then
the server forms and sends a Data indication. The Data indication the server forms and sends a Data indication. The Data indication
MUST contain both an XOR-PEER-ADDRESS and a DATA attribute. The DATA MUST contain both an XOR-PEER-ADDRESS and a DATA attribute. The DATA
attribute is set to the value of the 'data octets' field from the attribute is set to the value of the 'data octets' field from the
datagram, and the XOR-PEER-ADDRESS attribute is set to the source datagram, and the XOR-PEER-ADDRESS attribute is set to the source
transport address of the received UDP datagram. The Data indication transport address of the received UDP datagram. The Data indication
is then sent on the 5-tuple associated with the allocation. is then sent on the 5-tuple associated with the allocation.
10.4. Receiving a Data Indication 10.4. Receiving a Data Indication with DATA attribute
When the client receives a Data indication, it checks that the Data When the client receives a Data indication with DATA attribute, it
indication contains both an XOR-PEER-ADDRESS and a DATA attribute, checks that the Data indication contains an XOR-PEER-ADDRESS
and discards the indication if it does not. The client SHOULD also attribute, and discards the indication if it does not. The client
check that the XOR-PEER-ADDRESS attribute value contains an IP SHOULD also check that the XOR-PEER-ADDRESS attribute value contains
address with which the client believes there is an active permission, an IP address with which the client believes there is an active
and discard the Data indication otherwise. Note that the DATA permission, and discard the Data indication otherwise. Note that the
attribute is allowed to contain zero bytes of data. DATA attribute is allowed to contain zero bytes of data.
NOTE: The latter check protects the client against an attacker who NOTE: The latter check protects the client against an attacker who
somehow manages to trick the server into installing permissions somehow manages to trick the server into installing permissions
not desired by the client. not desired by the client.
If the Data indication passes the above checks, the client delivers If the Data indication passes the above checks, the client delivers
the data octets inside the DATA attribute to the application, along the data octets inside the DATA attribute to the application, along
with an indication that they were received from the peer whose with an indication that they were received from the peer whose
transport address is given by the XOR-PEER-ADDRESS attribute. transport address is given by the XOR-PEER-ADDRESS attribute.
10.5. Receiving an ICMP Packet 10.5. Receiving an ICMP Packet
When the server receives an ICMP packet at a currently allocated When the server receives an ICMP packet, the server verifies that the
relayed transport address, the server verifies that the type is type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either
either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either 1, 2, or 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the
3 for an ICMPv6 [RFC4443] packet. It also verifies that the IP IP packet in the ICMP packet payload contains a UDP header. If
packet in the ICMP packet payload contain an UDP header. If either either of these conditions fail, then the ICMP packet is silently
of these conditions fail, then the ICMP packet is silently dropped. dropped.
The server looks up the allocation associated with the relayed The server looks up the allocation whose relayed transport address
transport address. The server then checks to see whether the set of corresponds to the encapsulated packet's source IP address and UDP
permissions for the allocation allows the relaying of the ICMP packet port. If no such allocation exists, the packet is silently dropped.
as described in Section 8. The server then checks to see whether the set of permissions for the
allocation allows the relaying of the ICMP packet. For ICMP packets,
the source IP address MUST NOT be checked against the permissions
list as it would be for UDP packets. Instead, the server extracts
the destination IP address from the encapsulated IP header. The
server then compares this address with the IP address associated with
each permission in the list of permissions for the allocation. If no
match is found, relaying is not permitted, and the server silently
discards the ICMP packet. Note that only addresses are compared and
port numbers are not considered.
If relaying is permitted then the server forms and sends a SendError If relaying is permitted then the server forms and sends a Data
indication. The SendError indication MUST contain both an XOR-PEER- indication. The Data indication MUST contain both an XOR-PEER-
ADDRESS and an ICMP attribute. The ICMP attribute is set to the ADDRESS and an ICMP attribute. The ICMP attribute is set to the
value of the type and code fields from the ICMP packet, and the XOR- value of the type and code fields from the ICMP packet, and the XOR-
PEER-ADDRESS attribute is set to the destination IP address in the IP PEER-ADDRESS attribute is set to the destination IP address in the IP
header and to the destination port in the UDP header. Both are found header and to the destination port in the UDP header. Both are found
in the ICMP packet payload. The SendError indication is then sent on in the ICMP packet payload. The Data indication is then sent on the
the 5-tuple associated with the allocation. 5-tuple associated with the allocation.
10.6. Receiving a SendError Indication 10.6. Receiving a Data Indication with an ICMP attribute
When the client receives a SendError indication, it checks that the When the client receives a Data indication with an ICMP attribute, it
SendError indication contains both an XOR-PEER-ADDRESS and an ICMP checks that the Data indication contains an XOR-PEER-ADDRESS
attribute, and discards the indication if it does not. The client attribute, and discards the indication if it does not. The client
SHOULD also check that the XOR-PEER-ADDRESS attribute value contains SHOULD also check that the XOR-PEER-ADDRESS attribute value contains
an IP address with an active permission, and discard the SendError an IP address with an active permission, and discard the Data
indication otherwise. indication otherwise.
If the SendError indication passes the above checks, the client If the Data indication passes the above checks, the client signals
signals the application of the error condition, along with an the application of the error condition, along with an indication that
indication that it was received from the peer whose transport address it was received from the peer whose transport address is given by the
is given by the XOR-PEER-ADDRESS attribute. The application can make XOR-PEER-ADDRESS attribute. The application can make sense of the
sense of the meaning of the type and code values in the ICMP meaning of the type and code values in the ICMP attribute by using
attribute by using the family field in the XOR-PEER-ADDRESS the family field in the XOR-PEER-ADDRESS attribute.
attribute.
11. Channels 11. Channels
Channels provide a way for the client and server to send application Channels provide a way for the client and server to send application
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 11.4) starts with a two-byte The ChannelData message (see Section 11.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:
skipping to change at page 45, line 37 skipping to change at page 45, line 37
send to the peer, or that the peer is sending to the client. send to the peer, or that the peer is sending to the client.
11.5. Sending a ChannelData Message 11.5. Sending a ChannelData Message
Once a client has bound a channel to a peer, then when the client has Once a client has bound a channel to a peer, then when the client has
data to send to that peer it may use either a ChannelData message or data to send to that peer it may use either a ChannelData message or
a Send indication; that is, the client is not obligated to use the a Send indication; that is, the client is not obligated to use the
channel when it exists and may freely intermix the two message types channel when it exists and may freely intermix the two message types
when sending data to the peer. The server, on the other hand, MUST when sending data to the peer. The server, on the other hand, MUST
use the ChannelData message if a channel has been bound to the peer. use the ChannelData message if a channel has been bound to the peer.
The server uses a Data indication to signal the XOR-PEER-ADDRESS and
ICMP attributes to the client even if a channel has been bound to the
peer.
The fields of the ChannelData message are filled in as described in The fields of the ChannelData message are filled in as described in
Section 11.4. Section 11.4.
Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to
a multiple of four bytes in order to ensure the alignment of a multiple of four bytes in order to ensure the alignment of
subsequent messages. The padding is not reflected in the length subsequent messages. The padding is not reflected in the length
field of the ChannelData message, so the actual size of a ChannelData field of the ChannelData message, so the actual size of a ChannelData
message (including padding) is (4 + Length) rounded up to the nearest message (including padding) is (4 + Length) rounded up to the nearest
multiple of 4. Over UDP, the padding is not required but MAY be multiple of 4. Over UDP, the padding is not required but MAY be
skipping to change at page 47, line 14 skipping to change at page 47, line 14
11.7. Relaying Data from the Peer 11.7. Relaying Data from the Peer
When the server receives a UDP datagram on the relayed transport When the server receives a UDP datagram on the relayed transport
address associated with an allocation, the server processes it as address associated with an allocation, the server processes it as
described in Section 10.3. If that section indicates that a described in Section 10.3. If that section indicates that a
ChannelData message should be sent (because there is a channel bound ChannelData message should be sent (because there is a channel bound
to the peer that sent to the UDP datagram), then the server forms and to the peer that sent to the UDP datagram), then the server forms and
sends a ChannelData message as described in Section 11.5. sends a ChannelData message as described in Section 11.5.
When the server receives an ICMP packet on the relayed transport When the server receives an ICMP packet, the server processes it as
address associated with an allocation, the server processes it as described in Section 10.5. A Data indication MUST be sent regardless
described in Section 10.5. A SendError indication MUST be sent if there is a channel bound to the peer that was the destination of
regardless if there is a channel bound to the peer that was the the UDP datagram that triggered the reception of the ICMP packet.
destination of the UDP datagram that triggered the reception of the
ICMP packet.
12. Packet Translations 12. Packet Translations
As discussed in Section 2.6, translations in TURN are designed so As discussed in Section 2.6, translations in TURN are designed so
that a TURN server can be implemented as an application that runs in that a TURN server can be implemented as an application that runs in
userland under commonly available operating systems and that does not userland under commonly available operating systems and that does not
require special privileges. The translations specified in the require special privileges. The translations specified in the
following sections follow this principle. following sections follow this principle.
The descriptions below have two parts: a preferred behavior and an The descriptions below have two parts: a preferred behavior and an
skipping to change at page 52, line 28 skipping to change at page 52, line 24
This section lists the codepoints for the new STUN methods defined in This section lists the codepoints for the new STUN methods defined in
this specification. See elsewhere in this document for the semantics this specification. See elsewhere in this document for the semantics
of these new methods. of these new methods.
0x003 : Allocate (only request/response semantics defined) 0x003 : Allocate (only request/response semantics defined)
0x004 : Refresh (only request/response semantics defined) 0x004 : Refresh (only request/response semantics defined)
0x006 : Send (only indication semantics defined) 0x006 : Send (only indication semantics defined)
0x007 : Data (only indication semantics defined) 0x007 : Data (only indication semantics defined)
0x008 : CreatePermission (only request/response semantics defined 0x008 : CreatePermission (only request/response semantics defined
0x009 : ChannelBind (only request/response semantics defined) 0x009 : ChannelBind (only request/response semantics defined)
TBD-DA : SendError (only indication semantics defined)
15. New STUN Attributes 15. New STUN Attributes
This STUN extension defines the following new attributes: This STUN extension defines the following new attributes:
0x000C: CHANNEL-NUMBER 0x000C: CHANNEL-NUMBER
0x000D: LIFETIME 0x000D: LIFETIME
0x0010: Reserved (was BANDWIDTH) 0x0010: Reserved (was BANDWIDTH)
0x0012: XOR-PEER-ADDRESS 0x0012: XOR-PEER-ADDRESS
0x0013: DATA 0x0013: DATA
skipping to change at page 75, line 47 skipping to change at page 75, line 47
22. Acknowledgements 22. 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 orginal TURN specification and everyone who had co-author of orginal TURN specification and everyone who had
contributed to that document. contributed to that document.
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 for comments and review. The authors like to thank Gonzalo Salgueiro, Simon Perreault and Jonathan Lennox
would like to thank Marc for his contributions to the text. for comments and review. The authors would like to thank Marc for
his contributions to the text.
23. References 23. References
23.1. Normative References 23.1. Normative References
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>. <http://www.rfc-editor.org/info/rfc5389>.
 End of changes. 26 change blocks. 
59 lines changed or deleted 69 lines changed or added

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