2.5. Номера версий и совместимость
В этом документе описывается версия 2.0 протокола IKE — старшая часть версии имеет номер 2, а младшая — 0. Очевидно, что некоторые реализации захотят поддерживать версии 1.0 и 2.0, а в будущем и другие версии.
Старшую часть номера версии следует менять только в тех случаях, когда формат пакетов или требуемые действия меняются столь существенно, что узлы старой версии не смогут взаимодействовать напрямую с узлами более новой версии, если они будут просто игнорировать поля непонятные новой версии и выполнять действия, заданные в старой спецификации. Младшая часть номера версии показывает новые возможности и должна игнорироваться узлом с меньшим значением младшей части номера версии, но использоваться для информации с большим значением младшего номера версии. Например, младшая часть может показывать возможность обработки новых уведомляющих сообщений. Узел с большим значением младшей части номера будет просто отмечать неспособность своего корреспондента понимать такие сообщения и, следовательно, передавать их.
Если конечная точка получает сообщение с большим (чем у нее) значением старшей части номера версии, она должна отбросить такое сообщение; следует также передать в ответ неидентифицированное уведомление, содержащее поддерживаемое значение старшей части номера версии. Если конечная точка поддерживает версию со старшей частью n и m, она должна также поддерживать все версии между n и m. Если такая точка получает сообщение поддерживаемой версии, она должна отвечать сообщением той же версии. Для предотвращения ситуаций, когда пара узлов использует старшуу часть номера версии меньше максимально поддерживаемого обоими узлами номера, в IKE используется флаг, показывающий, что узел способен поддерживать больший номер версии.
Таким образом, старшая часть номера версии в заголовке IKE показывает номер версии для данного сообщения, а не номер версии, поддерживаемой отправителем. Если инициатор способен поддерживать версии n, n+1 и n+2, а отвечающая сторона поддерживает версии n и n+1, они согласуют использование версии n+1, а инициатор будет устанавливать флаг способности поддерживать более высокую версию. Если узлы по ошибке (или в результате активной атаки) согласуют использование версии n, тогда оба узла будут указывать поддержку более высокой версии. В этом случае они должны разорвать соединение и организовать его заново с использованием версии n+1.
Отметим, что IKEv1 не следует этим правилам, поскольку в этой версии протокола просто не может быть указана поддержка более высокой версии. Поэтому в активной атаке может просто использоваться попытка вынудить пару узлов v2 работать на основе v1. Когда узел, поддерживающий v2, согласует работу на основе v1, ему следует отмечать этот факт в системном журнале.
Для обеспечения совместимости с более новыми версиями во всех резервных полях реализации версии 2.0 должны устанавливать значение 0, а при получении сообщений такие реализации должны игнорировать содержимое резервных полей (будьте консервативными при передаче и либеральными при приеме). В результате новые версии протокола смогут использовать резервные поля так, что их значения будут игнорироваться реализациями, не понимающими таких полей. Аналогично, типы данных, которые не определены, являются резервными; реализации версии 2.0 должны пропускать такие элементы данных, игнорируя их содержимое.
IKEv2 добавляет флаг «критичности» (critical) к каждому заголовку данных для более гибкой совместимости с грядущими версиями. Если флаг critical установлен, а тип данных нераспознан, сообщение должно быть отвергнуто, а отклик на запрос IKE, включающий эти данные, должен включать элемент Notify UNSUPPORTED_CRITICAL_PAYLOAD, показывающий прием нераспознанных критичных данных. Если флаг критичности не установлен, нераспознанный элемент должен игнорироваться.
Хотя в будущем могут добавляться новые элементы данных, которые будут появляться вперемешку с определенными в этой спецификации полями, реализации должны передавать определенные в этой спецификации элементы в том порядке, который показан на рисунках раздела 2 и реализациям следует отвергать некорректные сообщения с другим порядком элементов данных.