Кратко

  • RFC 3336 использовал мультиплексирование AAL2, чтобы эффективнее передавать небольшие PPP-пакеты, например голос после сжатия RTP-заголовков.
  • Граница доверия была уже общего ATM-соединения: аутентификация PPP-сеанса не защищала соседние CID без PPP и сеть коммутации ATM.

Идентификатор канала не был удостоверением

Проблема возникала из-за масштаба пакетов. PPP поверх AAL5 хорошо подходил для IP, но RFC 3336 отмечал, что заполнение и оформление кадров расходовали полосу при малой полезной нагрузке — особенно для голоса с уже сжатыми RTP-заголовками. AAL2 предлагал другую схему: его общий уровень CPS мог мультиплексировать несколько PPP-полезных нагрузок в ATM-ячейки, не заставляя каждый короткий пакет нести стоимость полного кадра.

Однако это не превращало виртуальное ATM-соединение в одну PPP-линию. RFC 3336 описывал службу PPP/AAL2 как двунаправленное соединение точка-точка, выделенное заранее или устанавливаемое по запросу. Внутри него идентификатор канала AAL2 (CID) обозначал отдельный поток. PPP-сеанс мог занимать один или несколько CID; обе стороны должны были согласовать их число, соответствие служебным подуровням и конкретные значения. Для постоянного соединения эти параметры задавались конфигурацией, а для коммутируемого могли передаваться сигнализацией.

То же виртуальное соединение могло нести обычный трафик AAL2 и несколько разных функций конвергенции. Поэтому CID разделял потоки, но не являлся криптографическим удостоверением личности. RFC 3336 четко ограничивал область действия PPP-аутентификации: успешную аутентификацию PPP-сеанса и связанные механизмы нельзя было считать защитой соседних CID без PPP. Она также не защищала сеть коммутации ATM. Если транспортная инфраструктура была скомпрометирована, предупреждал документ, оставалась возможность атаки посредника.

Существовали и другие сигналы, но они не стирали эту границу. Состояние линии Up/Down можно было определять по пакетам управления отказами типа 3 в соответствующем потоке CID. В инкапсуляцию также входила 16-битная CRC для обнаружения ошибок. Ни статус канала, ни CRC не доказывали, кто контролирует соседний CID, и не скрывали его содержимое от противника. Для защиты за пределами PPP-сеанса RFC 3336 указывал на аутентификацию или шифрование более высокого уровня и/или службы безопасности ATM.

Одновременно опубликованная RFC 3337 показывает, почему несколько CID заинтересовали разработчиков систем реального времени: один PPP-сеанс мог охватывать разные CID, позволяя чередовать фрагменты разных классов. Но способ планирования CPS оставался зависимым от требований приложения. Одной метки класса было недостаточно, чтобы гарантировать задержку. Формат позволял различать обработку; он не доказывал, что конкретный планировщик или сеть ее обеспечивали.

Вывод ограничен документальными свидетельствами. RFC Editor указывает для RFC 3336 статус Proposed Standard, а текст описывает механизм. Это не показывает, какие поставщики реализовали его, насколько широко он применялся и происходили ли связанные с ним инциденты. Note 65 Лу Хэна задает подходящую редакционную дисциплину: стандарт — это предложение для работающих систем, а не доказательство его принятия.

Архитектурный урок состоит в том, что общая транспортная связь может снизить стоимость передачи пакета и одновременно содержать несколько самостоятельных областей контроля и доверия. Если в записи сказано «PPP аутентифицирован», следует уточнить, что именно: обе стороны PPP и трафик этого сеанса или каждый CID, служебная функция и коммутатор на виртуальном соединении? RFC 3336 показывает, что первое не означает второе.

Источники

Страница статуса RFC Editor

Источники: RFC 3336 · RFC 3337 · PPP поверх AAL5, RFC 2364 · Мультиплексирование PPP, RFC 3153 · PPP, RFC 1661 · Сжатие RTP-заголовков, RFC 2508 · Низкоскоростные каналы, RFC 2689 · ITU-T I.363.2 · ITU-T I.366.1 · Lu Heng, Note 65