draft-ietf-tram-turnbis-13.txt   draft-ietf-tram-turnbis-14.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 15, 2018 P. Matthews Expires: August 26, 2018 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
February 11, 2018 February 22, 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-13 draft-ietf-tram-turnbis-14
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
the relay. TURN differs from some other relay control protocols in the relay. TURN differs from some other relay control protocols in
that it allows a client to communicate with multiple peers using a that it allows a client to communicate with multiple peers using a
single relay address. single relay address.
The TURN protocol was designed to be used as part of the ICE The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal, (Interactive Connectivity Establishment) approach to NAT traversal,
though it also can be used without ICE. though it also can be used without ICE.
This document obsoletes [RFC5766] and [RFC6156]. This document obsoletes RFC 5766 and RFC 6156.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 15, 2018. This Internet-Draft will expire on August 26, 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 41 skipping to change at page 2, line 41
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . 26 7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 27
7.3. Receiving an Allocate Success Response . . . . . . . . . 31 7.3. Receiving an Allocate Success Response . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Forming a CreatePermission Request . . . . . . . . . . . 37 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 . . . . . . . . . 38 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 . . . . . . . . . . . . . . 39
11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40 11.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40
11.4. Receiving a Data Indication . . . . . . . . . . . . . . 40 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44 12.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44
12.2. Receiving a ChannelBind Request . . . . . . . . . . . . 44 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 . . . . . . . . . . . . . 46 12.5. Sending a ChannelData Message . . . . . . . . . . . . . 47
12.6. Receiving a ChannelData Message . . . . . . . . . . . . 47 12.6. Receiving a ChannelData Message . . . . . . . . . . . . 47
12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48 12.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48
13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 48 13. Packet Translations . . . . . . . . . . . . . . . . . . . . . 49
13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 49 13.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 49
13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 49 13.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 50
13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 51 13.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 51
14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 52 14. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 52
15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 53 15. STUN Methods . . . . . . . . . . . . . . . . . . . . . . . . 54
16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 54 16. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 54
16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 54 16.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 54
16.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 54 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 . . . . . . . . . . . . . . . . . . 55
16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55 16.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55
16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56 16.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56
16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56 16.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56
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 . . . . . . . . . . . . . . 57
skipping to change at page 15, line 13 skipping to change at page 15, line 13
the client must simply wait for it to time out. the client must simply wait for it to time out.
TURN TURN Peer Peer TURN TURN Peer Peer
client server A B client server A B
| | | | | | | |
|-- ChannelBind req ---------------->| | | |-- ChannelBind req ---------------->| | |
| (Peer A to 0x4001) | | | | (Peer A to 0x4001) | | |
| | | | | | | |
|<---------- ChannelBind succ resp --| | | |<---------- ChannelBind succ resp --| | |
| | | | | | | |
|-- [0x4001] data ------------------>| | | |-- (0x4001) data ------------------>| | |
| |=== data ===>| | | |=== data ===>| |
| | | | | | | |
| |<== data ====| | | |<== data ====| |
|<------------------ (0x4001) data --| | | |<------------------ (0x4001) data --| | |
| | | | | | | |
|--- Send ind (Peer A)-------------->| | | |--- Send ind (Peer A)-------------->| | |
| |=== data ===>| | | |=== data ===>| |
| | | | | | | |
| |<== data ====| | | |<== data ====| |
|<------------------ (0x4001) data --| | | |<------------------ (0x4001) data --| | |
skipping to change at page 18, line 31 skipping to change at page 18, line 31
2.9. Happy Eyeballs for TURN 2.9. Happy Eyeballs for TURN
If an IPv4 path to reach a TURN server is found, but the TURN If an IPv4 path to reach a TURN server is found, but the TURN
server's IPv6 path is not working, a dual-stack TURN client can server's IPv6 path is not working, a dual-stack TURN client can
experience a significant connection delay compared to an IPv4-only experience a significant connection delay compared to an IPv4-only
TURN client. To overcome these connection setup problems, the TURN TURN client. To overcome these connection setup problems, the TURN
client MUST query both A and AAAA records for the TURN server client MUST query both A and AAAA records for the TURN server
specified using a domain name and try connecting to the TURN server specified using a domain name and try connecting to the TURN server
using both IPv6 and IPv4 addresses in a fashion similar to the Happy using both IPv6 and IPv4 addresses in a fashion similar to the Happy
Eyeballs mechanism defined in [RFC6555]. The TURN client performs Eyeballs mechanism defined in [RFC8305]. The TURN client performs
the following steps based on the transport protocol being used to the following steps based on the transport protocol being used to
connect to the TURN server. connect to the TURN server.
o For TCP or TLS-over-TCP, initiate TCP connection to both IP o For TCP or TLS-over-TCP, initiate TCP connection to both IP
address families as discussed in [RFC6555], and use the first TCP address families as discussed in [RFC8305], and use the first TCP
connection that is established. If connections are established on connection that is established. If connections are established on
both IP address families then terminate the TCP connection using both IP address families then terminate the TCP connection using
the IP address family with lower precedence [RFC6724]. the IP address 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 [RFC8305], 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 can silently abandon the UDP address families then the TURN client can silently abandon the UDP
connection on the IP address family with lower precedence. If the connection on the IP address family with lower precedence. If 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 [RFC8305] 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 address families then the client sends DTLS close_notify alert IP address families then the client sends DTLS close_notify alert
to terminate the DTLS session using the IP address family with to terminate the DTLS session using the IP address family with
lower precedence. If TURN over DTLS server has been configured to lower precedence. If TURN over DTLS server has been configured to
require a cookie exchange (Section 4.2 in [RFC6347]) and require a cookie exchange (Section 4.2 in [RFC6347]) and
HelloVerifyRequest is received from the TURN servers on both IP HelloVerifyRequest is received from the TURN servers on both IP
address families then the client can silently abandon the address families then the client can silently abandon the
connection on the IP address family with lower precedence. connection on the IP address family with lower precedence.
3. Terminology 3. Terminology
skipping to change at page 24, line 33 skipping to change at page 24, line 33
address. address.
The relayed transport address is the transport address allocated by The relayed transport address is the transport address allocated by
the server for communicating with peers, while the 5-tuple describes the server for communicating with peers, while the 5-tuple describes
the communication path between the client and the server. On the the communication path between the client and the server. On the
client, the 5-tuple uses the client's host transport address; on the client, the 5-tuple uses the client's host transport address; on the
server, the 5-tuple uses the client's server-reflexive transport server, the 5-tuple uses the client's server-reflexive transport
address. The relayed transport address MUST be unique across all address. The relayed transport address MUST be unique across all
allocations, so it can be used to uniquely identify the allocation. allocations, so it can be used to uniquely identify the allocation.
Both the relayed transport address and the 5-tuple MUST be unique
across all allocations, so either one can be used to uniquely
identify the allocation, and an allocation in this context can be
either a single or dual allocation.
The authentication information (e.g., username, password, realm, and The authentication information (e.g., username, password, realm, and
nonce) is used to both verify subsequent requests and to compute the nonce) is used to both verify subsequent requests and to compute the
message integrity of responses. The username, realm, and nonce message integrity of responses. The username, realm, and nonce
values are initially those used in the authenticated Allocate request values are initially those used in the authenticated Allocate request
that creates the allocation, though the server can change the nonce that creates the allocation, though the server can change the nonce
value during the lifetime of the allocation using a 438 (Stale Nonce) value during the lifetime of the allocation using a 438 (Stale Nonce)
reply. Note that, rather than storing the password explicitly, for reply. Note that, rather than storing the password explicitly, for
security reasons, it may be desirable for the server to store the key security reasons, it may be desirable for the server to store the key
value, which is a secure hash over the username, realm, and password value, which is a secure hash over the username, realm, and password
(see [I-D.ietf-tram-stunbis]). (see [I-D.ietf-tram-stunbis]).
skipping to change at page 26, line 15 skipping to change at page 26, line 20
If the client wishes to obtain one IPv6 and one IPv4 relayed If the client wishes to obtain one IPv6 and one IPv4 relayed
transport address then it includes an ADDITIONAL-ADDRESS-FAMILY transport address then it includes an ADDITIONAL-ADDRESS-FAMILY
attribute in the request. This attribute specifies that the server attribute in the request. This attribute specifies that the server
must allocate both address types. The attribute value in the must allocate both address types. The attribute value in the
ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family).
Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
ADDRESS-FAMILY attributes in the same request. Clients MUST NOT ADDRESS-FAMILY attributes in the same request. Clients MUST NOT
include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
that contains a RESERVATION-TOKEN attribute. Clients MUST NOT that contains a RESERVATION-TOKEN attribute. Clients MUST NOT
include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
that contains an EVEN-PORT attribute with the R bit set to 1. that contains an EVEN-PORT attribute with the R bit set to 1. The
reason behind the restriction is if EVEN-PORT with R bit set to 1 is
allowed with the ADDITIONAL-ADDRESS-FAMILY attribute, two tokens will
have to be returned in success response and requires changes to the
way RESERVATION-TOKEN is handled.
If the client wishes the server to initialize the time-to-expiry If the client wishes the server to initialize the time-to-expiry
field of the allocation to some value other than the default field of the allocation to some value other than the default
lifetime, then it MAY include a LIFETIME attribute specifying its lifetime, then it MAY include a LIFETIME attribute specifying its
desired value. This is just a hint, and the server may elect to use desired value. This is just a hint, and the server may elect to use
a different value. Note that the server will ignore requests to a different value. Note that the server will ignore requests to
initialize the field to less than the default value. initialize the field to less than the default value.
If the client wishes to later use the DONT-FRAGMENT attribute in one If the client wishes to later use the DONT-FRAGMENT attribute in one
or more Send indications on this allocation, then the client SHOULD or more Send indications on this allocation, then the client SHOULD
skipping to change at page 55, line 30 skipping to change at page 55, line 44
16.5. XOR-RELAYED-ADDRESS 16.5. XOR-RELAYED-ADDRESS
The XOR-RELAYED-ADDRESS is present in Allocate responses. It The XOR-RELAYED-ADDRESS is present in Allocate responses. It
specifies the address and port that the server allocated to the specifies the address and port that the server allocated to the
client. It is encoded in the same way as XOR-MAPPED-ADDRESS client. It is encoded in the same way as XOR-MAPPED-ADDRESS
[I-D.ietf-tram-stunbis]. [I-D.ietf-tram-stunbis].
16.6. REQUESTED-ADDRESS-FAMILY 16.6. REQUESTED-ADDRESS-FAMILY
This attribute is used by clients to request the allocation or This attribute is used in Allocate and Refresh requests to specify
refresh of a specific address type from a server. The value of this the address type requested by the client. The value of this
attribute is 4 bytes with the following format: attribute is 4 bytes with the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved | | Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family: there are two values defined for this field and specified in Family: there are two values defined for this field and specified in
[I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and [I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and
0x02 for IPv6 addresses. 0x02 for IPv6 addresses.
Reserved: at this point, the 24 bits in the Reserved field MUST be Reserved: at this point, the 24 bits in the Reserved field MUST be
set to zero by the client and MUST be ignored by the server. set to zero by the client and MUST be ignored by the server.
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
requests.
16.7. EVEN-PORT 16.7. EVEN-PORT
This attribute allows the client to request that the port in the This attribute allows the client to request that the port in the
relayed transport address be even, and (optionally) that the server relayed transport address be even, and (optionally) that the server
reserve the next-higher port number. The value portion of this reserve the next-higher port number. The value portion of this
attribute is 1 byte long. Its format is: attribute is 1 byte long. Its format is:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 58, line 17 skipping to change at page 58, line 24
Number: this 8-bit field contains the reason server cannot allocate Number: this 8-bit field contains the reason server cannot allocate
one of the requested address types. The error code values could one of the requested address types. The error code values could
be either 440 (unsupported address family) or 508 (insufficient be either 440 (unsupported address family) or 508 (insufficient
capacity). The number representation is defined in section 14.8 capacity). The number representation is defined in section 14.8
of [I-D.ietf-tram-stunbis]. of [I-D.ietf-tram-stunbis].
Reason Phrase: The recommended reason phrases for error codes 440 Reason Phrase: The recommended reason phrases for error codes 440
and 508 are explained in Section 17. and 508 are explained in Section 17.
The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate
responses.
16.13. ICMP Attribute 16.13. ICMP Attribute
This attribute is used by servers to signal the reason an UDP packet This attribute is used by servers to signal the reason an UDP packet
was dropped. The following is the format of the ICMP attribute. was dropped. The following is the format of the ICMP attribute.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ICMP Type | ICMP Code | | Reserved | ICMP Type | ICMP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 74, line 5 skipping to change at page 74, line 5
Then he has set up an amplification attack: Then he has set up an amplification attack:
o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it
to the tunnel endpoint to the tunnel endpoint
o The tunnel endpoint will de-encapsulate packets from the v4 o The tunnel endpoint will de-encapsulate packets from the v4
interface and send them to v6 interface and send them to v6
So if the attacker sends a packet of the following form... So if the attacker sends a packet of the following form...
IPv6: src=2001:DB9::1 dst=2001:DB8::2 IPv6: src=2001:DB8:1::1 dst=2001:DB8::2
UDP: <ports> UDP: <ports>
TURN: <channel id> TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2 IPv6: src=2001:DB8:1::1 dst=2001:DB8::2
UDP: <ports> UDP: <ports>
TURN: <channel id> TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2 IPv6: src=2001:DB8:1::1 dst=2001:DB8::2
UDP: <ports> UDP: <ports>
TURN: <channel id> TURN: <channel id>
... ...
Then the TURN relay and the tunnel endpoint will send it back and Then the TURN relay and the tunnel endpoint will send it back and
forth until the last TURN header is consumed, at which point the TURN forth until the last TURN header is consumed, at which point the TURN
relay will send an empty packet, which the tunnel endpoint will drop. relay will send an empty packet, which the tunnel endpoint will drop.
The amplification potential here is limited by the MTU, so it's not The amplification potential here is limited by the MTU, so it's not
huge: IPv6+UDP+TURN takes 334 bytes, so a four-to-one amplification huge: IPv6+UDP+TURN takes 334 bytes, so a four-to-one amplification
skipping to change at page 79, line 10 skipping to change at page 79, line 10
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P.
Jones, "Traversal Using Relays around NAT (TURN) Uniform Jones, "Traversal Using Relays around NAT (TURN) Uniform
Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065, Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065,
November 2013, <https://www.rfc-editor.org/info/rfc7065>. November 2013, <https://www.rfc-editor.org/info/rfc7065>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>. <https://www.rfc-editor.org/info/rfc7915>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
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-06 (work in progress), September
 End of changes. 31 change blocks. 
37 lines changed or deleted 41 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/