RFC-5766TraversalUsingRelaysaroundNAT(TURN)资源-CSDN文库

需积分: 1 144 浏览量 2023-08-07 10:42:56 上传评论收藏 108KB PDF 举报

资源推荐

资源详情

资源评论

Internet Engineering Task Force (IETF) R. Mahy

Request for Comments: 5766 Unaffiliated

Category: Standards Track P. Matthews

ISSN: 2070-1721 Alcatel-Lucent

J. Rosenberg

jdrosen.net

April 2010

Traversal Using Relays around NAT (TURN):

Relay Extensions to Session Traversal Utilities for NAT (STUN)

Abstract

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

(peers). In these situations, it is necessary for the host to use

the services of an intermediate node that acts as a communication

relay. This specification defines a protocol, called TURN (Traversal

Using Relays around NAT), that allows the host to control the

operation of the relay and to exchange packets with its peers using

the relay. TURN differs from some other relay control protocols in

that it allows a client to communicate with multiple peers using a

single relay address.

The TURN protocol was designed to be used as part of the ICE

(Interactive Connectivity Establishment) approach to NAT traversal,

though it also can be used without ICE.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force

(IETF). It represents the consensus of the IETF community. It has

received public review and has been approved for publication by the

Internet Engineering Steering Group (IESG). Further information on

Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,

and how to provide feedback on it may be obtained at

http://www.rfc-editor.org/info/rfc5766.

Mahy, et al. Standards Track [Page 1]

RFC 5766 TURN April 2010

This document is subject to BCP 78 and the IETF Trust’s Legal

Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect

to this document. Code Components extracted from this document must

include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5

2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11

2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . . 12

2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 15

2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16

2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 17

2.9. Anycast Discovery of Servers . . . . . . . . . . . . . . . 17

3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18

4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 19

5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22

6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 23

6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 23

6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 24

6.3. Receiving an Allocate Success Response . . . . . . . . . . 28

6.4. Receiving an Allocate Error Response . . . . . . . . . . . 29

7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 31

7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 31

7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 31

7.3. Receiving a Refresh Response . . . . . . . . . . . . . . . 32

8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 32

9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 34

9.1. Forming a CreatePermission Request . . . . . . . . . . . . 34

9.2. Receiving a CreatePermission Request . . . . . . . . . . . 34

9.3. Receiving a CreatePermission Response . . . . . . . . . . 35

10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 35

10.1. Forming a Send Indication . . . . . . . . . . . . . . . . 35

10.2. Receiving a Send Indication . . . . . . . . . . . . . . . 35

Mahy, et al. Standards Track [Page 2]

RFC 5766 TURN April 2010

10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . . 36

10.4. Receiving a Data Indication . . . . . . . . . . . . . . . 37

11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

11.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 39

11.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 39

11.3. Receiving a ChannelBind Response . . . . . . . . . . . . . 40

11.4. The ChannelData Message . . . . . . . . . . . . . . . . . 41

11.5. Sending a ChannelData Message . . . . . . . . . . . . . . 41

11.6. Receiving a ChannelData Message . . . . . . . . . . . . . 42

11.7. Relaying Data from the Peer . . . . . . . . . . . . . . . 43

12. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . . 43

13. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 45

14. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 45

14.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . . 45

14.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 46

14.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . . 46

14.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

14.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . . 46

14.6. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . . 46

14.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 47

14.8. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . . 47

14.9. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 48

15. New STUN Error Response Codes . . . . . . . . . . . . . . . . 48

16. Detailed Example . . . . . . . . . . . . . . . . . . . . . . . 48

17. Security Considerations . . . . . . . . . . . . . . . . . . . 55

17.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . . 55

17.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 55

17.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 56

17.1.3. Faked Refreshes and Permissions . . . . . . . . . . . 56

17.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . . 56

17.1.5. Impersonating a Server . . . . . . . . . . . . . . . 57

17.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . . 58

17.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 58

17.2. Firewall Considerations . . . . . . . . . . . . . . . . . 59

17.2.1. Faked Permissions . . . . . . . . . . . . . . . . . . 59

17.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 60

17.2.3. Running Servers on Well-Known Ports . . . . . . . . . 60

17.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 60

17.3.1. DoS against TURN Server . . . . . . . . . . . . . . . 60

17.3.2. Anonymous Relaying of Malicious Traffic . . . . . . . 61

17.3.3. Manipulating Other Allocations . . . . . . . . . . . 61

17.4. Other Considerations . . . . . . . . . . . . . . . . . . . 61

18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61

19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 62

20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63

21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64

21.1. Normative References . . . . . . . . . . . . . . . . . . . 64

21.2. Informative References . . . . . . . . . . . . . . . . . . 64

Mahy, et al. Standards Track [Page 3]

RFC 5766 TURN April 2010

1. Introduction

A host behind a NAT may wish to exchange packets with other hosts,

some of which may also be behind NATs. To do this, the hosts

involved can use "hole punching" techniques (see [RFC5128]) in an

attempt discover a direct communication path; that is, a

communication path that goes from one host to another through

intervening NATs and routers, but does not traverse any relays.

As described in [RFC5128] and [RFC4787], hole punching techniques

will fail if both hosts are behind NATs that are not well behaved.

For example, if both hosts are behind NATs that have a mapping

behavior of "address-dependent mapping" or "address- and port-

dependent mapping", then hole punching techniques generally fail.

When a direct communication path cannot be found, it is necessary to

use the services of an intermediate host that acts as a relay for the

packets. This relay typically sits in the public Internet and relays

packets between two hosts that both sit behind NATs.

This specification defines a protocol, called TURN, that allows a

host behind a NAT (called the TURN client) to request that another

host (called the TURN server) act as a relay. The client can arrange

for the server to relay packets to and from certain other hosts

(called peers) and can control aspects of how the relaying is done.

The client does this by obtaining an IP address and port on the

server, called the relayed transport address. When a peer sends a

packet to the relayed transport address, the server relays the packet

to the client. When the client sends a data packet to the server,

the server relays it to the appropriate peer using the relayed

transport address as the source.

A client using TURN must have some way to communicate the relayed

transport address to its peers, and to learn each peer’s IP address

and port (more precisely, each peer’s server-reflexive transport

address, see Section 2). How this is done is out of the scope of the

TURN protocol. One way this might be done is for the client and

peers to exchange email messages. Another way is for the client and

its peers to use a special-purpose "introduction" or "rendezvous"

protocol (see [RFC5128] for more details).

If TURN is used with ICE [RFC5245], then the relayed transport

address and the IP addresses and ports of the peers are included in

the ICE candidate information that the rendezvous protocol must

carry. For example, if TURN and ICE are used as part of a multimedia

solution using SIP [RFC3261], then SIP serves the role of the

rendezvous protocol, carrying the ICE candidate information inside

the body of SIP messages. If TURN and ICE are used with some other

Mahy, et al. Standards Track [Page 4]

RFC 5766 TURN April 2010

rendezvous protocol, then [MMUSIC-ICE-NONSIP] provides guidance on

the services the rendezvous protocol must perform.

Though the use of a TURN server to enable communication between two

hosts behind NATs is very likely to work, it comes at a high cost to

the provider of the TURN server, since the server typically needs a

high-bandwidth connection to the Internet. As a consequence, it is

best to use a TURN server only when a direct communication path

cannot be found. When the client and a peer use ICE to determine the

communication path, ICE will use hole punching techniques to search

for a direct path first and only use a TURN server when a direct path

cannot be found.

TURN was originally invented to support multimedia sessions signaled

using SIP. Since SIP supports forking, TURN supports multiple peers

per relayed transport address; a feature not supported by other

approaches (e.g., SOCKS [RFC1928]). However, care has been taken to

make sure that TURN is suitable for other types of applications.

TURN was designed as one piece in the larger ICE approach to NAT

traversal. Implementors of TURN are urged to investigate ICE and

seriously consider using it for their application. However, it is

possible to use TURN without ICE.

TURN is an extension to the STUN (Session Traversal Utilities for

NAT) protocol [RFC5389]. Most, though not all, TURN messages are

STUN-formatted messages. A reader of this document should be

familiar with STUN.

2. Overview of Operation

This section gives an overview of the operation of TURN. It is non-

normative.

In a typical configuration, a TURN client is connected to a private

network [RFC1918] and through one or more NATs to the public

Internet. On the public Internet is a TURN server. Elsewhere in the

Internet are one or more peers with which the TURN client wishes to

communicate. These peers may or may not be behind one or more NATs.

The client uses the server as a relay to send packets to these peers

and to receive packets from these peers.

Mahy, et al. Standards Track [Page 5]

剩余66页未读，继续阅读

评论收藏

内容反馈

毕加索解锁

粉丝: 2139
资源: 24

RFC-5766 Traversal Using Relays around NAT (TURN)

最新资源

RFC-5766 Traversal Using Relays around NAT (TURN)

Python库 | rfc-xmldiff-0.5.2.tar.gz

RFC-33A.rar_rfc-33a

rfc-index.zip_RFC_index_rfc-all

SAP PI RFC-to-Web Service Scenario

sapjco3-call RFC-code

RFC-2543---SIP Session Initiation Protocol.doc

rfc-quic.7z

sap-java-rfc-jco3

配套资料－FTP协议的RFC－rfc0959.txt

RFC-3550 RTP中英文版

RFC-3550-中文版.pdf

RFC10xx 内容,分析与详解

google-rfc-2445:自动从code.google.compgoogle-rfc-2445导出

saprfc-1.4.1.All.zip

RFC中文文档全集【RFC1-3093】

RFC-5340 OSPFv3 for IPv6 的中文翻译

这是rfc-2246的原文

NAT64-rfc6146

中方RFC RFC3---RFC3093，chm文件,查找、学习、引用的好帮手

落雪音乐-六音音源 sixyin-music-source-v1.1.0.js

markdown配套文件，使用前先解压

喜马拉雅xm文件解密工具

OCPP协议解析 代码+代码含义详解

mpp_demo.rar

m3u8的下载转换工具

ubuntu下安装ffmpeg必备软件包合集

音频转码，无限制的享受音乐吧！

OPENCV函数手册（中文）.zip

ev4转mp4小工具（无视授权密码）

最新资源

OCPP协议解析代码+代码含义详解