Кратко

  • RFC 1472 разместил протоколы аутентификации и пары ID/Secret в таблицах с областью ссылки, приоритетом, направлением, протоколом и состоянием.
  • valid делал запись доступной для выбора; подтверждение требовало отдельного обмена PAP или CHAP и решения аутентификатора.

RFC 1472 вышел в июне 1993 года и сделал секреты PPP управляемыми объектами. Но таблица не присвоила себе доказательство события, к которому лишь готовила систему.

Соседний RFC 1471 определял объекты LCP. RFC 1472 вынес настройки аутентификации в отдельную необязательную группу: чтение открывало идентификаторы и секреты, а запись позволяла менять выбор защитного протокола.

Приоритет задавал порядок попыток

pppSecurityConfigTable связывала протокол со ссылкой и приоритетом. Меньшее число пробовали раньше. Нулевая ссылка служила правилом по умолчанию для ссылок без собственной строки.

Приоритет не оценивал надёжность и не предсказывал успех. Поле протокола называло планируемую попытку, а не уже согласованный механизм. Нулевое правило не доказывало, что действует для конкретной ссылки: его могла перекрыть специальная запись.

Состояние принимало значения valid и invalid. Инвалидация не обязывала удалить строку. Это зависело от реализации, поэтому станция управления должна была уметь видеть запись, которая сохранилась в таблице, но больше не использовалась, и проверять её статус.

Присутствие и актуальность были разными фактами.

Пара ID/Secret не была доказанной личностью

Для одной ссылки можно было хранить несколько пар. Индекс различал их, однако конкретную пару выбирала локальная реализация.

Направление меняло роль. local-to-remote описывало пару, с которой локальная сторона подтверждает себя удалённой. remote-to-local — пару, ожидаемую от удалённой стороны. Одинаковые байты могли относиться к разным действующим лицам.

Значение полей зависело и от протокола. Для PAP идентификатор мог быть Peer-ID, а секрет — паролем. Для CHAP-MD5 идентификатор мог быть CHAP Name, а секрет участвовал в вычислении ответа. Поэтому RFC 1472 определял их как строки октетов, а не как самодостаточную универсальную личность.

Настроенное имя не подтверждало человека. Хранимый секрет не доказывал владение в нужный момент. Действующая запись не говорила, какую пару выбрали, что прислал удалённый узел и каким был вердикт.

Событие находилось за пределами MIB

RFC 1334 описывал PAP: после установления ссылки узел передавал Peer-ID и пароль, получая Authenticate-Ack или Nak. Более поздний RFC 1994 описал CHAP как вызов, вычисленный ответ, локальное сравнение и успех либо отказ.

Эти сообщения создавали недостающую квитанцию события. Для аудита нужно связать ссылку, согласованный протокол, идентификатор запроса или вызова, ответ, версию учётных данных и решение.

RFC 1661 отделял и следующие этапы: сначала установить канал данных, затем при необходимости аутентифицировать узел, после чего настроить сетевые протоколы через NCP. Успешная проверка не доказывала открытие IPCP; IPCP не доказывал маршрут, доставку или результат приложения.

Канал управления сам требовал защиты

RFC 1472 настоятельно не рекомендовал реализовывать группу без privacy в SNMPv2. MIB views могли изолировать чувствительное поддерево. Режим только чтения ограничивал изменение, но сохранял риск чтения секрета.

Защищённая административная операция доказывала лишь действие на пути управления. Она не заменяла PPP-аутентификацию. Централизация упрощала работу, одновременно концентрируя последствия слишком широкого умолчания, смены приоритета, открытой view или неверного толкования старой строки.

Две временные шкалы

В журнале настройки нужны автор, время, область ссылки, наследование умолчания, приоритет, протокол, индекс, направление, переход статуса и чтение из агента. В журнале события — LCP, согласованный механизм, запрос или вызов, ответ, вердикт, версия секрета, NCP и трафик.

Действующая строка, которую не выбрали, остаётся инвентарём. Выбранная недействующая строка означает расхождение исполнения. Успех без версии секрета оставляет пробел атрибуции. Проверенная ссылка, остановившаяся в IPCP, имеет более позднюю неисправность.

Историческая точность RFC 1472 заключалась в границе: таблица показывала готовность системы, но не называла готовность свершившимся событием.

Источники