Editing XEP-0065: SOCKS5 Bytestreams
From JaWiki (Jabber/XMPP wiki)
Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to copy and paste your text into a text file and save it for later.
The administrator who locked it offered this explanation: MediaWiki upgrading
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 7: | Line 7: | ||
Этот документ определяет [[XEP|расширение протокола XMPP]] для установление [[out-of-band|внеканального]] байтового потока между двумя произвольными [[entity|сущностями]] Jabber. | Этот документ определяет [[XEP|расширение протокола XMPP]] для установление [[out-of-band|внеканального]] байтового потока между двумя произвольными [[entity|сущностями]] Jabber. | ||
− | : '''ПРИМЕЧАНИЕ:''' Настоящий протокол | + | : '''ПРИМЕЧАНИЕ:''' Настоящий протокол является [[Draft Standard|Черновым Стандартом]] [[XMPP Standards Foundation|Организации Стандартизации XMPP]]. Его реализации поощряются, и протокол подходит для развёртывания в производственных системах<!-- Implementations are encouraged and the protocol is appropriate for deployment in production systems -->, но прежде, чем он станет [[Final Standard|Окончательным Стандартом]], в протоколе могут произойти некоторые изменения. |
= Входные данные = | = Входные данные = | ||
Line 16: | Line 16: | ||
* Номер: 0065 | * Номер: 0065 | ||
* Издатель: [[XMPP Standards Foundation|Организации Стандартизации XMPP]] | * Издатель: [[XMPP Standards Foundation|Организации Стандартизации XMPP]] | ||
− | * Статус: Черновик | + | * Статус: [[Draft Standard|Черновик]] |
* Тип: {{fixme|Standards Track}} | * Тип: {{fixme|Standards Track}} | ||
* Версия: 1.7 | * Версия: 1.7 | ||
Line 22: | Line 22: | ||
* Утвердивший орган: [[XMPP Council|Совет XMPP]] | * Утвердивший орган: [[XMPP Council|Совет XMPP]] | ||
* Опирается на: | * Опирается на: | ||
− | ** [[XMPP Core|Основы XMPP]], | + | ** [[RFC 3920: XMPP Core|Основы XMPP]], |
** RFC 1928: SOCKS Protocol Version 5, | ** RFC 1928: SOCKS Protocol Version 5, | ||
** RFC 3174: US Secure Hash Algorithm 1 (SHA1), | ** RFC 3174: US Secure Hash Algorithm 1 (SHA1), | ||
Line 58: | Line 58: | ||
== Отношение к XMPP == | == Отношение к XMPP == | ||
− | [[XMPP|Расширяемый протокол передачи сообщений и информации о присутствии (XMPP)]] определён в документах [[XMPP Core|«Основы XMPP» | + | [[XMPP|Расширяемый протокол передачи сообщений и информации о присутствии (XMPP)]] определён в документах [[RFC 3920: XMPP Core|«Основы XMPP» (RFC 3920)]] и [[RFC 3921: XMPP IM|«Обмен сообщениями в XMPP» (RFC 3921)]], внесённых [[XMPP Standards Foundation|Организацией Стандартизации XMPP]] в Процесс Стандартизации Интернета (Internet Standards Process), который управляется [[w:IETF|IETF]] в соответствии с RFC 2026. Каждый протокол, определённый в этом документе, разработан вне Процесса Стандартизации Интернета и должен рассматриваться как дополнение к XMPP, а не как развитие, продолжение самого XMPP. |
== Слова соответствия == | == Слова соответствия == | ||
Line 73: | Line 73: | ||
== Введение == | == Введение == | ||
− | [[XMPP]] разработан для пересылки сравнительно малых кусков [[XML]] между [[entity|сетевыми сущностями]] (см. «[[XMPP Core|Основы XMPP]]») и не предназначен для пересылки двоичных данных. Тем не менее, иногда требуется передать двоичные данные другой сущности, найденной в сети XMPP (например, передать файл). Поэтому в сообществе Jabber многие признают, что было бы полезно иметь общий протокол для пересылки двоичных данных между двумя произвольными сущностями в сети. Основным приложением такой технологии передачи была бы [[file transfer|передача файлов]], для которой в настоящее время есть несколько несовместимых протоколов (что выливается в отсутствие совместимости). Тем не менее, возможны и другие приложения, из-за которых важно разработать общий протокол, а не ограниченный частным применением, таким, передача файлов. Этот документ определяет протокол, удовлетворяющий следующим условиям: | + | [[XMPP]] разработан для пересылки сравнительно малых кусков [[XML]] между [[entity|сетевыми сущностями]] (см. «[[RFC 3920: XMPP Core|Основы XMPP]]») и не предназначен для пересылки двоичных данных. Тем не менее, иногда требуется передать двоичные данные другой сущности, найденной в сети XMPP (например, передать файл). Поэтому в сообществе Jabber многие признают, что было бы полезно иметь общий протокол для пересылки двоичных данных между двумя произвольными сущностями в сети. Основным приложением такой технологии передачи была бы [[file transfer|передача файлов]], для которой в настоящее время есть несколько несовместимых протоколов (что выливается в отсутствие совместимости). Тем не менее, возможны и другие приложения, из-за которых важно разработать общий протокол, а не ограниченный частным применением, таким, передача файлов. Этот документ определяет протокол, удовлетворяющий следующим условиям: |
* Байтовые потоки устанавливаются поверх стандартных соединений [[w:TCP|TCP]] (RFC 793) или [[w:UDP|UDP]] (RFC 768), причём поддержка TCP ОБЯЗАТЕЛЬНА, а поддержка UDP НЕОБЯЗАТЕЛЬНА. | * Байтовые потоки устанавливаются поверх стандартных соединений [[w:TCP|TCP]] (RFC 793) или [[w:UDP|UDP]] (RFC 768), причём поддержка TCP ОБЯЗАТЕЛЬНА, а поддержка UDP НЕОБЯЗАТЕЛЬНА. | ||
* [[w:Сокет|Сокеты]] могут быть прямыми (peer-to-peer) или опосредованными (устанавливаемыми через передающий сервис). | * [[w:Сокет|Сокеты]] могут быть прямыми (peer-to-peer) или опосредованными (устанавливаемыми через передающий сервис). | ||
* Где возможно, используются стандартные протоколы передачи. | * Где возможно, используются стандартные протоколы передачи. | ||
− | Конкретно, данный документ предполагает, что сообщество Jabber пользуется протоколом [[w:en:SOCKS|SOCKS 5]] — технологией передачи данных, принятой [[w:IETF|IETF]] и совместимой с [[w:IPv6|IPv6]]. (Примечание: Предлагаемая технология использует подмножество протокола SOCKS 5, специально адаптированное для передачи данных в Jabber, поэтому существующие SOCKS 5 [[ | + | Конкретно, данный документ предполагает, что сообщество Jabber пользуется протоколом [[w:en:SOCKS|SOCKS 5]] — технологией передачи данных, принятой [[w:IETF|IETF]] и совместимой с [[w:IPv6|IPv6]]. (Примечание: Предлагаемая технология использует подмножество протокола SOCKS 5, специально адаптированное для передачи данных в Jabber, поэтому существующие SOCKS 5 [[proxy|прокси-серверы]] не могут использоваться для её реализации без соответствующей доработки.) |
== Терминология == | == Терминология == | ||
Line 175: | Line 175: | ||
Перед попыткой создания канала передачи данных Инициатору надо найти посредника (прокси). Он может сделать это, используя [[Service Discovery|обнаружение сервисов]] следующим образом: | Перед попыткой создания канала передачи данных Инициатору надо найти посредника (прокси). Он может сделать это, используя [[Service Discovery|обнаружение сервисов]] следующим образом: | ||
− | <b id="Example_3">Пример 3. Инициатор посылает серверу запрос [[Service Discovery|обнаружения сервисов ( | + | <b id="Example_3">Пример 3. Инициатор посылает серверу запрос [[Service Discovery|обнаружения сервисов (Servce Discovery).]]</b> |
<iq type='get' | <iq type='get' | ||
from='initiator@host1/foo' | from='initiator@host1/foo' | ||
Line 197: | Line 197: | ||
</iq> | </iq> | ||
− | === | + | === Initiator Queries Proxy to Find Out if it is a Proxy === |
− | + | For each item in the disco#items result, the Initiator must query to determine if it is a bytestreams proxy. It may do so using Service Discovery as follows: | |
− | + | Example 5. Initiator Sends Service Discovery Request to Proxy | |
− | + | <iq type='get' | |
− | + | from='initiator@host1/foo' | |
− | + | to='proxy.host3' | |
− | + | id='proxy_info'> | |
− | + | <query xmlns='http://jabber.org/protocol/disco#info'/> | |
− | + | </iq> | |
+ | |||
− | + | The proxy will return its information. The Initiator SHOULD inspect each identity to see if it contains an identity of category "proxy" and type "bytestreams". | |
− | + | Example 6. Server Replies to Service Discovery Request | |
− | + | <iq type='result' | |
− | + | from='proxy.host3' | |
− | + | to='initiator@host1/foo' | |
− | + | id='proxy_info'> | |
− | + | <query xmlns='http://jabber.org/protocol/disco#info'> | |
− | + | ... | |
− | + | <identity category='proxy' | |
− | + | type='bytestreams' | |
− | + | name='SOCKS5 Bytestreams Service'/> | |
− | + | ... | |
− | + | <feature var='http://jabber.org/protocol/bytestreams'/> | |
− | + | ... | |
− | + | </query> | |
− | + | </iq> | |
− | + | ||
+ | === Initiator Discovers Network Address of StreamHost === | ||
− | + | If the StreamHost is a Proxy, the Initiator must first request the full network address used for bytestreaming (obviously this is not required if the StreamHost is the Initiator). This is done by sending an IQ-get to the proxy in the bytestreams namespace, as follows: | |
− | + | Example 7. Initiator Requests Network Address from Proxy | |
+ | <iq type='get' | ||
+ | from='initiator@host1/foo' | ||
+ | to='proxy.host3' | ||
+ | id='discover'> | ||
+ | <query xmlns='http://jabber.org/protocol/bytestreams'/> | ||
+ | </iq> | ||
+ | |||
− | < | + | The <streamhost/> element specifying a network address MUST possess the following attributes: |
− | + | jid = the JID of the StreamHost for communications over Jabber | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | In addition, the <streamhost/> element MUST include: | |
− | + | ||
− | + | ||
− | + | EITHER | |
− | + | host = the hostname or IP address of the StreamHost for SOCKS5 communications over TCP | |
− | + | port = a port associated with the hostname or IP address for SOCKS5 communications over TCP | |
− | + | ||
− | + | ||
− | + | OR | |
− | + | zeroconf = a zeroconf [5] identifier to which an entity may connect, for which the service identifier and protocol name SHOULD be "_jabber.bytestreams". | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | Example 8. Proxy Informs Initiator of Network Address | |
+ | <iq type='result' | ||
+ | from='proxy.host3' | ||
+ | to='initiator@host1/foo' | ||
+ | id='discover'> | ||
+ | <query xmlns='http://jabber.org/protocol/bytestreams'> | ||
+ | <streamhost | ||
+ | jid='proxy.host3' | ||
+ | host='24.24.24.1' | ||
+ | zeroconf='_jabber.bytestreams'/> | ||
+ | </query> | ||
+ | </iq> | ||
+ | |||
− | + | If the Initiator does not have permissions to initiate bytestreams on the Proxy for whatever reason (e.g., a proxy implementation may enable administrators to ban JIDs or domains from using the Proxy), the Proxy MUST return a <forbidden/> error to the Initiator (for information about error syntax, refer to Error Condition Mappings [6]): | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | Example 9. Proxy Returns Error to Initiator | |
+ | <iq type='error' | ||
+ | from='initiator@host1/foo' | ||
+ | to='proxy.host3' | ||
+ | id='discover'> | ||
+ | <query xmlns='http://jabber.org/protocol/bytestreams'/> | ||
+ | <error code='403' type='auth'> | ||
+ | <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> | ||
+ | </error> | ||
+ | </iq> | ||
+ | |||
− | + | If the Proxy is unable to act as a StreamHost, the Proxy SHOULD return a <not-allowed/> error to the Initiator: | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | === | + | Example 10. Proxy Returns Error to Initiator |
+ | <iq type='error' | ||
+ | from='initiator@host1/foo' | ||
+ | to='proxy.host3' | ||
+ | id='discover'> | ||
+ | <query xmlns='http://jabber.org/protocol/bytestreams'/> | ||
+ | <error code='405' type='cancel'> | ||
+ | <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> | ||
+ | </error> | ||
+ | </iq> | ||
+ | |||
+ | === Initiator Informs Target of StreamHosts === | ||
− | + | In order to establish a bytestream between the Initiator and the Target, the Initiator must provide network address information for the StreamHost(s) to the Target. This happens in-band via a single IQ-set, which must contain the following information: | |
+ | The network address of at least one StreamHost to which the Target may attempt to connect | ||
+ | The Stream ID for this connection | ||
+ | The "mode" to use, normally "tcp" but optionally "udp" (see the Optional UDP Support section of this document) | ||
− | + | The protocol format is shown below. | |
− | + | ||
− | + | ||
− | + | Example 11. Initiation of Interaction | |
+ | <iq type='set' | ||
+ | from='initiator@host1/foo' | ||
+ | to='target@host2/bar' | ||
+ | id='initiate'> | ||
+ | <query xmlns='http://jabber.org/protocol/bytestreams' | ||
+ | sid='mySID' | ||
+ | mode='tcp'> | ||
+ | <streamhost | ||
+ | jid='initiator@host1/foo' | ||
+ | host='192.168.4.1' | ||
+ | port='5086'/> | ||
+ | <streamhost | ||
+ | jid='proxy.host3' | ||
+ | host='24.24.24.1' | ||
+ | zeroconf='_jabber.bytestreams'/> | ||
+ | </query> | ||
+ | </iq> | ||
+ | |||
− | < | + | If the Target is unwilling to accept the bytestream, it MUST return a <not-acceptable/> error to the Initiator. |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | Example 12. Target Refuses Bytestream | |
+ | <iq type='error' | ||
+ | from='target@host2/bar' | ||
+ | to='initiator@host1/foo' | ||
+ | id='initiate'> | ||
+ | <error code='406' type='auth'> | ||
+ | <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> | ||
+ | </error> | ||
+ | </iq> | ||
+ | |||
+ | === Target Establishes SOCKS5 Connection with StreamHost === | ||
− | + | If the Target is willing to accept the bytestream, it MUST attempt to open a standard TCP socket on the network address of the StreamHost communicated by the Initiator. If the Initiator provides more than one StreamHost, the Target SHOULD try to connect to them in the order they occur. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | If the Target tries but is unable to connect to any of the StreamHosts and it does not wish to attempt a connection from its side, it MUST return a <item-not-found/> error to the Initiator. | |
− | + | Example 13. Target Is Unable to Connect to Any StreamHost and Wishes to End Transaction | |
+ | <iq type='error' | ||
+ | from='target@host2/bar' | ||
+ | to='initiator@host1/foo' | ||
+ | id='initiate'> | ||
+ | <error code='404' type='cancel'> | ||
+ | <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> | ||
+ | </error> | ||
+ | </iq> | ||
+ | |||
− | + | If the Target is able to open a TCP socket on a StreamHost, it MUST utilize the SOCKS5 protocol specified in RFC 1928 [7] to establish the connection with the StreamHost. In accordance with the SOCKS5 RFC, the Target MAY have to authenticate in order to use the proxy. However, any authentication required is beyond the scope of this document. | |
− | + | Once the Target has successfully authenticated with the Proxy (even anonymously), it SHOULD send a CONNECT request to the appropriate host in order to continue the negotiation. The following rules apply: | |
− | + | The hostname MUST be SHA1(SID + Initiator JID + Target JID) where the definition of the SHA1 hashing algorithm is as specified by RFC 3174 [8] and the output is hexadecimal-encoded (not binary). | |
− | + | The port MUST be 0 (zero). | |
− | + | The JIDs provided MUST be the JIDs used for the IQ exchange, which MAY be full JIDs (<node@domain.tld/resource>) or bare JIDs (<node@domain.tld>). | |
− | + | The appropriate stringprep profiles (as specified in XMPP Core [9]) MUST be applied to the JIDs before application of the SHA1 hashing algorithm. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | Example 14. Target Connects to StreamHost | |
+ | CMD = X'01' | ||
+ | ATYP = X'03' | ||
+ | DST.ADDR = SHA1 Hash of: (SID + Initiator JID + Target JID) | ||
+ | DST.PORT = 0 | ||
+ | |||
− | + | Example 15. StreamHost Acknowledges Connection | |
+ | STATUS = X'00' | ||
+ | |||
− | + | When replying to the client in accordance with Section 6 of RFC 1928, the StreamHost SHOULD set the BND.ADDR and BND.PORT to the values provided by the client in the connection request. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | === Target Acknowledges SOCKS5 Connection === | |
− | + | After the Target has authenticated with the StreamHost, it MUST send an IQ-result to the Initiator indicating which StreamHost was used. | |
− | + | Example 16. Target Notifies Initiator of Connection | |
+ | <iq type='result' | ||
+ | from='target@host2/bar' | ||
+ | to='initiator@host1/foo' | ||
+ | id='initiate'> | ||
+ | <query xmlns='http://jabber.org/protocol/bytestreams'> | ||
+ | <streamhost-used jid='proxy.host3'/> | ||
+ | </query> | ||
+ | </iq> | ||
+ | |||
+ | At this point, the Initiator knows which StreamHost was used by the Target. | ||
− | + | === Initiator Establishes SOCKS5 Connection with StreamHost === | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
+ | If the StreamHost used is a Proxy, the Initiator MUST authenticate and establish a connection with the StreamHost before requesting that the StreamHost activate bytestream. The Initiator will establish a connection to the SOCKS5 proxy in the same way the Target did (passing the same value for the CONNECT request), as shown in the following examples. | ||
− | + | Example 17. Initiator Connects to StreamHost | |
− | + | CMD = X'01' | |
+ | ATYP = X'03' | ||
+ | DST.ADDR = SHA1 Hash of: (SID + Initiator JID + Target JID) | ||
+ | DST.PORT = 0 | ||
+ | |||
+ | Example 18. StreamHost Acknowledges Connection to Initiator | ||
+ | STATUS = X'00' | ||
+ | |||
=== Activation of Bytestream === | === Activation of Bytestream === | ||