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

o RSV зарезервировано X'0000'
o FRAG текущий номер фрагмента
o ATYP тип адреса:
o IP v4 адрес: X'01'
o имя домена: X'03'
o IP v6 адрес: X'04'
o DST.ADDR требуемый целевой адрес
o DST.PORT требуемый целевой порт
o 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'.


Leech, et al Standards Track [Страница 8]

RFC 1928 Протокол SOCKS 5 Март 1996

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

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

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

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

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

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

Careful consideration should be given by the administrator to the
selection of authentication methods.

9. Ссылки

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

Адрес автора

Marcus Leech
Bell-Northern Research Ltd
P.O. Box 3511, Stn. C,
Ottawa, ON
CANADA K1Y 4H7

Phone: (613) 763-9145
EMail: mleech@bnr.ca

Leech, et al Standards Track [Страница 9]

------------------------------------------------------------------------
Не стреляйте в переводчика, он переводит как умеет (с) неизвестен
Перевод сделан Александром Горлачем, alex@gorlach.koenig.su
------------------------------------------------------------------------