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

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

Сообщение 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-пакеты.

Рис. 6.16. Задание 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 для пересылки РРР-пакетов. Для управляющего соеди-нения РРТР используется протокол ТСР.

Рис. 6.17. Установление РРТР-соединения

Рис. 6.18. Завершение установления РРТР-соединения