Кратко

  • RFC 1701 допускал применение четырёхоктетного Key для аутентификации источника, но не определял получение, распределение, защиту или проверку такого утверждения.
  • RFC 2890 назначил полю исполнимую роль: идентифицировать один логический поток в туннеле. Несмотря на имя, Key не участвует в безопасности, а Sequence Number даёт порядок без гарантии доставки.
  • Произвольный внедрённый Sequence способен продвинуть память получателя и превратить последующие легитимные пакеты в «старые». Доверять K/S можно только под отдельной защитой, охватывающей GRE-заголовок и полезную нагрузку.

Название обещало больше, чем формат

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

RFC 1701 в 1994 году описал общую инкапсуляцию одного сетевого протокола в другой. За заголовком доставки шёл GRE-заголовок, а затем вложенный пакет. Дополнительно могли присутствовать контрольная сумма, маршрут, Key и Sequence Number.

Документ говорил, что получатель может использовать Key для аутентификации источника. Все методы установления подлинности оставались вне спецификации. Не было генерации, обмена, привязки к паре конечных точек, срока действия, защиты от копирования и изменения. Поле переносило число, но не переносило основание доверять числу.

С Sequence Number повторилась та же незавершённость. Он мог устанавливать порядок передачи, однако алгоритмы нумерации и приёма не задавались. Два устройства понимали расположение поля, но могли по-разному менять состояние.

Общая спецификация сначала стала меньше

RFC 2784 в марте 2000 года стандартизовал пересечение GRE-реализаций, уже развёрнутых несколькими производителями. Базовый заголовок оставил признак Checksum, Version и Protocol Type. Последний сообщает тип внутренней нагрузки, но не даёт ей права попасть в туннель.

Старые дополнительные биты стали границей совместимости. Передатчик, следующий только RFC 2784, отправлял резервные позиции нулевыми. Получатель без RFC 1701 был обязан отбросить пакет, если один из битов 1–5 ненулевой. Отдельные правила объясняли взаимодействие со старыми реализациями.

Так код мог локально определить свой набор совместимости. Ему не требовалось угадывать смысл по марке оборудования, адресу или уверениям оператора.

RFC 2890 сделал Key контекстом, а не удостоверением

Через полгода RFC 2890 обновил базовый формат. K объявляет четырёхоктетный Key, S — такой же Sequence Number. Позиции совместимы с RFC 1701, но теперь основная семантика задана.

Инкапсулятор вставляет Key; способ получить число остаётся за пределами RFC. Декапсулятор использует его для различения отдельного потока внутри туннеля, когда вложенным данным не хватает контекста для локальной маршрутизации или обработки. Пакеты одного потока несут одно значение.

Это локальное имя в отношениях конкретных конечных точек. В другом туннеле то же число может означать иной поток. Оно не сообщает владельца, разрешение или секрет. Тот, кто умеет создать пакет, может скопировать видимые четыре октета.

Раздел о безопасности ставит точку: несмотря на имя, поле Key не связано ни с какой безопасностью. Совместимость сохранила название, а стандарт лишил его ложной доказательной силы.

Sequence описывает память получателя

При S передатчик использует свободный 32-битный счётчик от нуля с оборотом по модулю 2^32. Получатель хранит номер последнего успешно декапсулированного пакета. Если присутствует K, история относится к выбранному им потоку.

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

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

Общей шкалы времени для туннеля нет. Пакеты без S могут чередоваться с нумерованными; разные Keys имеют разные истории. Разрыв доказывает отсутствие успешной декапсуляции в данном состоянии, но не различает потерю, задержку, фильтрацию, перезапуск и отсутствие отправки.

Поддельное будущее делало настоящее устаревшим

Пусть последним принят номер 40. Внедрённый пакет с копией Key и сильно большим Sequence приходит первым. Если GRE-заголовок не защищён внешней целостностью, получатель может записать ложное будущее. Нормальные последующие пакеты выглядят слишком старыми и отбрасываются.

RFC 2890 прямо описывает произвольное внедрение Sequence как путь к отказу в обслуживании. Требуется отдельная IP-защита GRE-заголовка и туннелированной нагрузки. В область проверки должны входить K и S, потому что именно они выбирают контекст и двигают состояние.

Следовательно, Sequence сам по себе не является anti-replay. Окно повторов полезно лишь после аутентификации пакета как участника защищённой связи. Без неё атакующий способен переписать меру, по которой будут отвергнуты следующие сообщения.

Шифрование тоже не возникает из K/S. Key не скрывает содержимое, Sequence не скрывает рисунок трафика. Целостность, происхождение и конфиденциальность выбираются внешним защитным механизмом.

Новое обязательство не расширило старое поле

RFC 9601 2024 года — другое зарегистрированное обновление RFC 2784. Оно относит GRE между IP-заголовками к правилам переноса ECN и требует безопасной настройки входа, когда внешний протокол доставки — IPv4 или IPv6.

Это независимый слой. ECN переносит свидетельство перегрузки, Key выбирает поток, Sequence поддерживает локальный порядок, а защита проверяет происхождение и целостность. Все обязанности могут работать в одном туннеле, не заменяя друг друга.

RFC 9601 также отмечает, что у GRE нет собственного динамического установления и настройки туннеля. Отношение создаёт статическая конфигурация или другой протокол управления. Захват пакетов видит K/S, но не видит мандат, назначивший число и допустивший соседний узел.

Счётчик — это факт решения, не факт причины

Рост out-of-sequence может быть следствием перестановки, дубликатов, малого буфера, перезапуска, расхождения конфигурации или внедрения. Счётчик показывает сравнение, выполненное получателем. Причина появляется только при сопоставлении внешних адресов, пространства Key, последнего состояния, пакетов и результата проверки целостности.

Историческая ценность RFC 2890 состоит в сужении обещаний. Key сообщает контекст, Sequence — условный порядок. Безопасность начинается у механизма, который действительно способен проверить источник и неизменность данных.

Источники