draft-ietf-tram-turnbis-01.txt   draft-ietf-tram-turnbis-02.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 2, 2015 Avaya Expires: August 7, 2015 Avaya
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
January 29, 2015 February 3, 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-01 draft-ietf-tram-turnbis-02
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 2, 2015. This Internet-Draft will expire on August 7, 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 2, line 50 skipping to change at page 2, line 50
6.4. Receiving an Allocate Error Response . . . . . . . . . . 30 6.4. Receiving an Allocate Error Response . . . . . . . . . . 30
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 32 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 32
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 32 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 32
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 33 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 33
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 35 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Forming a CreatePermission Request . . . . . . . . . . . 35 9.1. Forming a CreatePermission Request . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . 42 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 43
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 . . . . . . . . . . . . . . . 47 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 48
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 . . . . . . . . . . . . . . . . . . 51 15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 52
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 . . . . . . . . . . . . . . . . . . . 53 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 54
15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 54 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 54
15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 54 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 55
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 24, line 25 skipping to change at page 24, line 25
TOKEN attribute, for the reasons outlined in [RFC6156]. TOKEN attribute, for the reasons outlined in [RFC6156].
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 addresses then it includes an ADDITIONAL-ADDRESS-FAMILY transport addresses 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. that contains a RESERVATION-TOKEN attribute. Clients MUST NOT
include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
that contains a EVEN-PORT attribute with the R bit set to 1.
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 26, line 9 skipping to change at page 26, line 13
the server rejects the request with a 400 (Bad Request) error. the server rejects the request with a 400 (Bad Request) error.
7. If the server does not support the address family requested by 7. If the server does not support the address family requested by
the client in REQUESTED-ADDRESS-FAMILY or is disabled by local the client in REQUESTED-ADDRESS-FAMILY or is disabled by local
policy, it MUST generate an Allocate error response, and it MUST policy, it MUST generate an Allocate error response, and it MUST
include an ERROR-CODE attribute with the 440 (Address Family not include an ERROR-CODE attribute with the 440 (Address Family not
Supported) response code. If the REQUESTED-ADDRESS-FAMILY Supported) response code. If the REQUESTED-ADDRESS-FAMILY
attribute is absent, the server MUST allocate an IPv4 relayed attribute is absent, the server MUST allocate an IPv4 relayed
transport address for the TURN client. transport address for the TURN client.
8. The server checks if the request contains an ADDITIONAL-ADDRESS- 8. The server checks if the request contains an EVEN-PORT attribute
with the R bit set to 1. If yes, and the request also contains
an ADDITIONAL- ADDRESS-FAMILY attribute, the server rejects the
request with a 400 (Bad Request) error. Otherwise, the server
checks if it can satisfy the request (i.e., can allocate a
relayed transport address as described below). If the server
cannot satisfy the request, then the server rejects the request
with a 508 (Insufficient Capacity) error.
9. The server checks if the request contains an ADDITIONAL-ADDRESS-
FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4 FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4
address family), then the server rejects the request with a 400 address family), then the server rejects the request with a 400
(Bad Request) error. Otherwise, and the server checks if it can (Bad Request) error. Otherwise, and the server checks if it can
allocate relayed transport addresses of both address types. If allocate relayed transport addresses of both address types. If
the server cannot satisfy the request, then the server rejects the server cannot satisfy the request, then the server rejects
the request with a 508 (Insufficient Capacity) error. If the the request with a 508 (Insufficient Capacity) error. If the
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). or 508 (Insufficient Capacity).
9. 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.
10. 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
with a 300 (Try Alternate) error if it wishes to redirect the with a 300 (Try Alternate) error if it wishes to redirect the
client to a different server. The use of this error code and client to a different server. The use of this error code and
attribute follow the specification in [RFC5389]. attribute follow the specification in [RFC5389].
If all the checks pass, the server creates the allocation. The If all the checks pass, the server creates the allocation. The
5-tuple is set to the 5-tuple from the Allocate request, while the 5-tuple is set to the 5-tuple from the Allocate request, while the
list of permissions and the list of channels are initially empty. list of permissions and the list of channels are initially empty.
The server chooses a relayed transport address for the allocation as The server chooses a relayed transport address for the allocation as
follows: follows:
skipping to change at page 33, line 10 skipping to change at page 33, line 22
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
When the server receives a Refresh request, it processes it as per When the server receives a Refresh request, it processes it as per
Section 4 plus the specific rules mentioned here. Section 4 plus the specific rules mentioned here.
If the server receives a Refresh Request with a REQUESTED-ADDRESS-
FAMILY attribute, and the value of the attribute does not match the
address family of the allocation, the server MUST reply with a 443
(Peer Address Family Mismatch) Refresh error response.
If the server receives a Refresh Request with an ADDITIONAL-ADDRESS- If the server receives a Refresh Request with an ADDITIONAL-ADDRESS-
FAMILY attribute and the attribute value does not match the address FAMILY attribute and the attribute value does not match the address
family of the allocation, the server MUST reply with a 443 (Peer family of the allocation, the server MUST reply with a 443 (Peer
Address Family Mismatch) Refresh error response. Address Family Mismatch) Refresh error response.
The server computes a value called the "desired lifetime" as follows: The server computes a value called the "desired lifetime" as follows:
if the request contains a LIFETIME attribute and the attribute value if the request contains a LIFETIME attribute and the attribute value
is 0, then the "desired lifetime" is 0. Otherwise, if the request is 0, then the "desired lifetime" is 0. Otherwise, if the request
contains a LIFETIME attribute, then the server computes the minimum contains a LIFETIME attribute, then the server computes the minimum
of the client's requested lifetime and the server's maximum allowed of the client's requested lifetime and the server's maximum allowed
 End of changes. 15 change blocks. 
19 lines changed or deleted 25 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/