logo资料库

新版STUN协议中文版(RFC5389).pdf

发布时间：2022-06-17 发布人：admin 分类：说明书 资料大小：0.72M 资料格式：pdf 举报 版权申诉
第1页 / 共31页
第2页 / 共31页
第3页 / 共31页
第4页 / 共31页
第5页 / 共31页
第6页 / 共31页
第7页 / 共31页
第8页 / 共31页
资料共31页，剩余部分请下载后查看
    1.简介 .............................................................................................................................. 3 2.源于 RFC3489 的演变 ................................................................................................... 3 3.操作概览 ....................................................................................................................... 4 4.术语 .............................................................................................................................. 5 5.定义 .............................................................................................................................. 5 6. STUN 消息结构 ............................................................................................................ 6 7.基本的协议处理 ............................................................................................................ 8 7.1 形成一个请求消息或一个指示消息 ...................................................................... 8 7.2 发送请求消息或者指示消息 ................................................................................. 8 7.2.1 通过 UDP 发送 .......................................................................................... 9 7.2.2 通过 TCP 或者 TCP 上的 TLS 发送 ............................................................. 9 7.3 接受一个 STUN 消息 ......................................................................................... 10 7.3.1 处理一个请求............................................................................................11 7.3.2 处理一个指示........................................................................................... 12 7.3.4 处理一个错误响应.................................................................................... 13 8. FINGERPRI NT 机制.................................................................................................. 13 9. server 的 DNS 发现..................................................................................................... 13 10.鉴权和消息完整性机制 .............................................................................................. 14 10.1 短期证书机制................................................................................................... 14 10.1.1 形成一个请求或者指示 ........................................................................... 15 10.1.2 接受一个请求或指示 .............................................................................. 15 10.1.3 接受一个响应 ......................................................................................... 15 10.2 长期证书机制................................................................................................... 15 10.2.1 形成一个请求 ......................................................................................... 16 10.2.2 接受一个请求 ......................................................................................... 16 10.2.3 接受一个请求 ......................................................................................... 17 11. ALTERNATE-SERVER 机制 .................................................................................. 17 12.向后兼容 RFC3489 .................................................................................................... 18 12.1client 处理的改变 .............................................................................................. 18 12.2server 处理的改变.............................................................................................. 18 13.基本 server 行为 ........................................................................................................ 19 14. STUN 用法 .............................................................................................................. 19 15. STUN 属性 .............................................................................................................. 20 15.1MAPPED- ADDRESS ......................................................................................... 20 15.2 XOR-MAPPED- ADDRESS ................................................................................ 21 15.3USERNAME ..................................................................................................... 22 15.5FINGERPRINT.................................................................................................. 23 15.6ERROR-CODE .................................................................................................. 23 15.7 域 .................................................................................................................... 24 15.8 NONCE............................................................................................................ 25 15.9 未知属性.......................................................................................................... 25 15.10 软件 ............................................................................................................... 25 15.11 ALTERNATE-SERVER .................................................................................... 26 16.安全考虑 ................................................................................................................... 26 1
    16.1 针对协议的攻击 ............................................................................................... 26 16.1.1 外围攻击 ................................................................................................ 26 16.1.2 内部攻击 ................................................................................................ 26 16.2 影响用法的攻击 ............................................................................................... 27 16.2.1 攻击 I：针对目标的分布式 Dos(Ddos) ..................................................... 27 16.2.2 攻击 II：隐藏客户端 ............................................................................... 27 16.2.3 攻击 III：假冒 client 的身份 ................................................................... 27 16.2.4 攻击 IV：窃听 ........................................................................................ 27 16.3 哈希敏捷计划.................................................................................................. 28 17. IAB 考虑 .................................................................................................................. 28 18. IANA 考虑................................................................................................................ 28 18.1 STUN 方法注册................................................................................................ 28 18.2 STUN 属性注册................................................................................................ 29 18.3STUN 错误码注册 ............................................................................................. 29 18.4STUN UDP 和 TCP 端口号 ................................................................................ 30 19.从 RFC3489 的改变 ................................................................................................... 30 20.贡献者....................................................................................................................... 31 21.致谢 .......................................................................................................................... 31 2
    1. 简介 NAT 的会话穿透用法 (STUN) 本说明书中说定义的协议—会话穿透 NAT 用法，为处理 NAT 提供了一种工具。它提供 了一种为端点决定由 NAT 分配的和端点本身私有地址和端口相关联的 IP 地址和端口的方 法 。 他也 提供 一种 保持 NAT 绑 定 的方 法。 本协 议 的扩 展可 用于 两端 点的 连接 检 测 [MMUSIC-ICE]，或者两端点之间的包中转[BEHAVE-TURN]. 为保持工具的特性，本说明书定义了一种可扩展的包格式，几种传输层协议之上的操作 以及两种鉴权形式。 STUN 被试图用于解决一种或者多种 NAT 穿透。这些解决方案即是为我们所知的 ST UN 用法。每种用法描述了 STUN 怎样被用于实现 NAT 穿透解决方案。典型地，一种用法指明 什么时候 STUN 消息被发送，哪种可选属性被包含，什么服务器被使用，以及什么鉴权方 式 被 使 用 。 交 互 式 连 接 建 立(ICE) [MMUSIC-ICE] 是 STUN 的 一 种 使 用 方 式 . SIP Outbound[SIP-OUTBOUND]是另外的一种 ST UN 用法。在某些情况下，一种用法需要扩展 STUN，一种 STUN 扩展能以新的方法，属性，或者错误响应码的形式出现。更多的 STUN 用法信息能够在第 14 节找到。 2. 源于 RFC3489 的演变 STUN 最初定义在 RFC3489。RFC3489 有时候被成为“经典的 STUN”，它是以能完全 解决 NAT 穿透问题的解决方案来描述的。在该解决方案中一个客户端能够发现它自己是否 处在 NAT 的后面，判定 NAT 的类型，发现 NAT 外围的公网 IP 地址和端口，然后利用这个 IP 地址和端口填在协议体中，参见 RFC3261。然而，自从 RFC3489 发布后，经验发现经典 的 STUN 简直不能按一种分布式的解决方案来有效地工作。通过经典 STUN 获得的 IP 地址 和端口有时候对端到端的通讯有用，但是有时候没有用。经典的 STUN 没有提供方法来是 否应该发现，事实上，工作还是不工作，并且在它不能工作的情况下没有提供补救措施。更 有甚者的是，经典 STUN 的判断 NAT 类型的分类算法被发现是不完美的，许多 NAT 不完全 符合由它定义的类型。 经典 STUN 也存在一种安全弱点—攻击者能够在特定的拓扑和限制下提供错误的映射， 这基本上不能通过加密方式来解决。尽管这个问题在本说明书中仍存在，但是通过使用 STUN 更完善的解决方案使得攻击被缓解了。 鉴于这些原因，本说明书淘汰了 RFC3489，并且将 STUN 描述成一种工具用于完全穿 透 NAT 解决方案的一部分。ICE [MMUSIC-ICE]是一种为像 SIP 那样基于 offer/answer [RFC3264]策略的协议提供完全的解决方案。SIP Outbound [SIP-OUTBOUND]是一种 sip 信 令完全穿透的解决方案，它以完全不同的方法使用 STUN。因此，一个协议可能能够由它自 己使用 STUN 作为一种解决方案，这类的用法没在这描述，由于上述原因它被强烈的阻止 了。 这里描述的上了线的协议仅是轻微地改自经典 STUN。运行在 TCP 和 UDP 之上的协议 的扩展是一个更加结构化的方法。一个极其巧妙的让应用程序使用 STUN 的机制是偷用 RFC3489 中定义的 128 位事物 ID 中的 32 位，允许改变向后兼容。编码的地址映射使用一 种新的异或格式。还有其他的，更小的改变，参见 19 节更加完整的描述。 由于使用范围的改变，STUN 已经从"Simple Traversal of UDP through NAT"更名为 "Session Traversal Utilities for NAT"。略缩词仍为大家熟知的 STUN。 3
    3. 操作概览 本节仅是描述性的。 /-----\ // STUN \\ | Server | \\ // \-----/ +--------------+ Public Internet ................| NAT 2 |....................... +--------------+ +--------------+ Private NET 2 ................| NAT 1 |....................... +--------------+ /-----\ // STUN \\ | Client | \\ // Private NET 1 \-----/ Figure 1: One Possible STUN Configuration 一种可能的 STUN 配置如图 1 所示。在这种配置下，有两种实现 STUN 协议的实体（成 为 STUN 代理）。图中底下的代理是客户端，它连接到私网 1。这个私网通过 NAT1 连接到 私网 2.私网 2 通过 NAT2 连接到公网。图中最上面的代理是位于公网的服务器。 STUN 是一个 client-server 协议。它支持两种类型的事物。一种是 request/response 事物， 在这种事物中，客户发送一个请求到服务器，服务器返回一个响应。第二种是指示事物，在 这种事物中，两种代理（client 或者 server）发送一个指示并不产生响应。两种事物都包含 一个随机选择的 96 位的事物 ID 号。对请求/相应事物，这个 ID 号允许产生它的客户端将响 应和请求相关联；对于指示事物，事物 ID 用于调试。 所有的 STUN 消息都以固定的头部开始，头部包含一个方法，一个类别，和一个事物 4
    ID 号。方法指明各种各样的请求或者指示。本说明书仅仅定义一种方法—Binding，其他的 方法有望在其他的文档中定义。类别字段表明该消息是一个请求，一个成功的响应，一个错 误响应，还是一个指示。紧跟固定头部的是 0 个或多个的 TLV 属性，为具体消息传递附加 信息。 本文档定义一个唯一的称作 Binding 的方法。该方法能被用于请求/响应事物或者指示事 物。当被用在请求/响应事物中的时候，方法可以用于决定一个 NAT 分配给 client 的特定的 binding。当被用在请求/响应事物或者指示中的时候，方法可以用于保持这种 binding 有效。 在 binding 请求/响应事物中，绑定请求由 STUN 客户端发送到 STUN 服务端。当绑定请求 到达 server 的时候，他可能穿过 STUN Client 和 STUN Client 之间的一个或者多个 NAT（在 图 1 中有两个这样的 NAT）。当绑定请求通过 Nat 的时候，Nat 将修改数据包的源通讯地址 （指源 IP 地址和源端口号）。因而，server 收到的请求的源通讯地址将是由 NAT 创建的接近 server 那边的公网的 IP 和端口。这个地址成为反射通讯地址。STUN server 复制该源通讯地 址到一个 STUN 绑定响应的 XOR-MAPPED- ADDRESS 属性中，并返回该绑定响应到客户端。 当该响应数据包返回通过 NAT 的时候，NAT 将修改 IP 头的目的地址，但是包含在 STUN 响应数据包体 XOR-MAPPED-ADDRESS 属性中的通讯地址将不会被修改。这样，client 能 够学习到最外面 NAT 分配的关于 STUN server 的通讯地址。 在某些情况下，STUN 必须服用其他的协议（如[MMUSIC-ICE], [SIP-OUTBOUND])。 在这些情况下，必须有一种方法来监视一个包，判定它是一个 STUN 包还是不是。STUN 在 包头提供三种有固定值的字段来达到该目的。如果这样不够的话，STUN 数据包还可以包含 一个 FINGERPRINT 值，能够用于区分数据包。 STUN 定义了一系列的一个用法能够决定使用的可选过程，称为机制。这些机制包括 DNS 发现，对于备选 server 的重定向技术，一个用于复用的指纹属性，以及两个鉴权和消 息完整交换。鉴权机制解决一个用户名，密码，以及消息完整值的用途。两种鉴权机制，长 期证书机制和短期证书机制被定义在本说明书中。每一种用途详述了该用途允许的机制。 在长期证书机制中，客户和服务器共享一个预先备置的用户名和密码并执行一个源自 （但是细节不同）HTTP 定义的领会挑战/响应交换。在短期证书机制中，client 和 server 通 过一些优先于 STUN 交换的带外方法交换用户名和密码。这些用于完整性保护和鉴权请求 和响应。没有挑战或暂未使用。 4. 术语 在本文档中，关键词”必须”,”不允许”,”要求”,”可以”,”不可以”, ”应该”,”不应该”,”建议”,”可能”,” 可选” 是根据 BCP14,RFC 2119[2]的规范描述 STUN 实现需要的不同层次。 5. 定义 STUN Agent：一个 STUN Agent 是一个实现了 STUN 协议的实体。该实体既可以是 S TUN 客 户端，也可以是 STUN 服务端。 STUN Client：一个 S TUN client 是一个发送 S TUN 请求和接受 S TUN 响应的实体。一个 S TUN 客户端能够发送指示。在本说明书中，词条 S TUN client 和 client 是同义词。 STUN Server：一个 S TUN client 是一个发送 S TUN 响应和接受 S TUN 请求的实体。一个 S TUN 客户端能够发送指示。在本说明书中，词条 S TUN server 和 server 是同义词。 5
    Transport Address：IP 地址和端口号的组合（如 UDP 和 TCP 端口号）。 Reflexive Transport Address：一个客户端学习到的能够标示该客户端的被 server 看得到的通讯 地址。当一个客户端和另一个主机被一个 NA T 阻隔的时候，反射通讯地址描述 NA T 公网一边分 给客户端的映射地址。反射通讯地址从 S TUN 响应消息中的映射地址属性（MAPPED-ADDRESS or XOR-MAPPED-ADDRESS ）学习到。 Mapped Address：和反射地址一个意思。这个词条保留仅仅是由于历史原因以及归功于属性名 MAPPED-ADDRESS 和 XOR-MAPPED-ADDRESS。 Long-Term Credential ：一个描述客户端和服务端共享私密的用户名和密码。长期证书通常授给 client 当订阅者注册一个服务的时候并保持到订阅者离开改服务或者显式改变证书关系。 Long-term Password：长期证书的密码。 Short-term Credential：一个描述客户端和服务端共享私密的临时用户名和密码。短期证书通过 一些 server 和 client 之间的协议机制俩获得，预处理 S TUN 交换。一个短期的证书由一个显式 的临时域，该域可能基于一段指定的时间（例如 5 分钟）或者一个事件（例如结束一个 S IP 对 话）。短期证书的指定域由应用程序用途定义。 Long-Term Password：短期证书的密码。 Attribute：一个能附加到 STUN 消息的类型-长度-值对象的 STUN 词条。属性分为两类： comprehension-required 和 comprehension-optional。STUN 代理可以安全地忽略它们不能 理解的 comprehension-optional 属性，但是如果它包含一个不能理解的 comprehension-required 属性，它将不能成功处理一个消息。 TRO：重传时间到，定义了一个发送请求和第一次重传请求的初始的时间周期。 6. STUN 消息结构 STUN 消息使用网络顺序的二进制编码（最重要的字节或者八位优先，通常称作 big-endian）。传输顺序在 RFC791【RFC0791】的附录 B 中详细描述。注意，数据常量是十 进制的（基数是 10）。 所有的 STUN 消息必须以 20 字节的头部开始，紧跟 0 个或者多个属性。STUN 头部包含 一个 STUN 消息类型，巧妙的方法值，事物 ID 和消息长度。 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 0| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6
    | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of STUN Message Header 每一个 STUN 消息最重要的 2bits 必须为 0。当 STUN 和其他协议在同一端口上复用的时候， 这能够区分 STUN 的数据包。 消息类型字段定义了消息类别（请求，成功响应，失败响应，或者重定向）和 STUN 消息的消息方法（基本功能）。尽管有 4 种消息类型，但是在 STUN 中仅有两种事物：请 求/响应事物（包含请求消息和响应消息）和指示事物（包含单一的指示消息）。响应类型 分为错误和成功的响应来辅助快速处理 STUN 消息。消息类型域被分解在如下的结构中： 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ |M |M |M|M|M|C|M|M|M|C|M|M|M|M| |11|10|9|8|7|1|6|5|4|0|3|2|1|0| +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of STUN Message Type Field 消息类型域中的比特位从最重要（M11）到最不重要（M0）来显示。M11 到 M0 标示一个 方法的 12 位编码。C1 和 C0 标示类型的编码。0b00 的类型是一个请求，0b01 的类型是一 个指示，010 类型是一个成功的响应，0b11 是一个错误的响应。本说明书定义了唯一的一 个方法：Binding。方法和类别是正交的，因此，对于每个方法，一个请求，成功响应，错 误响应和标示都可能是该方法的。扩展定义的新方法必须指明对于改方法哪种类型被允许。 例如，一个绑定请求拥有类别 class=0b00（request）和 method=0b000000000001 (Binding)并且编码到前 16 位的为 0x0101。 注意：这种不幸的编码方式归功于【rfc3489】中值的安排，它没有考虑指示，成功和 错误的比特域的使用。 巧妙域必须包含固定的网络序的值 0x2112A442。在 RFC3489 中，这个域是事物 ID 的一部分；把这个域放在这里允许一个主机检测客户端是否理解本修订说明书所附加的特定 属性。另外，当 STUN 在相同端口上复用其他协议的时候它辅助区分 STUN 包和其他协议 包。 事物 ID 是一个 96bits 的标识符，用于唯一标示一个 STUN 事物。对于请求/响应事物， 该标识符被 STUN client 挑选给请求，并且有 server 在响应中传回。对于指示（indication）， 它由发送它的代理挑选。他主要为关联请求和响应服务，它也为特定的类别免受攻击而有一 7
    定的作用。Server 也使用事物 ID 来作为一个经过所有客户端的每个事物的唯一关键字。由 此，事物 ID 必须统一地，随机地从 0—2^96-1 中选取，可以是一个加密的随机串。重传相 同的请求使用相同的 ID，但是 client 必须为一个先的事物挑选新的事物 ID，除非新的请求 是面向 bit 的与先前请求相同的并且从相同的通讯地址发送到相同的 IP 地址。Success 和 error 响应必须携带和他们相关联的请求的事物 ID。当一个代理在相同端口上即是 server 有是 client 的时候，代理发送的事物 ID 和接受道德事物 ID 没有关系。 消息长度域必须包含不包括 20 字节头部的 STUN 消息的字节大小数。由于所有的 STUN属性被填充成 4 字节的组合，因而此域的最后两 bit 总是 0.这也提供了一种区分 ST UN 数据包和其他协议包的方法。 紧跟 STUN 固定头部的是 0 哥或者多个属性。每个属性都是以 TLV 编码的。编码细节 和属性本身将在 15 节给出。 7. 基本的协议处理 本节定义了 STUN 协议的基本处理。他描述了消息是怎么样形成的，怎样发送，当他们 到达时怎样被处理。也详细定义了绑定方法的处理。本文档其他的节描述了在特定条件下选 择使用可选的处理的一种方法。其他的文档可能会定义其他的 STUN 扩展，通过附加新的 方法，新的属性或者新的错误响应码。 7.1 形成一个请求消息或一个指示消息 当形成一个请求或一个指示消息，代理必须遵从第 6 节的规则构造头部。另外，消息 类别必须是“Request”或者“Indication”（按实际情况而定），方法必须是绑定或者其他 文档定义的方法。 代理添加方法或者用法指定的所有属性。例如，某些用法可能指定代理使用一个鉴权方 法（section10）或者 FINGERPRINT 属性（section8）。 如果代理发送一个请求，它可以在请求中添加一个 SOFTWARE 属性。代理可能在指 示消息中包含一个 SOFTWARE 属性，这有方法决定。STUN 的扩展应该讨论 SOFTWARE 在新的只是中是否有用。 对于没有鉴权的绑定方法，不需要任何属性除非用法指定了。 在知情的情况下，所有的通过 UDP 发送的 STUN 消息应该短语路径的 MTU。如果不知道 路径的 MTU，消息应该小于 Ipv4 首跳的 576 字节【RFC1122】以及 Ipv6 首跳的 1280 字 节【RFC2460】。这个值和 IP 包的总大小有关。因此，对于 Ipv4，实际的 STUN 消息长 度应该小于 548 字节（576-20 字节的 IP 头部，减 8 字节的 UDP 头部，假设没有 IP 可选 项被使用）。STUN 无能力解决请求小于 MTU 但是响应大于 MTU 的情况。不要认为这种 限制将是 STUN 的一个问题。MT U 的限制是应该，不是必须的，来证实 STUN 本身被用于 探测 MTU 的特征[BEHAVE-NAT]。 除此之外或者类似的应用，MTU 限制必须被遵从。 7.2 发送请求消息或者指示消息 代理将发送请求或者指示消息。本文档说明了怎样通过 UDP，TCP 或者 TCP 之上的 TLS 来发送 STUN 消息；其他的通讯协议将在以后被添加。STUN 用法必须指明那个通讯 协议被使用，代理怎样决定接收者的 IP 地址和端口。第 9 节描述了用法可能选择使用的基 8
    分享到：
    赞 收藏

    相关推荐

    资料库

    网络技术

    共收录2367份资料，累计7个分类，关注成员有19位，主要包括：综合布线,网管软件,网络监控,网络设备,其它,系统集成,网络基础

    热门标签

    综合布线 网管软件 网络监控 网络设备 其它 系统集成 网络基础

    最新资料