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 198: | Line 198: | ||
=== Инициатор спрашивает посредника, является ли он посредником === | === Инициатор спрашивает посредника, является ли он посредником === | ||
+ | {{todo|Что автор хотел этим сказать? // [[User:Juriks|Сыр Российский]] 19:42, 25 October 2007 (CEST)}} | ||
− | Инициатор должен | + | Каждый элемент списка результатов disco#items Инициатор должен запросить, является ли он посреднико передачи данных. Он может сделать это, используя [[Service Discovery|обнаружение сервисов (Service Discovery)]] следующим образом: |
<b id="Example_5">Пример 5. Инициатор посылает посреднику запрос обнаружения сервисов.</b> | <b id="Example_5">Пример 5. Инициатор посылает посреднику запрос обнаружения сервисов.</b> | ||
Line 209: | Line 210: | ||
</iq> | </iq> | ||
− | Посредник вернёт сведения о себе. Инициатору СЛЕДУЕТ исследовать | + | Посредник вернёт сведения о себе. Инициатору СЛЕДУЕТ исследовать каждую {{fixme|личность}} и посмотреть, содержится ли в этих сведениях {{fixme|личность}} категории "proxy" (свойство 'category') и типа "bytestreams" (свойство 'type'). |
<b id="Example_6">Пример 6. Сервер отвечает на запрос обнаружения сервисов.</b> | <b id="Example_6">Пример 6. Сервер отвечает на запрос обнаружения сервисов.</b> | ||
Line 330: | Line 331: | ||
</iq> | </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 === | ||