Совместное использование протоколов L2TP и IPSec
Основные принципы совместного использования L2TP и IPSec
- Требуется обеспечить синхронное завершение L2TP-туннеля и SA, созданной в фазах I или II.
Механизмы РРР и L2TP дают возможность завершения соединения как с уведомлением об этом противоположной стороны, так и без уведомления. В протоколе РРР LCP TermReq и TermAck обеспечивают завершение с уведомлением. Сообщения LCP keep-alive и hello L2TP-туннеля дают возможность определить, что произошло завершение без уведомления. Когда происходит завершение, приводящее к закрытию туннеля, используются механизмы управляющего соединения протокола L2TP. При удалении L2TP-туннеля любой из сторон SA, созданные в фазах I или II, которые используются L2TP-туннелем, также должны быть удалены.
- Проблемы, связанные с фрагментацией.
Так как MTU по умолчанию для РРР-соединений равно 1500 байтам, возможна фрагментация при добавлении L2TP- и IPSec-заголовков в РРР-кадр. Одним из механизмов, который может использоваться для решения этой проблемы, может быть использование в РРР значения MTU для входящего / исходящего трафика, равного L2TP/IPSec туннелю минус накладные расходы, связанные с внешними заголовками. Это должно быть сдела-но после того, как L2TP-туннель был установлен, но перед тем, как нача-лись LCP-переговоры. Если значение MTU для входящего / исходящего трафика для туннеля меньше, чем значение MTU для РРР, то указывается новое значение. Это значение может также использоваться в качестве начального значения, предлагаемого для MTU в LCP ConfigReq.
Если ICMP MTU получено в IPSec, то это значение должно храниться в SA. IPSec должен также уведомить об этом L2TP, чтобы новое значение MTU было указано в РРР-интерфейсе. Любое новое значение MTU, задава-емое для РРР-интерфейса, должно проверяться на соответствие этим ограничениям.
Детали IPSec-фильтрования для L2TP-защиты
Так как IKE/IPSec не знает о деталях приложения, которое он защищает, обычно не требуется никакой интеграции между приложением и IPSec-протоколом. Однако в протоколах, в которых возможно изменение номера порта при переговорах, выполняемых этим протоколом (как в случае L2TP), могут возникнуть проблемы при выполнении IKE. В спецификации протокола L2TP говорится, что производитель может динамически назначать UDP-порт источника. Новое значение порта посылается в SCCRP от Получателя к Инициатору.
Хотя текущая спецификация L2TP позволяет Получателю указывать новый IP-адрес в SCCRP, если требуется защита L2TP с использованием IPSec, обычно этого не делают. Для обеспечения возможности указывать новый IP-адрес при совместном использовании L2TP и IPSec, необходимо, чтобы при выборе Получателем нового IP-адреса, он посылал STOPCCN Инициатору с AVP Result Code, Error Code. Result Code должен быть установлен в 2 (General error), и Error Code должен быть установлен в 7 (Try Another).
Если Error Code установлен в 7, то должно посылаться дополнительное сообщение об ошибке, в котором содержится IP-адрес, который Получатель будет использовать в последующих обменах. Инициатор после обработки этих сообщений должен послать новый SCCRQ на новый IP-адрес. Данный подход уменьшает сложность, так как Инициатор всегда знает корректный IP-адрес противоположной стороны. Это также позволяет управляющему механизму L2TP привязать записи в базе данных поли-тик IPSec к одной и той же противоположной стороне.
Далее обсудим детали записей в базе данных политик, требуемые для реализации данного поведения, а также другие механизмы, необходимые для защиты L2TP с использованием IPSec.
- I фаза IKE-переговоров.
В IKE при использовании аутентификации по предварительно распределенному секрету этот секрет должен быть указан на каждой стороне. При использовании Main Mode (который обеспечивает защиту идентификации) этот секрет должен быть связан с IP-адресом противоположной стороны. При использовании Aggresive Mode (который не обеспечивает защиту идентификации) предварительно распределенный секрет должен быть связан с одним из допустимых типов идентификаций, определенных в IPSec DOI.
Если инициатор получает STOPCCN с AVP результата и кодом ошибки, установленным в Try Another, и в сообщении присутствует действительный IP-адрес, он может связать исходный предварительно распределенный секрет с новым IP-адресом, содержащимся в сообщении об ошибке.
Использование заранее распределенных ключей в качестве аутентификаторов плохо влияет на масштабируемость. Так как число конечных точек LAC и LNS возрастает, то и трудность управления заранее распределенными ключами также возрастает. Поэтому аутентификация с использованием сертификатов является более предпочтительной.
- Переговоры II фазы IKE.
В течение II фазы участники согласовывают, как будет защищен трафик IPSec-протоколов. Идентификации в Quick Mode являются комбинацией адресного пространства, протокола и номера порта.
При обеспечении безопасности L2TP с использованием IPSec возможны следующие изменения портов и адресов Инициатора и Получателя:
Таблица 10.1. Порт Инициатора Адрес Получателя Порт Получателя 1701 Фиксированный 1701 1701 Фиксированный Динамический 1701 Динамический 1701 1701 Динамический Динамический Динамический Фиксированный 1701 Динамический Фиксированный Динамический Динамический Динамический 1701 Динамический Динамический Динамический Наиболее общим случаем является последний в списке. В этом случае Инициатор выбирает новый номер порта, и Получатель выбирает новый адрес и новый номер порта. Поток L2TP-сообщений, который возникает в этом случае, следующий:
→IKE фаза I и фаза II для защиты Initial SCCRQ SCCRQ → (Фиксированный IP-адрес, Динамический порт Инициатора) ← STOPCCN (Получатель выбирает новый IP-адрес) → Новые переговоры IKE фаза I и фаза II для защиты нового SCCRQ SCCRQ → (SCCRQ на новый IP-адрес Получателя) ← Новые переговоры IKE фаза II для изменения номера порта Получателя ← SCCRP (Получатель выбирает новый номер порта) SCCCN → (Завершение установления L2TP-туннеля)
Хотя обычно Инициатор и Получатель динамически не изменяют пор-ты, безопасность L2TP должна также обеспечиваться при использовании таких приложений, как балансировка нагрузки и гарантирование качества (QoS). Это может потребовать изменения порта и IP-адреса при установлении L2TP-туннеля.
Для поддержки наиболее общего случая в L2TP и IPSec должны быть разработаны механизмы, которые позволяют L2TP вставлять свои записи в БД IPSec. Данная технология может быть использована любым приложением, которое изменяет порты и которому требуется безопасность с использованием IPSec.
Не требуется, чтобы Получатель поддерживал возможность изменять свой IP-адрес и порт. Тем не менее Инициатор должен позволять Получателю изменить свой порт и IP-адрес.
Терминология, используемая для задания параметров фильтрования:
Таблица 10.2. I-Port Номер UDP-порта, который Инициатор выбирает для инициализации и получения L2TP-трафика. Это может быть статический порт, такой как 1701, или временный порт, связанный с сокетом. R-Port Номер UDP-порта, который Получатель выбирает для инициализации и получения L2TP-трафика. Это может быть порт 1701 или временный порт, связанный с сокетом. Это номер порта, который Получатель будет использовать после получения начального SCCRQ. R-IPAddr1 IP-адрес, который Получатель слушает при получении начального SCCRQ. Если Получатель не изменил IP-адрес на новый, данный адрес будет использоваться всем последующим L2TP-трафиком. R-IPAddr2 IP-адрес, который Получатель выбрал после получения SCCRQ. Этот адрес используется для того, чтобы послать SCCRQ, и весь последующий трафик L2TP-туннеля будет посылаться с данного адреса и получаться на него. R-IPAddr IP-адрес, который Получатель использует для посылки и получения L2TP-пакетов. Это либо исходное значение R-IPAddr1, либо новое значение R-IPAddr2. I-IPAddr IP-адрес, который Инициатор использует для взаимодействия по L2TP-туннелю. Any-Addr Наличие Any-Addr говорит о том, что IKE должен допускать любой одиночный адрес, предложенный в качестве ID в фазе II переговоров. Данный одиночный адрес может рассматриваться как единственный IP-адрес или IP-адрес с маской, установленной в 255.255.255.255. Any-Port Наличие Any-Port говорит о том, что IKE должен допускать любое значение номера порта. Записи в политике IPSec, которые будут определены далее, перечислены от наибольшего приоритета к наименьшему.
