Кратко

  • RFC 3193 требовал защищать управляющие и информационные пакеты L2TP средствами ESP, но селекторы IPsec приходилось обновлять, если во время установки туннеля L2TP выбирал другой адрес или UDP-порт.
  • IKE мог подтверждать владение ключом машины на каждом пакете, тогда как PPP называл пользователя при открытии сессии; без локального разделения трафика первое доказательство не становилось вторым.

Удобная схема VPN изображает трубу: трафик входит, получает шифрование и выходит на другом конце. RFC 3193 описывал более сложную конструкцию. Защищённый туннель возникал из нескольких автоматов состояний, которые узнавали необходимые факты в разное время.

L2TP переносил PPP и управлял туннелем, сессиями, keep-alive и завершением. Порт 1701 был местом первоначальной встречи, но ответчик мог выбрать другой исходящий порт. Спецификация L2TP позволяла ему предложить и иной IP-адрес. Для приложения это давало выбор конечной точки и распределение нагрузки. Для IPsec это означало, что точный набор защищаемых пакетов заранее не известен.

IPsec определял набор селекторами: адресами, протоколом и портами. Security Association не обещала защищать всё, что приложение позже назовёт туннелем. Она относилась к согласованному классу пакетов. Если L2TP менял сокет, а IPsec продолжал проверять старые селекторы, законный трафик выпадал из защиты либо слишком широкое правило разрешало лишнее.

Поэтому первый фильтр должен был существовать до отправки SCCRQ. Если подходящей Phase 2 SA не было, отправка Start-Control-Connection-Request запускала её создание через IKE; при неудаче пакет следовало отбросить. Это временная граница. Защита не могла начаться со второго управляющего сообщения, оставив само создание отношений открытым.

По мере появления новых фактов L2TP передавал их уровню безопасности. Узнав динамический порт, приложение внедряло сведения в базу фильтров IPsec. После Quick Mode IKE мог установить более узкий фильтр для завершённой SA. Широкое правило первоначальной встречи было временным коридором, а не постоянным полномочием.

Изменение адреса оформлялось особенно строго. Ответчик не должен был просто ответить с нового места. По старому защищённому пути он посылал StopCCN с общей ошибкой, указанием «Try Another» и новым адресом. Инициатор проверял значение, создавал новую политику и новые Phase 1 и Phase 2, лишь затем отправляя новый SCCRQ. Смена адреса означала контролируемый перезапуск криптографического контекста.

Для смены порта применялась иная последовательность. Ответчик выбирал новый исходящий порт перед SCCRP, L2TP добавлял фильтры, и ответчик начинал дополнительную Phase 2. Входное правило инициатора заранее допускало такой выбор. После установления туннеля остаточные SA и фильтры подготовки можно было удалить.

Отсюда следует, почему формула «UDP 1701 поверх IPsec» ничего не доказывала. Защищаемый объект переходил от начальной пары конечных точек к реально согласованному сокету. L2TP владел прикладным состоянием, которое IKE не мог придумать. IKE владел результатом аутентификации, который L2TP не мог считать само собой разумеющимся. RFC связывал наблюдения через уведомления и явное внедрение фильтров.

Жизненные циклы также не превращались в одну транзакцию. PPP мог корректно завершиться через LCP. L2TP мог закрыть control connection или обнаружить молчащий peer по hello. IKE мог получить удаление Phase 1 или Phase 2. После исчезновения туннеля связанные SA следовало удалить и разослать delete. Если IKE узнавал об удалении состояния другой стороной, он уведомлял L2TP. Исчезновение одного объекта ещё не было квитанцией об исчезновении остальных.

При приёме L2TP выполнял две проверки. Сначала он убеждался, что IPsec расшифровал или аутентифицировал пакет. Затем сравнивал адреса и UDP-порты с сокетом, использованным при создании конкретного туннеля. Доверенный peer всё ещё мог направить защищённый пакет не в тот прикладной контекст. Принадлежность SA и принадлежность туннелю были разными фактами.

Даже размер пакета требовал обмена наблюдениями. PPP часто ожидал MRU 1500 байт, но L2TP и IPsec добавляли заголовки. RFC предлагал перед LCP передавать PPP значение MTU интерфейса за вычетом накладных расходов. Если IPsec позже узнавал меньший Path MTU через ICMP, значение сохранялось в SA и сообщалось L2TP. Наблюдение одного слоя не влияло на другой без явного интерфейса.

Сжатие показывало ту же границу. L2TP был логическим соединением, но IP не гарантировал порядок пакетов. Потеря одного элемента могла рассинхронизировать состояние компрессора или шифра для всех следующих. Поэтому документ предпочитал методы без состояния. Название «туннель» не превращало сеть в надёжный упорядоченный поток.

Главное различие касалось идентичности. PPP и IKE отвечали на разные вопросы. PPP мог аутентифицировать пользователя при запуске сессии. IKE мог аутентифицировать машину, владеющую сертификатом или ключом, после чего ESP проверял каждый пакет производными ключами. Это было сильным непрерывным свидетельством владения ключом, но не доказательством идентичности, которую IKE никогда не утверждал.

На многопользовательской машине IPsec с машинным сертификатом обычно не умел разделять локальных пользователей. После открытия туннеля другой пользователь мог отправить через него трафик. Пакет оставался целостным, аутентичным и защищённым от replay в рамках машинной SA, но из этого не следовало, что его создал пользователь, названный PPP.

Пользовательская аутентификация в IKE могла сузить разрыв только вместе с обеспечением на клиенте: в туннель должен попадать трафик именно этого пользователя. Сертификат, IKE identity и криптографически правильный пакет сами по себе не создавали изоляцию. Локальная политика выбора трафика являлась частью заявления о безопасности.

Раздел о сертификатах поэтому говорил не только о криптографии. LNS мог доверять нескольким удостоверяющим центрам с разной проверкой отзыва. Машинный сертификат значил не больше, чем процедура его выдачи. Смарт-карта снижала риск кражи пользовательского ключа, но могла обойти политику, которая хотела связывать доступ с одобренным устройством. Формат credential не назначал полномочия процесса регистрации.

Предварительно разделяемые ключи делали проблему нагляднее. Адреса удалённых клиентов часто были динамическими. В IKE Main Mode ответчику требовался ключ до получения identity payload, поэтому выбрать уникальный ключ по пользователю было трудно. Развёртывание скатывалось к общему групповому секрету. Знание секрета доказывало членство в группе, а не личность клиента; обладатель секрета мог выдать себя за LNS и атаковать старые механизмы PPP. RFC советовал не аутентифицировать LNS групповым pre-shared key.

Aggressive Mode показывал идентичность достаточно рано для выбора ключа, но раскрывал её. Сертификаты масштабировались лучше, однако наследовали качество регистрации и настройки доверия. Универсального credential не было: существовал выбор между приватностью идентичности, выбором ключа, масштабом и контролем выдачи.

Наконец, защита имела географию. При compulsory tunneling клиент отправлял PPP к LAC и мог не знать, что дальше LAC оборачивает его в L2TP/IPsec. LNS видел SA между LAC и LNS, клиент не мог считать защищённым участок до LAC. При voluntary tunneling сам клиент создавал L2TP и мог проверить SA до LNS, но участок после LNS всё равно оставался другим.

Историческое достоинство RFC 3193 — в точности этих отказов. Документ указал, где прикладное состояние входит в политику безопасности, где результат безопасности возвращается приложению и какую идентичность ни одна квитанция не получает автоматически. Туннель работал благодаря обмену ограниченными фактами, а не благодаря праву одного слоя говорить за остальные.