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

Обзор существующих AVP

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

AVP, используемые во всех управляющих сообщениях

Message Type (все сообщения)

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

Бит Mandatory (M) в Message Type AVP имеет специальное значение. Он указывает, что сам AVP должен игнорироваться, если не распознается. Он также определяет, что само управляющее сообщение должно игнорироваться. Таким образом, если бит М установлен в Message Type AVP, и Message Type не известен, то туннель уничтожается. Если бит М не установлен, то неизвестный тип сообщения может игнорироваться.

Random Vector (все сообщения)

Random Vector AVP используется для обеспечения возможности скрытия значений некоторых AVP. Этот случайный вектор будет использоваться при вычислении хэш-кода MD5 для скрытых значений.

В сообщение может быть несколько Random Vector AVP. Данный AVP посылается до первого AVP с установленным битом H.

Бит М в данном AVP установлен, AVP не должен быть скрыт.

Коды результата и коды ошибок

Result Code (CDN, STOPCCN)

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

В сообщении STOPCCN определены следующие коды результата:

В сообщении CDN определены следующие коды результата:

Коды ошибок, приведенные ниже, не относятся к типам ошибок, которые специфичны для конкретного L2TP-запроса, а скорее к ошибкам протокола или формата сообщений. Если в L2TP-ответе указано, что произошла общая ошибка, необходимо проанализировать значение General Error, чтобы определить конкретную причину. Определены следующие коды ошибок:

AVP, используемые в управляющих соединениях

Protocol Version (SCCRP, SCCRQ)

Значение 2 указывает на протокол L2TP.

Framing Capabilities (SCCRP, SCCRQ)

AVP указывает противоположной стороне тип обработки: синхронная или асинхронная. Противоположная сторона не должна делать запрос входящего или исходящего вызова со значением Framing Type AVP, которое не соответствует полученному при установлении управляющего соединения. Попытки сделать это приведут к тому, что вызов будет сброшен.

Данный AVP может быть скрыт. Бит М для данного AVP всегда установлен.

Bearer Capabilities (SCCRP, SCCRQ)

Bearer Capabilities AVP указывает противоположной стороне типы устройств аппаратных интерфейсов, а именно, поддерживается ли аналоговый и цифровой доступ.

LNS не должен в исходящем вызове указывать значение в Bear Capabilities AVP, которое не соответствует тому, которое он получил от LAC при установлении управляющего соединения. Попытка сделать это приведет к тому, что вызов будет сброшен.

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

Данный AVP может быть скрыт, бит М не установлен.

Tie Breaker (SCCRQ)

Tie Breaker AVP говорит о том, что отправитель хочет, чтобы существовал единственный туннель между данной парой LAC-LNS.

Host Name (SCCRP, SCCRQ)

Host Name AVP указывает имя LAC или LNS, чаще всего это DNS-имя.

Assigned Tunnel ID (SCCRP, SCCRQ, STOPCCN)

Assigned Tunnel ID AVP указывает идентификатор, связанный с данным туннелем отправителем. Данное значение используется для мультиплексирования и демультиплексирования нескольких туннелей между LNS и LAC. Противоположная сторона размещает данное значение в заголовке Tunnel ID во всех управляющих сообщениях и сообщениях данных, которые передаются по этому туннелю. Перед тем, как получить Assigned Tunnel ID AVP от противоположной стороны, данной стороне посылаются управляющие сообщения со значением Assigned Tunnel ID, равным нулю.

В управляющем сообщении STOPCCN Assigned Tunnel ID AVP имеет тоже самое значение, что и в первый раз посланный Assigned Tunnel ID AVP, что позволяет противоположной стороне определить соответствующий туннель, даже если STOPCCN послан до того, как получен Assigned Tunnel ID AVP.

Данный AVP может быть скрыт. Бит М должен быть установлен.

Receive Window Size (SCCRQ, SCCRP)

Receive Window Size AVP определяет размер окна получателя.

Challenge (SCCRP, SCCRQ)

Challenge AVP говорит о том, что противоположная сторона хочет выполнить аутентификацию с использованием СНАР-механизма.

Данный AVP может быть скрыт. Бит М для данного AVP всегда установлен.

Challenge Response (SCCCN, SCCRP)

Response AVP передает ответ на полученный запрос.

Данный AVP всегда присутствует в SCCRP или SCCCN, если ранее был получен запрос в SCCRQ или SCCRP.

Данный AVP может быть скрыт. Бит М должен быть установлен.

Операции протокола

Установка туннелирования для РРР-сессии состоит из двух шагов:

Туннель и управляющее соединение должны быть установлены до инициализации входящего или исходящего вызова. L2TP-сессия должна быть установлена до того, как L2TP начнет туннелировать РРР-кадры. Че-рез единственный туннель может существовать несколько сессий, несколь-ко туннелей может быть создано между одними и теми же LAC и LNS.

Установление управляющего соединения

Управляющее соединение является начальным соединением, которое должно быть установлено до того, как между LAC и LNS будут установлены сессии. Установление управляющего соединения включает обеспечение безопасности идентификаций участников и т.п.

Установление управляющего соединения начинается с обмена следующими сообщениями:

ZLB ACK посылается, если в очереди нет сообщений.

Аутентификация туннеля

L2TP выполняет простую, не обязательную, СНАР-подобную аутентификацию туннеля при установлении управляющего соединения. Если LAC или LNS хочет аутентифицировать другого участника, в сообщение SCCRQ или SCCRP включается Challenge AVP. Если Challenge AVP получено, то Challenge Response AVP должен быть послан в следующем SCCRP или SCCRN соответственно. Если ответ не соответствует ожидаемому, установление туннеля должно быть сброшено.

Аутентификация выполняется с помощью разделяемого между LAC и LNS секрета. Тот же самый секрет используется для сокрытия AVP.

Установление сессии

После успешного установления управляющего соединения могут создаваться отдельные сессии. Каждая сессия соответствует одному потоку РРР между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является направленным от LAC к LNS. LAC запрашивает сессию для входящего вызова, LNS отвечает.

Установление входящего вызова

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

ZLB ACK посылается, если больше нет сообщений в очереди к противоположной стороне.

Установление исходящего вызова

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

ZLB ACK посылается, если больше нет сообщений в очереди к проти-воположной стороне.

Перенаправление РРР-кадров

После того, как завершено установление туннеля, РРР-кадры из удаленной системы получаются LAC, выполняются необходимые действия (удаление CRC, выполнение фрагментирования и т.п.), выполняется инкап-суляция в L2TP и перенаправление в соответствующий туннель. LNS получает L2TP-пакет, обрабатывает инкапсулированный РРР-кадр как если бы он был получен на локальном РРР-интерфейсе.

Отправитель сообщения, связанного с конкретной сессией и туннелем, размещает Session ID и Tunnel ID (указанные противоположной стороной) в заголовке Session ID и Tunnel ID для всех исходящих сообщений. Таким образом, РРР-кадры мультиплексируются в единственный туннель между LNS и LAC. В туннеле может существовать несколько сессий.

Нулевые значения Session ID и Tunnel ID используются для установления новой сессии.

Использование последовательных номеров в канале данных

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

В отличие от управляющего L2TP-канала канал данных L2TP не использует последовательные номера для повторной передачи потерянных сообщений данных. Сообщения данных могут использовать последовательные номера для определения потерянных пакетов или восстановления исходной последовательности пакетов, если при пересылке нарушена последовательность. LAC может потребовать, чтобы последовательные номера присутствовали в сообщениях данных, используя Sequencing Required AVP. Если данный AVP присутствует при установке сессии, последовательные номера должны указываться во всех сообщениях. Если данный AVP не присутствует, наличием последовательных номеров управляет LNS. Наличие или отсутствие последовательных номеров определяется посылкой сообщения с последовательным номеров в любое время в течение времени жизни сессии. Таким образом, если LAC получает сообще-ние данных без последовательного номера, он должен не посылать после-довательные номера во всех следующих исходящих сообщениях данных.

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

Keepalive (Hello)

Механизм keepalive реализован в L2TP, чтобы определять отключения туннеля. Это достигается отправкой управляющих сообщений Hello через определенный период времени, прошедший после получения последнего управляющего сообщения или сообщения данных. Как и в случае любого другого управляющего сообщения, если сообщение Hello не доставлено, то туннель считается отключенным и переустанавливается. Механизм переустановки транспорта вместе со вставленными сообщениями Hello гарантирует, что разрыв соединения между LNS и LAC будет определен на обоих концах туннеля.

Завершение сессии

Завершение сессии может инициализироваться и LAC, и LNS, и состоит в посылке управляющего сообщения CDN. После того, как последняя сессия завершена, управляющее соединение может быть удалено. Типичный пример обмена сообщениями в этом случае следующий:

Завершение управляющего соединения

Завершение управляющего соединения может инициироваться и LAC, и LNS. Оно состоит в посылке единственного управляющего сообщения STOPCCN. Получатель STOPCCN должен послать ZLB ACK для подтверждения получения сообщения и поддержания состояния управляющего соединения, если ZLB ACK будет потерян. Типичный обмен сообщениями следующий:

Надежная доставка управляющих сообщений

L2TP обеспечивает надежную доставку всех управляющих сообщений. Для этого используются поля Nr и Ns в заголовке управляющего сообщения. Функции более высокого уровня в L2TP не занимаются повтором или переупорядочиванием управляющих сообщений. Каждая сторона поддерживает отдельные последовательные номера для каждого конца туннеля.

Последовательные номера управляющих сообщений возрастают на единицу. Исключением являются только ZLB-сообщений.

Номер последнего полученного сообщения передается противоположной стороне в поле Nr.

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

В каждом туннеле поддерживается очередь управляющих сообщений, которые должны быть переданы противоположной стороне. Сообщение в начале очереди посылается с текущим значением Ns и хранится до тех пор, пока противоположная сторона не подтвердит получение сообщения в поле Nr. Если подтверждение не получено в течение определенного периода времени (по умолчанию 1 секунда), сообщение передается повторно. Повторное сообщение содержит то же самое значение Ns, но значение Nr должно быть изменено на последовательный номер следующего ожидаемого сообщения.

Интервал между следующими повторными передачами должен возрастать экспоненциально. Таким образом, если первая повторная передача происходит через 1 секунду, то следующая повторная передача должна произойти через 2 секунды, затем через 4 секунды и т.д. Если противоположная сторона не отвечает после нескольких повторных передач (по умолчанию 5), то туннель и все сессии закрываются.

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

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

Протокол управляющего соединения

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

Start-Control-Connection-Request (SCCRQ)

Управляющее сообщение SCCRQ используется для инициализации туннеля между LNS и LAC. Оно посылается либо LAC, либо LNS для установления туннеля.

В SCCRQ должны быть следующие AVP:

•	Message Type AVP
•	Protocol Version
•	Host Name
•	Framing Capabilities
•	Assinged Tunnel ID 

Start-Control-Connection-Reply (SCCRP)

Управляющее сообщение SCCRP посылается в ответ на получение SCCRQ сообщения. SCCRP используется для указания того, что SCCRQ получено, и установление туннеля должно продолжаться.

Start-Control-Connection-Connected (SCCCN)

Управляющее сообщение SCCCN посылается в ответ на SCCRP. Оно завершает процесс установления туннеля.

Stop-Control-Connection-Notification (STOPCCN)

Управляющее сообщение STOPCCN посылается либо LAC, либо LNS для информирования противоположной стороны о том, что туннель завершается, и управляющее соединение должно быть закрыто. Кроме того, все управляющие сессии должны быть неявно очищены (без посылки каких-либо управляющих сообщений). Причина данного запроса указана в Result Code AVP. На данное сообщение нет явного ответа, только неявное подтверждение на транспортном уровне, что получено управляющее сообщение.

Hello

Сообщение Hello периодически посылается любым из участников для подтверждения жизнеспособности ("keepalive") туннеля.

Надежность доставки этого сообщения гарантируется лежащим ниже транспортом.

Сообщения Hello являются глобальными для туннеля. Session ID в сообщении Hello установлено в 0.

Incoming-Call-Request (ICRQ)

Управляющее сообщение ICRQ посылается от LAC к LNS, когда определен входящий вызов. Это первое из трех сообщений, которые используются для установления сессии в L2TP-туннеле.

ICRQ используется для указания того, что для данного вызова устанавливается сессия между LAC и LNS и предоставляет LNS-параметры сессии. LAC может отложить ответ на вызов до тех пор, пока он не получит ICRQ от LNS, указывающее, что сессия должна быть установлена. Данный механизм позволяет LNS получать информацию о вызове до определения того, нужно ли на него отвечать или нет. В качестве альтернативы LAC может ответить на вызов, начать переговоры об LCP и РРР-аутентификации и использовать информацию, полученную для выбора LNS. В этом случае при получении сообщения ICRP на вызов уже будет дан ответ. LAC просто игнорирует шаги "индикация вызова" и "ответ вызова".

Incoming-Call-Reply (ICRP)

Управляющее сообщение ICRP посылается от LNS к LAC в ответ на получение сообщения ICRQ. Это второе из трех сообщений, используемых для установления сессий в L2TP-туннеле.

ICRP используется для указания того, что ICRQ было успешным и для того, чтобы LAC ответил на вызов, если он еще не сделал этого. Это также позволяет LNS указать необходимые параметры L2TP-сессии.

Incoming-Call-Connection (ICCN)

Управляющее сообщение ICCN посылается от LAC к LNS в ответ на получение сообщения ICRР. Это третье из трех сообщений, используемых для установления сессий в L2TP-туннеле.

ICCN используется для указания того, что ICRP получено, на вызов был дан ответ, и что L2TP-сессия находится в состоянии "установлено". Оно также предоставляет LNS дополнительную информацию об используемых параметрах, которые еще могли быть не доступны при посылке сообщения ICRQ.

Outgoing-Call-Request (OCRQ)

Управляющее сообщение OCRQ посылается от LNS к LAC для указания того, что исходящий вызов от LAC установлен. Это первое из трех сообщений, используемых для установления сессии в L2TP-туннеле.

OCRQ используется для указания того, что для данного вызова сессия между LNS и LAC установлена.

LNS при установлении туннеля получает от LAC Bearer Capabilities AVP, чтобы запросить исходящий вызов к данному LAC.

Outgoing-Call-Reply (OCRP)

Управляющее сообщение OCRP посылается от LAC к LNS в ответ на получение сообщения OCRQ. Это второе из трех сообщений, используемых для установления сессии в L2TP-туннеле.

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

Outgoing-Call-Connection (OCCN)

Управляющее сообщение OCCN посылается от LAC к LNS после OCRP и после того, как исходящий вызов завершен. Это заключительное сообщение из трех сообщений, используемых для установления сессии в L2TP-туннеле.

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

Call-Disconnect-Notify (CDN)

Управляющее сообщение CDN посылается либо LAC, либо LNS для запроса разрыва соединения внутри туннеля. Его цель состоит в информировании противоположной стороны о разрыве соединения и о причине этого разрыва. Противоположная сторона очищает все ресурсы и не посылает никакого ответного уведомления.

WAN-Error-Notify (WEN)

Управляющее сообщение WEN посылается от LAC к LNS для указания об условиях ошибки WAN (условиях, которые произошли на интерфейсе, поддерживающим РРР).

Set-Link-Info (SLI)

Управляющее сообщение SLI посылается от LNS к LAC для установления РРР-опций. Эти опции могут быть изменены в течение всего времени жизни соединения, тем самым LAC имеет возможность изменить свою информацию и поведение РРР-сессии.

Состояния управляющего соединения

Описанными выше управляющими сообщениями обмениваются приведенным в таблицах способом. Таблицы определены для входящих и исходящих вызовов, а также для инициализации самого туннеля. В таблицах состояний не определены таймауты и поведение при повторных передачах.

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

Протокол управляющего соединения не делает различая между LNS и LAC, но делает различие между отправителем и получателем. Туннель инициирует отправитель. Так как и LAC, и LNS могут быть отправителями, может возникнуть коллизия.

Установление управляющего соединения

Состояниями, связанными с LNS или LAC для установленного управляющего соединения, являются:

Входящие вызовы

Сообщение Incoming-Call-Request создается LAC, когда определен входящий вызов (это может быть не только звонок в телефонной линии, но и инициализация ТСР-соединения, если удаленная система подсоединена через интернет). LAC выбирает идентификатор сессии и серийный номер и определяет тип вызова. ISDN-вызов должен указываться как цифровой. Могут также указываться вызываемый номер, вызвавший номер и подадрес, если эта информация доступна.

После того, как LAC посылает Incoming-Call-Request, он ждет ответ от LNS, но не обязательно должен быть ответный вызов от LNS к LAC. LNS может не принимать вызов, если:

Если LNS решает принимать вызов, он отвечает Incoming-Call-Reply. Когда LAC получает Incoming-Call-Reply, он пытается соеди-нить вызов. Завершающее сообщение от LAC к LNS указывает, что состоя-ния вызова как для LAC, так и для LNS должны перейти в установленное состояние. Если вызов завершается до того, как LNS может принять его, LAC посылает Call-Disconnect-Notify для указания этого условия.

Когда звонящий клиент вешает трубку, вызов очищается обычным образом, и LAC посылает Call-Disconnect-Notify сообщение. Если LNS хочет очистить вызов, он посылает Call-Disconnect-Notify сообщение и очищает свою сессию.

Состояния входящего вызова LAC

Состояниями, связанными с LAC для входящих вызовов являются:

Состояния входящего вызова LNS

Состояниями, связанными с LNS для входящих вызовов, являются:

Исходящие вызовы

Исходящие вызовы инициируются LNS и требуют от LAC принять вызов. Для исходящих вызовов существует три сообщения: Outgoing-Call-Request, Outgoing-Call-Reply и Outgoing-Call-Connected. LNS посылает Outgoing-Call-Request, указывая номер телефона звонящего, подадрес и другие параметры. Номер телефона указывается всегда, не зависимо от типа сети, для обеспечения интероперабельности с наследуемы-ми приложениями. LAC отвечает на Outgoing-Call-Request сообщением Outgoing-Call-Reply после того, как определит, что существуют возможности принять вызов, и вызов разрешен администратором. После того, как исходящий вызов соединен, LAC посылает Outgoing-Call-Connected сообщение к LNS, указывая конечный результат вызова.

Состояния исходящего вызова LAC

Состояниями, связанными с LAC для исходящих вызовов, являются:

Состояния исходящего вызова LNS

Состояниями, связанными с LNS для исходящего вызова, являются:

Завершение туннеля

Туннель завершается, когда любой из участников посылает Stop-Control-Connection-Notification. Отправитель этого уведомления должен ждать в течение определенного периода времени подтверждения перед тем, как удалить управляющую информацию, связанную с туннелем. Получатель данного уведомления должен послать подтверждение и удалить соответствующую управляющую информацию.

Выполнение L2TP поверх UDP/IP

Протокол L2TP является самодостаточным и может функционировать в различных средах. Тем не менее необходимо знать некоторые детали, связанные со средой.

L2TP использует UDP-порт 1701. Весь L2TP-пакет, включая содержимое и L2TP-заголовок, посылается в UDP-дейтаграмме. Инициатор L2TP-туннеля выбирает доступный UDP-порт источника (который может и отличаться от 1701) и посылает пакет получателю на порт 1701. Получатель выбирает свободный порт в своей системе (который может и отличаться от 1701) и посылает ответ инициатору на его UDP-порт. После того, как адре-са и порты инициатора и получателя установлены, они остаются постоянными с течение всего времени жизни канала.

Считается, что, так как получатель может выбрать произвольный порт источника (в отличие от порта назначения в пакете, инициирующем туннель, который должен быть 1701), это может вызвать проблемы, связанные с прохождением NAT.

Также может иметь место фрагментация IP. В протоколе L2TP ничего не делается для оптимизации этого. LAC может использовать LCP для ве-дения переговоров о конкретном значении MRU, которое может быть оптимизировано для окружения LAC и согласовано со значением MTU в пути, по которому пересылаются L2TP-пакеты.

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

Порт 1701 используется как L2F-, так и L2TP-пакетами. Эти пакеты отличаются значением поля версии.

Для РРР-клиентов, использующих L2TP-over-UDP/IP туннель, РРР-канал имеет характеристики, которые дают возможность переупорядочивать или молча отбрасывать пакеты. Первый вариант может привести к тому, что не смогут использоваться не-IP-протоколы, передаваемые по РРР. Второй вариант может привести к тому, что не смогут использоваться протоколы, в которых ошибки определяются на уровне пакетов, такие как сжатие заголовка ТСР. Правильная последовательность может обеспечиваться последовательными номерами в сообщениях данных L2TP, если протокол, передаваемый по РРР-туннелю, не поддерживает переупорядочивание.

Возможность молча отбрасывать пакеты является наиболее проблематичной для некоторых протоколов. Если в РРР включена надежная доставка, то в протоколах более высокого уровня не будет потерь пакетов. Если в L2TP используются последовательные номера, то L2TP может определить потерю пакета. В случае LNS оба стека, и РРР, и L2TP присутствуют в LNS, и потеря пакета может быть обнаружена, если пакет получен с ошибкой контрольной суммы. Если стеки LAC и РРР не присутствуют одновременно, то эта технология также может использоваться.

Обсуждение безопасности

L2TP имеет несколько проблем, связанных с безопасностью.

Безопасность конечной точки туннеля

Конечные точки туннеля могут дополнительно выполнять аутентификацию друг друга при установлении туннеля. Характеристики этой аутентификации такие же, как у СНАР, т.е. аутентификация защищена от replay-атак и от атак, связанных с подделкой, при установлении туннеля. Данный механизм не предполагает никакой аутентификации после того, как туннель установлен. Это приводит к тому, что достаточно просто вставить пакеты в поток после того, как выполнена аутентификация конечных точек туннеля.

Для выполнения аутентификации LAC и LNS должны разделять общий секрет. Так как используется единственный секрет, AVP, аутентифицирующие туннель, содержат различные значения полей CHAP ID, используемые для вычисления дайджеста, чтобы гарантировать защиту от replay-атак.

Безопасность на уровне пакетов

Для обеспечения безопасности L2TP требуется, чтобы нижележащий транспорт мог предоставлять сервисы шифрования, целостности и аутентификации для всего L2TP-трафика. Этот безопасный транспорт оперирует со всем L2TP-пакетом и функционально не зависит от РРР и протокола, который доставляется по РРР. Таким образом, L2TP предоставляет сервисы конфиденциальности, целостности и аутентификации L2TP-пакетов между конечными точками туннеля (LAC и LNS), но не с шифрованием на уровне канала и обеспечением конфиденциальности трафика между физическими конечными точками.

End-to-end безопасность

Обеспечение защиты потока L2TP-пакетов на транспортном уровне означает безопасность данных, которые туннелируются РРР-пакетами, от LAC к LNS. Это не означает end-to-end безопасности между взаимодействующими хостами или приложениями.

L2TP и IPSec

При выполнении поверх IP IPSec обеспечивает безопасность на уровне пакетов с помощью ESP или АН. Все управляющие пакеты и пакеты данных L2TP, относящиеся к конкретному туннелю, являются для IPSec однородными UDP/IP пакетами.

В дополнение к транспортной безопасности на уровне IP в IPSec определен режим, который позволяет туннелировать IP-пакеты. Шифрование и аутентификация на уровне пакетов, предоставляемая туннельным режимом IPSec, и безопасность, обеспечиваемая L2TP совместно с IPSec, имеют эквивалентные характеристики.

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

Протокол РРТР

Протоколы L2TP и РРТР имеют много общего. Протокол L2TP был разработан на основе протоколов L2F и РРТР.

Одно из основных различий состоит в том, что протокол РРТР использует протокол GRE для пересылки РРР-пакетов. Для управляющего соеди-нения РРТР используется протокол ТСР.

Протокол PPPoE

Данный протокол представляет собой способ передачи по Ethernet протоколов РРР, таких как LCP, управляющих протоколов сетевого уровня, аутентификации и т.п. Эти возможности предоставляются для взаимодействия участников типа точка-точка и не предназначены для многоадресного взаимодействия, которое возможно в сети Ethernet и других аналогичных окружениях.

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

Обзор

Современные технологии доступа предназначены для нескольких конфликтующих друг с другом целей. Желательно установить соединение с несколькими хостами через одно и то же устройство доступа. Также необ-ходимо обеспечить управление доступом и возможности биллинга способом, аналогичным dial-up сервисам, использующим РРР. Во многих технологиях доступа наиболее эффективным является использование Ethernet для подсоединения нескольких хостов через одно и то же устройство доступа. Кроме того, желательно максимально снизить стоимость такого устройства и минимизировать необходимость конфигурирования.

РРРоЕ предоставляет возможность подсоединять к сети хосты через единственное устройство, которое обеспечивает доступ к удаленному Access Concentrator (NAC). При таком подходе каждый хост использует свой собственный РРР-канал, а пользователь имеет простой интерфейс. Управление доступом, биллинг и предоставляемые типы сервисов могут определяться на уровне пользователя.

Для предоставления соединения точка-точка по Ethernet каждая РРР-сессия должна знать Ethernet-адрес удаленной стороны, а также установить уникальный идентификатор сессии. В РРРоЕ определен протокол обнаружения, который выполняет эти задачи.

РРРоЕ имеет две стадии: стадия обнаружения (Discovery) и стадия РРР-сессии. Когда хост хочет установить РРРоЕ-сессию, он должен во-первых выполнить стадию Discovery для определения Ethernet МАС-адреса противоположной стороны и установить РРРоЕ SESSION_ID. Хотя РРР определяет взаимодействие типа точка-точка, Discovery наследует клиент-серверное взаимодействие. В процессе обнаружения Хост (клиент) определяет Access Concentrator (сервер). В зависимости от сетевой тополо-гии может быть несколько Access Concentrator, с которыми может взаимо-действовать Хост. Стадия Discovery позволяет Хосту обнаружить все Access Concentrator и выбрать один из них. При успешном завершении ста-дии Discovery как Хост, так и выбранный Access Concentrator обладают информацией, которую они будут использовать для создания своего собственного соединения точка-точка по сети Ethernet.

Стадия Discovery не поддерживает состояние до тех пор, пока не установлена РРР-сессия. После установления РРР-сессии как Хост, так и Access Concentrator выделяют ресурсы для виртуального РРР-интерфейса.

Содержимое пакетов

Пакеты имеют следующий формат.

Поле DESTINATION_ADDR содержит либо единственный Ethernet-адрес получателя, либо широковещательный Ethernet-адрес (0xffffffff). Для пакетов Discovery значением является либо единственный, либо широковещательный адрес. Для трафика РРР-сессии данное поле должно содержать адрес противоположной стороны.

Поле SOURCE_ADDR должно содержать Ethernet МАС-адрес источника.

Поле ETHER_TYPE определяет либо стадию Discovery, либо стадию РРР-сессии.

Стадия Discovery

На стадии Discovery существует четыре шага. После завершения данной стадии оба участника знают PPPoE SESSION_ID и Ethernet-адрес противоположной стороны, которые уникально определяют РРРоЕ-сессию. Шаги включают отправку Хостом широковещательного пакета Initiation, и получение от одного или более NAC пакета Offer. Затем Хост посылает одноадресный пакет Session Request, и выбранный NAC отвечает пакетом Confirmation. После получения Хостом пакета Confirmation, он начинает стадию установления РРР-сессии.

Содержимое РРРоЕ состоит из нуля или более атрибутов, которые в данном случае называются тегами (TAG). TAG являетсятройкой TLV (type-length-value).

1. Пакет PPPoE Active Discovery Initiation (PADI)

Хост посылает пакет PADI с широковещательным адресом, установленным в поле DESTINATION_ADDR.

2. Пакет PPPoE Active Discovery Offer (PADO)

При получении пакета PADI NAC отвечает пакетом PADO. Поле DESTINATION_ADDR содержит адрес Хоста, который послал пакет PADI. Пакет PADO должен содержать AC-Name TAG с именем NAC.

3. Пакет PPPoE Active Discovery Request (PADR)

Так как пакет PADI является широковещательным, Хост может получить более одного пакета PADI, из которых он должен выбрать один. Выбор может быть основан на AC-Name или предлагаемых сервисах. Затем Хост посылает пакет PADR к NAC, который он выбрал. Поле DESTINATION_ADDR установленов Ethernet-адресполучателя.

4. Пакет PPPoE Active Discovery Session-confirmation (PADS)

Когда NAC получает пакет PADS, он обрабатывает его и начинает РРР-сессию. Он создает уникальный SESSION_ID для данной РРРоЕ-сессии и возвращает пакет PADS Хосту.

5. Пакет PPPoE Active Discovery Termination (PADT)

Данный пакет может быть послан в любое время, после того, как сессия установлена, для указания того, что РРРоЕ-сессия завершается. Он может быть послан как Хостом, так и NAC.

При получении PADT никакой РРР-трафик не должен посылаться в рамках данной сессии. После посылки или получения PADT не должны посылаться даже обычные пакеты завершения РРР. РРР противоположной стороны может использовать сам протокол РРР для завершения РРРоЕ-сессии, но PADT может использоваться и тогда, когда РРР не используется.

Стадия РРР-сессии

После того, как РРРоЕ-сессия началась, РРР-данные посылаются как вложенные данные. Все Ethernet-пакеты являются одноадресными. SESSION_ID не изменяется для данной РРРоЕ-сессии и определяется на стадии обнаружения. Содержимым РРРоЕ является РРР-кадр. Кадр начинается с Protocol-ID PPP.

Не должны вестись переговоры о максимальном возможном блоке (Maximum-Receive-Unit - MRU), размер которого больше 1492. Так как максимальный размер содержимого Ethernet 1500 байтов, РРРоЕ-заголовок равен 6 байтам, и Protocol ID PPP равен 2 байтам, то РРР MTU не может быть больше, чем 1492.

Обычно NAC посылает Echo-Request пакеты к Хосту для определения состояния сессии. В противном случае, если Хост завершает сессию без отправления Terminate-Request пакета, NAC не имеет возможности определить, что сессия завершилась.

Когда LCP завершается, и Хост, и NAC перестают использовать данную сессию. Если Хост хочет начать другую РРР-сессию, он должен заново повторить стадию Discovery РРРоЕ.