Процедура для клиентов работающих по UDP
Клиент, работающий по UDP, должен посылать свои датаграмы на порт пересылающего их UDP-сервера, указанного в поле BND.PORT в ответе на запрос UDP ASSOCIATE. Если выбранная схема аутентификации требует особое формирование пакетов с целью проверки целостности и/или конфедициальности, датаграмма должна инкапсулироваться в пакет, формат которого определяется выбранной схемой. Каждая UDP-датаграма содержит в себе заголовок UDP-запроса:
| RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
|---|---|---|---|---|---|
| 2 | 1 | 1 | Variable | 2 | Variable |
Поля заголовка 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. |