Московский государственный университет имени М.В.Ломоносова
Опубликован: 28.11.2014 | Доступ: свободный | Студентов: 1321 / 115 | Длительность: 23:26:00
ISBN: 978-5-9556-0163-2
Лекция 6:

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

Таблица 6.1.
Состояние Комментарий
Пустое Начальное состояние как инициатора, так и получателя. Инициатор передает 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

Таблица 6.2.
Состояние Событие Действие Новое состояние
Пустое Звонок по несущей или определение входящего соединения, в зависимости от используемого типа сети Инициализация локального открытия туннеля 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 для входящих вызовов являются:

Таблица 6.3.
Состояние Комментарий
Пустое 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

Таблица 6.4.
Состояние Событие Действие Новое состояние
Пустое Получение 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 для входящих вызовов, являются:

Таблица 6.5.
Состояние Комментарий
Пустое Получено 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

Таблица 6.6.
Состояние Событие Действие Новое состояние
Пустое Получение 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 для исходящих вызовов, являются:

Таблица 6.7.
Состояние Комментарий
Пустое Если получен 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

Таблица 6.8.
Состояние Событие Действие Новое состояние
Пустое Локальный запрос открытия Инициациализация локального открытия туннеля 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 для исходящего вызова, являются:

Таблица 6.9.
Состояние Комментарий
Пустое, 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-пакеты.

Задание 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. Завершение установления РРТР-соединения