RFC: 1928
Оригинал: SOCKS Protocol Version 5
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , , ,
Перевод: Александр Горлач

RFC 1928, Страница 8 из 8

Процедура для клиентов работающих по UDP

Клиент, работающий по UDP, должен посылать свои датаграмы на порт пересылающего их UDP-сервера, указанного в поле BND.PORT в ответе на запрос UDP ASSOCIATE. Если выбранная схема аутентификации требует особое формирование пакетов с целью проверки целостности и/или конфедициальности, датаграмма должна инкапсулироваться в пакет, формат которого определяется выбранной схемой. Каждая UDP-датаграма содержит в себе заголовок UDP-запроса:

RSVFRAGATYPDST.ADDRDST.PORTDATA
211Variable2Variable

Поля заголовка UDP-запроса:

* RSV  зарезервировано X'0000'
* FRAG    текущий номер фрагмента
* ATYP    тип адреса:
   *  IP v4 адрес: X'01'
   *  имя домена:  X'03'
   *  IP v6 адрес: X'04'
*  DST.ADDR       требуемый целевой адрес
*  DST.PORT       требуемый целевой порт
*  DATA     пользовательские данные

Когда пересылающий UDP-датаграммы сервер пересылает датаграмму, он делает это молча, без какого-либо уведомления выполнившего запрос клиента. Аналогично, сервер будет молча отбрасывать датаграммы, которые он не может или не будет пересылать. Когда пересылающий UDP-датаграммы сервер получает ответную датаграмму с удаленного хоста, он должен инкапсулировать эту датаграмму используя помимо заголовка UDP-запроса еще и инкапсуляцию, определяемую выбранной схемой аутентификации.

Обращение к пересылающему UDP-датаграммы серверу должно производиться с ожидаемого SOCKS-сервером IP-адреса клиента, который (клиент) будет посылать датаграммы на BND.PORT, данный в ответе на UDP ASSOCIATE. Сервер должен отбрасывать датаграммы полученные с любого IP-адреса, отличного от того, что был записан для этой связи.

Поле FRAG показывает, является ли эта датаграмма самостоятельной или же фрагментом. Если датаграмма - фрагмент, то установленный старший бит является признаком последнего фрагмента, в то время как значение X'00' показывает, что это обычная датаграмма. Значения от 1 до 127 обозначают на позицию фрагменте в последовательности. Каждый получатель будет иметь REASSEMBLY QUEUE (очередь сборки) и REASSEMBLY TIMER (таймер сборки) связанные с такой фрагментной датаграммой. Очередь сборки должна быть переинициализирована и связанные с ней фрагменты выкинуты всякий раз при истечении таймера сборки или с приходом новой датаграммы, чье значение в поле FRAG меньше, чем наибольшее значение поля FRAG датаграмм, обработанных при сборке фрагмента. Таймер сборки должен быть не менее 5 секунд. Приложениям рекомендуется избегать фрагментацию везде, где только это возможно.

Реализация фрагментации опциональна, в реализациях где фрагментация не поддерживается, должны отбрасываться любые датаграммы, у которых поле FRAG отлично от X'00'.

Программный интерфейс для UDP работающего через SOCKS должен сообщать о оставшемся свободном пространстве в буфере для UDP-датаграмы, которое меньше, чем действительный размер буфера, выделенный операционной системой:

  • если ATYP равен X'01' - на 10+зависит_от_метода октетов меньше
  • если ATYP равен X'03' - на 262+зависит_от_метода октетов меньше
  • если ATYP равен X'04' - на 20+зависит_от_метода октетов меньше

Иными словами, так как в заголовке UDP-запроса, включенного в датаграмму, нет информации о длинне данных, то приложение должно помнить об этом самостоятельно.

Замечания по безопасности

Этот документ описывает протокол для работы на прикладном уровне с файрволлами в IP-сетях. Безопасность такой работы в большой степени зависит от особенностей аутентификации и инкапсуляции методов, обеспеченных в конкретной реализации и выбранных во время соединения клиента с SOCKS-cервером.

При выборе метода аутентификации администраторы должны проявить особое внимание.

Ссылки

[1]Koblas, D., «SOCKS», Proceedings: 1992 Usenix Security Symposium.

Страница 8 из 8

2007 - 2017 © Русские переводы RFC, IETF, ISOC.