Способы передачи РРР по Ethernet

Протокол L2TP

Топология

Рассмотрим классический L2TP-сценарий. Цель состоит в том, чтобы туннелировать РРР-кадры между удаленной системой (Remote System – оконечная система или маршрутизатор, соединенный с сетью удаленного доступа, которая является либо инициатором, либо получателем вызова. Также может являться dial-up или виртуальным dial-up клиентом) или LAC (L2TP Access Concentrator – узел, который действует как одна из сторон конечной точки L2TP-туннеля и является противоположной стороной L2TP Network Server – LNS) клиентом и LNS, расположенным в сети организации.

Рис. 6.1. Типичная топология сети при использовании протокола L2TP

Удаленный хост инициализирует РРР-соединение, например, через вы-деленный канал или интернет к LAC. LAC – устройство, функционирующее как одна из сторон конечной точки L2TP-туннеля и являющееся противоположной стороной L2TP Network Server – LNS. LAC расположен между LNS и удаленной системой и перенаправляет пакеты каждой из них. Между LAC и LNS выполняется туннелирование по протоколу L2TP.

LAC туннелирует РРР-соединение к LNS, в результате чего пользова-тель получает доступ к локальной сети организации. Удаленному хосту могут быть предоставлены IP-адреса из LAN посредством NCP переговоров РРР. Управляющий домен в локальной сети может выполнить адресацию, аутентификацию, авторизацию и аккаунтинг (АААА) как если бы пользователь непосредственно соединился с NAS.

LAC-клиент (хост, на котором выполняется L2TP-протокол) может также выполнять туннелирование к LAN без использования отдельного LAC. В этом случае хост, с установленным ПО LAC-клиента, также должен иметь соединение с интернетом. Затем создается виртуальное РРР-соединение, и ПО локального L2TP LAC-клиента создает туннель к LNS. Как и в предыдущем случае адресацию, аутентификацию, авторизацию и аккаунтинг (АААА) выполняет управляющий домен из LAN.

Типы сообщений

В протоколе L2TP существует два типа сообщений: управляющие сообщения и сообщения данных. Управляющие сообщения используются для установления, поддержки и очистки туннелей и вызовов. Сообщения дан-ных используются для инкапсуляции РРР-кадров, передающихся по туннелю. Управляющие сообщения используют надежный канал, гарантирующий доставку. Для сообщений данных при потере пакета повторная передача не используется.

Рис. 6.2. Стек протоколов при передаче РРР по L2TP

Для обеспечения надежной доставки по управляющему каналу в управляющих сообщениях используются последовательные номера.

Формат заголовка L2TP

L2TP-пакеты управляющего канала и канала данных имеют одинаковый формат заголовка. Поля Length, Ns и Nr являются обязательными и должны присутствовать во всех управляющих сообщениях.

Рис. 6.3. Заголовок L2TP-сообщения

Рис. 6.4. Формат L2TP-сообщения

Бит T (Type) определяет тип сообщения. 0 – сообщение данных, 1 – управляющее сообщение.

Если бит L (Length) равен 1, то поле Length присутствует. Этот бит должен быть установлен в 1 для управляющих сообщений.

Если установлен бит S (Sequence), то поля Ns и Nr присутствуют. Бит S установлен в управляющих сообщениях.

Если установлен бит O (Offset), то поле Offset Size присутствует. В управляющих сообщениях данный бит установлен в ноль.

Если установлен бит P (Priority), то данное сообщение должно посылаться с большим приоритетом. Например, LCP-сообщения Echo Request, которые используются для проверки жизнеспособности связи, должно посылаться с этим установленным битом. Этот бит используется только для сообщений данных. В управляющих сообщениях он установлен в ноль.

Версия должна быть установлена в 2. Если версия установлена в 1, то это означает совместимость с протоколом L2F, т.е. L2F-пакеты и L2TP-пакеты могут посылаться вперемешку.

Tunnel ID определяет идентификатор управляющего соединения. L2TP-туннели именуются идентификаторами, которые имеют только локальное значение. Это означает, что один и тот же туннель имеет различные Tunnel ID на разных концах. Tunnel ID в сообщении указан для стороны получателя, а не для стороны отправителя. Tunnel ID выбираются, и их значениями обмениваются при создании туннеля.

Session ID определяет идентификатор сессии внутри туннеля. L2TP-сессии именуются идентификаторами, которые имеют только локальное значение. Это означает, что одна и та же сессия имеет разные значения Session ID на разных концах. Session ID в сообщении указано для стороны получателя, а не для стороны отправителя. Session ID выбираются, и их значениями обмениваются при создании сессии.

Ns указывает последовательный номер сообщения данных или управляющего сообщения.

Nr указывает последовательный номер следующего управляющего сообщения. Таким образом, Nr установлен в Ns последнего полученного сообщения плюс один (по модулю 2¹⁶). В сообщениях данных Nr игнорируется.

Поле Offset Size, если присутствует, указывает, с какого байта после L2TP-заголовка начинаются данные.

Типы управляющих сообщений

В целях расширяемости и интераберабельности в L2TP используется унифицированный метод представления типов сообщений. Это представление обозначается AVP (Attribute-Value Pair).

Message Type AVP определяет тип посылаемого управляющего сообщения, т.е. тех сообщений, у которых установлен бит Т.

Для поддержки управляющего соединения используются следующие сообщения:

1. SCCRQ Start-Control-Connection-Request
2. SCCRP Start-Control-Connection-Replay
3. SCCCN Start-Control-Connection-Connection
4. STOPCCN Stop-Control-Connection-Notification
6. HELLO Hello

   Для поддержки вызова используются следующие сообщения:
7. OCRQ Outgoing-Call-Request
8. OCRP Outgoing-Call-Reply
9. OCCN Outgoing-Call-Connected
10. ICRQ Incoming-Call-Request
11. ICRP Incoming-Call-Reply
12. ICCN Incoming-Call-Connected
14. CDN Call-Disconnect-Notify

    Для отчета об ошибках используется сообщение:
15. WEN WAN-Error-Notify

    Для управления РРР-сессией используется сообщение:
16. SLI Set-Link-Info

Формат AVP

Рис. 6.5. Формат AVP

Первые шесть битов описывают общие атрибуты AVP.

Mandatory (M) бит: управляет реакцией на получение неизвестного AVP. Если бит установлен в AVP, который получатель не может распознать, то сессия, связанная с этим сообщением, завершается. Если сообще-ние связано с туннелем, то закрывается туннель и все сессии внутри него. Если бит М не установлен, то нераспознанный AVP игнорируется. Управляющее сообщение продолжает обрабатываться как если бы AVP не присутствовал.

Hidden (H) бит: указывает на скрытие данных в поле значения атрибута AVP. Это используется, чтобы избежать передачи чувствительных данных, таких как пароли пользователей, в явном виде в AVP. Далее рассмотрим процедуры, выполняющиеся для скрытия AVP.

Length: количество битов в данном AVP. Длина = 6 + длина поля Value в байтах. Длина самого этого поля равна 10 битам, что допускает максимально 1023 байтов данных в одном AVP. Минимальное значение в этом поле равно 6, что означает, что поле Value отсутствует.

Обязательные AVP

Получение неизвестного AVP с установленным битом М приводит к завершению сессии или туннеля, с которым этот AVP связан. Таким образом, бит М устанавливается только в AVP, которые абсолютно критичны для корректного функционирования сессии или туннеля.

Сокрытие значений атрибутов AVP

Бит Н в заголовке каждого AVP предоставляет механизм, с помощью которого можно указать, скрыто ли содержимое, посылаемое противопо-ложной стороной, или передается в явном виде. Данная возможность может быть использована для сокрытия таких чувствительных данных, как пароли или пользовательские идентификаторы.

Бит Н должен быть установлен только в том случае, если между LAC и LNS существует общий секрет. Разделяемый секрет является тем же самым секретом, который используется для аутентификации туннеля. Если бит Н установлен в каком-либо AVP в данном управляющем сообщении, в сообщении должен также присутствовать Random Vector AVP, который дол-жен предшествовать первому AVP с установленным битом Н.

Сокрытие значения AVP выполняется в несколько шагов. Первый шаг состоит в том, что берутся поля длины и значения исходного (не зашифрованного) AVP и преобразуются в формат Hidden AVP следующим образом.

Рис. 6.6. Исходный AVP

Длина значения исходного атрибута: это длина значения исходного атрибута, которое будет скрыто. Это необходимо для определения исходной длины значения атрибута, которая будет потеряна после добавления значений.

Значение исходного атрибута: значение атрибута, которое будет скрыто.

Добавление: случайные добавляемые октеты, используемые для скрытия исходной длины атрибута.

Добавление не изменяет значения поля длины исходного атрибута, но изменяет длину результирующего AVP, который будет создан.

Далее вычисляется хэш-код MD5 для следующего значения:

2 октета номера атрибута + разделяемый секрет + случайный вектор произвольной длины

Значение случайного вектора, используемого в данном хэше, передается в поле значения Random Vector AVP. Данный Random Vector AVP должен быть размещен в сообщении отправителя до любого скрытого AVP. Один и тот же случайный вектор может использоваться для нескольких скрытых AVP в одном и том же сообщении. Если используются разные случайные вектора, то новый случайный вектор должен быть размещен в сообщении перед первым AVP, в котором он применяется.

Затем выполняется XOR значения хэша MD5 и первых 16 октетов (или меньше) значения AVP, который требуется скрыть. Результат помещается в поле значения атрибута Hidden AVP. Если Hidden AVP меньше, чем 16 октет, то перед выполнение XOR оно добавляется до 16 октетов.

Если Hidden AVP длиннее 16 октетов, то вычисляется второе значение MD5 для конкатенации разделяемого секрета и следующими 16 октетами Hidden AVP.

Данная операция повторяется необходимое число раз.