Кратко

  • 64-битное поле Replay Prevention в RFC 2085 было необязательным для каждой SA: SPI выбирал состояние, где поле присутствовало либо отсутствовало.
  • Счётчик начинался с 1, не мог оборачиваться под одним ключом, а каждый получатель выбирал ограниченное окно, принимая каждое значение не более одного раза.
  • Верный HMAC и невиденный номер подтверждали локальную допустимость в общей SA, но не multicast-отправителя, глобальную хронологию, доставку, полномочие или результат приложения.

IP-пакет с верной аутентификацией мог быть точной копией старого пакета. MAC оставался правильным, потому что байты не менялись. RFC 2085 предложил узкий ответ: включить счётчик в аутентификацию и заставить получателя помнить ранее допущенные значения.

SPI выбирал наличие счётчика

Необязательное поле располагалось между SPI и Authentication Data. Без защиты от повтора данные аутентификации следовали сразу за SPI. По RFC 1826 получатель использовал индекс, чтобы найти однонаправленную SA, алгоритм, ключ, режим и состояние. Это был выбор правил обработки, не человеческая идентичность.

Счётчик рос с 1; общий ключ следовало заменить до оборота 2^64. Если поле присутствовало, оно входило в HMAC. Сторона без ключа не могла заменить старый номер новым, сохранив MAC. Но проверки оставались разными: HMAC связывал пакет и номер с секретом, а история получателя решала, допустимо ли аутентифицированное значение.

Рост не означал доставку по порядку

RFC разрешал пакеты вне порядка и оставлял глубину окна реализации. Неизменное требование: принятое значение не должно было приниматься раньше.

Номер ниже максимального мог быть законно запоздавшим, если оставался в окне и его отметка seen была свободна. Слева он был слишком стар, отмеченный номер был дублем, новый справа мог сдвинуть границу после аутентификации. RFC 6479 позже описал диапазон и биты получения, объяснив, почему параллельная криптография может требовать большего окна.

Окно было политикой получателя, не мировыми часами. Два получателя могли видеть разный порядок и выбрать разную глубину. Пропуск не доказывал потерю, задержка — атаку, приём у A — приём у B. Точная квитанция говорила лишь: в этой SA и этом состоянии такой аутентифицированный номер прежде не допускался.

Общая multicast-SA теряла происхождение

RFC 2085 прямо назвал предел: если несколько отправителей делят одну SA к multicast-адресу, replay protection не следует включать. Если она нужна, каждому отправителю следует дать отдельную SA.

HMAC продолжал работать; любой обладатель секрета мог его вычислить. Исчезал владелец счётчика. Независимые отправители, начав с 1, сразу сталкивались. Каждый локальный счётчик мог расти правильно, а общий поток повторял значения. Спецификация не задавала общего распределителя номеров.

Раздельные SA возвращали происхождение: SPI направлял пакет в правильную историю. Отключение проверки честно признавало сохранение групповой аутентификации без определения первого использования.

RFC 4302 сохранил границу, хотя сделал Sequence Number обязательным и добавил логический 64-битный ESN. Это объясняет дальнейшее развитие, но не меняет формат RFC 2085 с непосредственно передаваемым необязательным 64-битным полем.

Общий MAC подтверждал ключ, а не уникального говорящего

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

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

Аудит должен разделять поиск SA, наличие поля, номер, позицию окна, seen-состояние, HMAC, допуск, получение верхним уровнем, полномочие и подтверждённый эффект. Счётчик называл не отправителя, а место в истории допуска одного получателя.

Источники