Способы передачи РРР по Ethernet
| Состояние | Комментарий |
|---|---|
| Пустое | Начальное состояние как инициатора, так и получателя. Инициатор передает SCCRQ, получатель остается в пустом состоянии, пока не получит SCCRQ. |
| Wait-ctl-reply | Инициатор проверяет, не запрошено ли других соединений от той же самой противоположной стороны. В этом случае обрабатывает возникшую коллизию. При получении SCCRP он проверяет совместимость версий и переходит в состояние "установлено". Если версия не поддерживается, то посылается STOPCCN и закрывается туннель. |
| Wait-ctl-conn | Состояние, при котором ожидается SCCCN; при получении проверяется ответ. Туннель либо устанавливается, либо закрывается, если не проходит аутентификация. |
| Установлено | Установленное соединение может быть завершено либо в результате локальной причины, либо при получении Stop-Control-Connection-Notification. В случае локального завершения инициатор должен послать Stop-Control-Connection-Notification и очистить туннель. Если инициатор получает Stop-Control-Connection-Notification, он также должен очистить туннель. |
Входящие вызовы
Сообщение 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
| Состояние | Событие | Действие | Новое состояние |
|---|---|---|---|
| Пустое | Звонок по несущей или определение входящего соединения, в зависимости от используемого типа сети | Инициализация локального открытия туннеля | Wait-tunnel |
| Пустое | Получение ICCN, ICRP, CDN | Очистка | Пустое |
| Wait-tunnel | Сброс несущей или локальный запрос закрытия | Очистка | Пустое |
| Wait-tunnel | Открытие туннеля | Посылка ICRQ | Wait-reply |
| Wait-reply | Получение ICRP, принимаемо | Посылка ICCN | Установлено |
| Wait-reply | Получение ICRP, не принимаемо | Посылка CDN, очистка | Пустое |
| Wait-reply | Получение ICRQ | Посылка CDN, очистка | Пустое |
| Wait-reply | Получение CDN, ICCN | Очистка | Пустое |
| Wait-reply | Локальный запрос закрытия или сброс несущей | Посылка CDN, очистка | Пустое |
| Установлено | Получение CDN | Очистка | Пустое |
| Установлено | Получение ICRQ, ICRP, ICCN | Посылка CDN, очистка | Пустое |
| Установлено | Сброс несущей или локальный запрос закрытия | Посылка CDN, очистка | Пустое |
Состояниями, связанными с LAC для входящих вызовов являются:
| Состояние | Комментарий |
|---|---|
| Пустое | LAC определяет входящий вызов на одном из своих интерфейсов. Обычно это означает звонок по аналоговой линии или ISDN, или установление начального соединения по Ethernet. LAC инициирует установление туннеля и переходит в ждущее состояние для подтверждения существования туннеля. |
| Wait-tunnel | В этом состоянии сессия либо ждет открытия управляющего соединения, либо проверки, что туннель уже открыт. После проверки, что туннель уже открыт можно обмениваться управляющими сообщениями. Первым из них должно быть Incoming-Call-Request. |
| Wait-reply | LAC получает либо CDN сообщение, указывающее, что LNS не может принять вызов, после чего переходит в пустое состояние. Или LAC получает Incoming-Call-Reply сообщение, указывающее, что вызов принимается, и LAC посылает Incoming-Call-Connected сообщение и переходит в установленное состояние. |
| Установлено | Данные передаются по туннелю. Вызов может быть сброшен в результате следующих событий: Событие на интерфейсе, на котором установлено соединение: LAC посылает Call-Disconnect-Notify сообщение. Получение Call-Disconnect-Notify сообщения: LAC очищает ресурсы и разрывает соединение. Локальная причина: LAC посылает Call-Disconnect-Notify сообщение. |
Состояния входящего вызова LNS
| Состояние | Событие | Действие | Новое состояние |
|---|---|---|---|
| Пустое | Получение ICRQ, принимаемо | Посылка ICRP | Wait-connect |
| Пустое | Получение ICRQ, не принимаемо | Посылка CDN, очистка | Пустое |
| Пустое | Получение ICRP | Посылка CDN, очистка | Пустое |
| Пустое | Получение ICCN | Очистка | Пустое |
| Wait-connect | Получение ICCN, принимаемо | Подготовка данных | Установлено |
| Wait-connect | Получение ICCN, не принимаемо | Посылка CDN, очистка | Пустое |
| Wait-connect | Получение ICRQ, ICRP | Посылка CDN, очистка | Пустое |
| Пустое, wait-connect, установлено | Получение CDN | Очистка | Пустое |
| Wait-connect, установлено | Локальный запрос закрытия | Посылка CDN, очистка | Пустое |
| Установлено | Получение ICRQ, ICRP, ICCN | Посылка CDN, очистка | Пустое |
Состояниями, связанными с LNS для входящих вызовов, являются:
| Состояние | Комментарий |
|---|---|
| Пустое | Получено Incoming-Call-Request сообщение. Если запрос не принимаем, то обратно к LAC посылается Call-Disconnect-Notify. LNS остается в пустом состоянии. Если Incoming-Call-Request сообщение принимаемо, то посылается Imcoming-Call-Reply. Сессия переходит в состояние wait-connect. |
| Wait-connect | Если сессия уже установлена с LAC, LAC посылает Incoming-Call-Connect сообщение к LNS, который после этого переходит в состояние "установлено". LAC может послать Call-Disconnect-Notify для определения того, что входящий вызов не отсоединен. |
| Установлено | Сессия завершается либо при получении Call-Disconnect-Notify сообщения от LAC, либо посылкой Call-Disconnect-Notify. Происходит очистка на обоих концах, не зависимо от того, кто был инициатором. |
Исходящие вызовы
Исходящие вызовы инициируются 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
| Состояние | Событие | Действие | Новое состояние |
|---|---|---|---|
| Пустое | Получение OCRQ, принимаемо | Посылка OCRP, открытие несущей | Wait-cs-answer |
| Пустое | Получение OCRQ, не принимаемо | Посылка CDN, очистка | Пустое |
| Пустое | Получение OCRP | Посылка CDN, очистка | Пустое |
| Пустое | Получение OCCN, CDN | Очистка | Пустое |
| Wait-cs-answer | Ответ несущей, определение кадров | Посылка OCCN | Установлено |
| Wait-cs-answer | Сбой несущей | Посылка CDN, очистка | Пустое |
| Wait-cs-answer | Получение OCRQ, OCRP, OCCN | Посылка CDN, очистка | Пустое |
| Установлено | Получение OCRQ, OCRP, OCCN | Посылка CDN, очистка | Пустое |
| Wait-cs-answer, установлено | Получение CDN | Очистка | Пустое |
| Установлено | Сброс несущей, локальный запрос закрытия | Посылка CDN, очистка | Пустое |
Состояниями, связанными с LAC для исходящих вызовов, являются:
| Состояние | Комментарий |
|---|---|
| Пустое | Если получен Outgoing-Call-Request с указанием ошибки, ответом является Call-Disconnect-Notify. В противном случае отводятся ресурсы для физического канала и посылается Outgoing-Call-Reply. Отводятся ресурсы для исходящего вызова, и LAC переходит в состояние wait-cs-answer. |
| Wait-cs-answer | Если вызов не выполнен или истек таймер ожидания выполнения вызова, посылается Call-Disconnect-Notify с указанием соответствующей ошибки. LAC переходит в пустое состояние. Если соединение на данной стороне установлено и определены кадры, посылается Outgoing-Call-Connected, указывающее на успешное завершение установления соединения. LAC переходит в состояние "установлено". |
| Установлено | Если LAC получил Call-Disconnect-Notify, телекоммуникационный вызов должен быть обработан с помощью соответствующих механизмов и сессия очищена. Если вызов сброшен клиентом или вызывающим интерфейсом, к LNS посылается сообщение Call-Disconnect-Notify. После посылке этого сообщения отправитель Call-Disconnect-Notify переходит в пустое состояние. |
Состояния исходящего вызова LNS
| Состояние | Событие | Действие | Новое состояние |
|---|---|---|---|
| Пустое | Локальный запрос открытия | Инициациализация локального открытия туннеля | Wait-tunnel |
| Пустое | Получение OCCN, OCRP, CDN | Очистка | Пустое |
| Wait-tunnel | Открытие туннеля | Посылка OCRQ | Wait-reply |
| Wait-reply | Получение OCRP, принимаемо | Нет | Wait-connect |
| Wait-reply | Получение OCRP, не принимаемо | Посылка CDN, очистка | Пустое |
| Wait-reply | Получение OCCN, OCRQ | Посылка CDN, очистка | Пустое |
| Wait-connect | Получение OCCN | Нет | Установлено |
| Wait-connect | Получение OCRQ, OCRP | Посылка CDN, очистка | Пустое |
| Пустое, wait-reply, wait-connect, установлено | Получение CDN | Очистка | Пустое |
| Установлено | Получение OCRQ, OCRP, OCCN | Посылка CDN, очистка | Пустое |
| Wait-reply, wait-connect, установлено | Локальный запрос закрытия | Посылка CDN, очистка | Пустое |
| Wait-tunnel | Локальный запрос закрытия | Очистка | Пустое |
Состояниями, связанными с LNS для исходящего вызова, являются:
| Состояние | Комментарий |
|---|---|
| Пустое, wait-tunnel | При инициации исходящего вызова во-первых создается туннель, а также состояниями входящего вызова LAC становятся пустое и wait-tunnel. После того, как туннель установлен, к LAC посылается Outgoing-Call-Request сообщение, и сессия переходит в состояние wait-reply. |
| Wait-reply | Если полученоCall-Disconnect-Notify, то это означает, что произошла ошибка, сессия очищается и возвращается в пустое состояние. Если получено Outgoing-Call-Reply, то это означает, что происходит вызов, и сессия переходит в состояние wait-connect. |
| Wait-connect | Если получен Call-Disconnect-Notify, вызов сбрасывается; сессия очищается и возвращается в пустое состояние. Если получен Outgoing-Call-Connected, то вызов считается успешным, и в сессии можно обмениваться данными. |
| Установлено | Если получен Call-Disconnect-Notify, вызов завершается по причине, указанной в кодах результата. Сессия переходит в пустое состояние. Если LNS решает завершить сессию, он посылает Call-Disconnect-Notify к LAC, затем очищает сессию и переводит ее в пустое состояние. |
Завершение туннеля
Туннель завершается, когда любой из участников посылает 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 для пересылки РРР-пакетов. Для управляющего соеди-нения РРТР используется протокол ТСР.
