draft-ietf-tram-turnbis-02.txt   draft-ietf-tram-turnbis-03.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: August 7, 2015 Avaya Expires: October 11, 2015 Avaya
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
February 3, 2015 April 9, 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-02 draft-ietf-tram-turnbis-03
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 August 7, 2015. This Internet-Draft will expire on October 11, 2015.
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 3, line 9 skipping to change at page 3, line 9
9.2. Receiving a CreatePermission Request . . . . . . . . . . 36 9.2. Receiving a CreatePermission Request . . . . . . . . . . 36
9.3. Receiving a CreatePermission Response . . . . . . . . . . 36 9.3. Receiving a CreatePermission Response . . . . . . . . . . 36
10. Send and Data 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 . . . . . . . . . . . . . . 37 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 37
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 38 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 38
10.4. Receiving a Data Indication . . . . . . . . . . . . . . 38 10.4. Receiving a Data Indication . . . . . . . . . . . . . . 38
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 41 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 41
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 41 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 41
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 43 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 42
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 43 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 43
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 43 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 43
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 44 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 44
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 45 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 45
12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 45 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 45
12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 45 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 45
12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 46 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 46
12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 48 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 47
13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 48 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 48
14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 50 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 50
15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 50 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 50
15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 51 15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 51
15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 51 15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 51
15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 51 15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 51
15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 51 15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 51
15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 52 15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 51
15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 52 15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 52
15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 52 15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 52
15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 53 15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 53
15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 53 15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 53
15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 54 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 53
15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 54 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 54
15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 55 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 54
16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 55 16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 55
17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 56 17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 56
18. Security Considerations . . . . . . . . . . . . . . . . . . . 63 18. Security Considerations . . . . . . . . . . . . . . . . . . . 63
18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 63 18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 63
18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 63 18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 63
18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 64 18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 64
18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 64 18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 64
18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 64 18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 64
18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 65 18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 65
18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 65 18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 65
skipping to change at page 32, line 42 skipping to change at page 32, line 42
MUST refresh it before it expires. It is suggested that the client MUST refresh it before it expires. It is suggested that the client
refresh the allocation roughly 1 minute before it expires. If a refresh the allocation roughly 1 minute before it expires. If a
client no longer wishes to use an allocation, then it SHOULD client no longer wishes to use an allocation, then it SHOULD
explicitly delete the allocation. A client MAY refresh an allocation explicitly delete the allocation. A client MAY refresh an allocation
at any time for other reasons. at any time for other reasons.
7.1. Sending a Refresh Request 7.1. Sending a Refresh Request
If the client wishes to immediately delete an existing allocation, it If the client wishes to immediately delete an existing allocation, it
includes a LIFETIME attribute with a value of 0. All other forms of includes a LIFETIME attribute with a value of 0. All other forms of
the request refresh the allocation. The client MUST NOT include any the request refresh the allocation.
REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request.
When refreshing a dual allocation, the client includes ADDITIONAL- When refreshing a dual allocation, the client includes REQUESTED-
ADDRESS-FAMILY attribute indicating the address family type that ADDRESS-FAMILY attribute indicating the address family type that
should be refreshed. If no ADDITIONAL-ADDRESS-FAMILY is included should be refreshed. If no REQUESTED-ADDRESS-FAMILY is included then
then the request should be treated as applying to all current the request should be treated as applying to all current allocations.
allocations. The client MUST only include family types it previously The client MUST only include family types it previously allocated and
allocated and has not yet deleted. This process can also be used to has not yet deleted. This process can also be used to delete an
delete an allocation of a specific address type, by setting the allocation of a specific address type, by setting the lifetime of
lifetime of that refresh request to 0. Deleting a single allocation that refresh request to 0. Deleting a single allocation destroys any
destroys any permissions or channels associated with that particular permissions or channels associated with that particular allocation;
allocation; it MUST NOT affect any permissions or channels associated it MUST NOT affect any permissions or channels associated with
with allocations for the other address family. allocations for the other address family.
The Refresh transaction updates the time-to-expiry timer of an The Refresh transaction updates the time-to-expiry timer of an
allocation. If the client wishes the server to set the time-to- allocation. If the client wishes the server to set the time-to-
expiry timer to something other than the default lifetime, it expiry timer to something other than the default lifetime, it
includes a LIFETIME attribute with the requested value. The server includes a LIFETIME attribute with the requested value. The server
then computes a new time-to-expiry value in the same way as it does then computes a new time-to-expiry value in the same way as it does
for an Allocate transaction, with the exception that a requested for an Allocate transaction, with the exception that a requested
lifetime of 0 causes the server to immediately delete the allocation. lifetime of 0 causes the server to immediately delete the allocation.
7.2. Receiving a Refresh Request 7.2. Receiving a Refresh Request
skipping to change at page 41, line 29 skipping to change at page 41, line 29
transaction. A ChannelBind transaction also creates or refreshes a transaction. A ChannelBind transaction also creates or refreshes a
permission towards the peer (see Section 8). permission towards the peer (see Section 8).
To initiate the ChannelBind transaction, the client forms a To initiate the ChannelBind transaction, the client forms a
ChannelBind request. The channel to be bound is specified in a ChannelBind request. The channel to be bound is specified in a
CHANNEL-NUMBER attribute, and the peer's transport address is CHANNEL-NUMBER attribute, and the peer's transport address is
specified in an XOR-PEER-ADDRESS attribute. Section 11.2 describes specified in an XOR-PEER-ADDRESS attribute. Section 11.2 describes
the restrictions on these attributes. The client MUST only include the restrictions on these attributes. The client MUST only include
an XOR-PEER-ADDRESS attribute with an address of the same address an XOR-PEER-ADDRESS attribute with an address of the same address
family as that of the relayed transport address for the allocation. family as that of the relayed transport address for the allocation.
For dual allocations obtained using the ADDITIONAL-FAMILY-ADDRESS
attribute, the client can include XOR-PEER-ADDRESS attributes with
addresses of IPv4 and IPv6 address families. When using dual
allocation, the peer addresses of those channels may be of different
families. Thus, a single 5-tuple session may create several IPv4
channels and several IPv6 channels.
Rebinding a channel to the same transport address that it is already Rebinding a channel to the same transport address that it is already
bound to provides a way to refresh a channel binding and the bound to provides a way to refresh a channel binding and the
corresponding permission without sending data to the peer. Note corresponding permission without sending data to the peer. Note
however, that permissions need to be refreshed more frequently than however, that permissions need to be refreshed more frequently than
channels. channels.
11.2. Receiving a ChannelBind Request 11.2. Receiving a ChannelBind Request
When the server receives a ChannelBind request, it processes as per When the server receives a ChannelBind request, it processes as per
skipping to change at page 54, line 19 skipping to change at page 54, line 10
server. The server includes this attribute in a success response to server. The server includes this attribute in a success response to
tell the client about the token, and the client includes this tell the client about the token, and the client includes this
attribute in a subsequent Allocate request to request the server use attribute in a subsequent Allocate request to request the server use
that relayed transport address for the allocation. that relayed transport address for the allocation.
The attribute value is 8 bytes and contains the token value. The attribute value is 8 bytes and contains the token value.
15.11. ADDITIONAL-ADDRESS-FAMILY 15.11. ADDITIONAL-ADDRESS-FAMILY
This attribute is used by clients to request the allocation of a IPv4 This attribute is used by clients to request the allocation of a IPv4
and IPv6 address type from a server. The following is the format of and IPv6 address type from a server. It is encoded in the same way
the ADDITIONAL-ADDRESS-FAMILY attribute. as REQUESTED-ADDRESS-FAMILY Section 15.6. The ADDITIONAL-ADDRESS-
FAMILY attribute MAY be present in Allocate or Refresh requests. The
0 1 2 3 attribute value of 0x02 (IPv6 address) is the only valid value in
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 Allocate request.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the ADDITIONAL-ADDRESS-FAMILY attribute is TBD-CA.
As specified in [RFC5389], attributes with values between 0x8000
and 0xFFFF are comprehension-optional, which means that the client
or server can safely ignore the attribute if they don't understand
it.
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6
addresses.
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.
The ADDITIONAL-ADDRESS-FAMILY attribute MAY be present in Allocate or
Refresh requests. The attribute value of 0x02 (IPv6 address) is the
only valid value in Allocate request.
15.12. ADDRESS-ERROR-CODE Attribute 15.12. ADDRESS-ERROR-CODE Attribute
This attribute is used by servers to signal the reason for not This attribute is used by servers to signal the reason for not
allocating the requested address family. The following is the format allocating the requested address family. The following is the format
of the ADDRESS-ERROR-CODE attribute. of the ADDRESS-ERROR-CODE attribute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Error code | Reserved | | Family | Rsvd |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the ADDRESS-ERROR-CODE attribute is TBD-CA. As Type: the type of the ADDRESS-ERROR-CODE attribute is TBD-CA. As
specified in [RFC5389], attributes with values between 0x8000 and specified in [RFC5389], attributes with values between 0x8000 and
0xFFFF are comprehension-optional, which means that the client or 0xFFFF are comprehension-optional, which means that the client or
server can safely ignore the attribute if they don't understand server can safely ignore the attribute if they don't understand
it. it.
Length: this 16-bit field contains the length of the attribute in Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes. bytes.
Family: there are two values defined for this field and specified in Family: there are two values defined for this field and specified in
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 [RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6
addresses. addresses.
Error code: this 8-bit field contains the reason server cannot Reserved: at this point, the 13 bits in the Reserved field MUST be
allocate one of the requested address types. The error code
values could be either 440 (unsupported address family) or 508
(insufficient capacity).
Reserved: at this point, the 16 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.
Class: The Class represents the hundreds digit of the error code and
is defined in section 15.6 of [RFC5389].
Number: this 8-bit field contains the reason server cannot allocate
one of the requested address types. The error code values could
be either 440 (unsupported address family) or 508 (insufficient
capacity). The number representation is defined in section 15.6
of [RFC5389].
Reason Phrase: The recommended reason phrases for error codes 440
and 508 are explained in Section 16.
The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate
responses. responses.
16. New STUN Error Response Codes 16. New STUN Error Response Codes
This document defines the following new error response codes: This document defines the following new error response codes:
403 (Forbidden): The request was valid but cannot be performed due 403 (Forbidden): The request was valid but cannot be performed due
to administrative or similar restrictions. to administrative or similar restrictions.
 End of changes. 18 change blocks. 
71 lines changed or deleted 48 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/