RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

4. Требования по совместимости

Для обеспечения интероперабельности всех реализаций IKEv2 вводятся специальные требования «необходимо поддерживать» (MUST support) в дополнение к другим требованиям. IKEv2 является протоколом защиты и одной из его основных функций является предоставление возможности организации SA только уполномоченным сторонам. Поэтому конкретная реализаця может быть настроена с любыми ограничениями по части алгоритмов и удостоверяющих центров, что вступает в противоречие с всеобщей интероперабельностью.

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

  • возможность согласования SA через NAT и туннель, приводящая к организации ESP SA с использованием UDP;
  • возможность запрашивать (и отдавать по запросу) временный адрес IP на удаленной стороне туннеля;
  • возможность поддерживать различные типы унаследованной идентификации;
  • возможность поддерживать окна размером более 1;
  • возможность организации множества SA (ESP и/или AH) в одной IKE_SA;
  • возможность замены ключей SA.

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

Каждая реализация должна быть способна выполнять обмен 4 сообщениями IKE_SA_INIT и IKE_AUTH, обеспечивающий организацию двух SA (одна для IKE, одна для ESP и/или AH). Реализации могут работать в режиме «только инициатор» или «только ответчик», если это подходит для используемой платформы. Каждая реализация должна быть способна отвечать на обмен INFORMATIONAL, но минимальные реализации могут отвечать на любое сообщение INFORMATIONAL пустым откликом INFORMATIONAL (отметим, что в контексте IKE_SA «пустое» сообщение состоит из заголовка IKE, за которым следует элемент Encrypted без вложенных в него элементов). Минимальная реализация может поддерживать обмен CREATE_CHILD_SA лишь для случаев, когда запрос распознан и отвергнут с уведомлением типа NO_ADDITIONAL_SAS. От минимальных реализаций не требуется возможность инициирования обменов CREATE_CHILD_SA или INFORMATIONAL. Когда срок жизни SA истекает (по локальному значению времени жизни или числу переданных октетов), реализация может попытаться обновить связь с помощью обмена CREATE_CHILD_SA или может удалить (закрыть) SA и создать новую. Если ответчик отвергает запрос CREATE_CHILD_SA с передачей уведомления NO_ADDITIONAL_SAS, реализация должна быть способна взамен закрыть старую SA и создать новую.

Реализации не обязаны поддерживать возможность запроса временных адресов IP и отклики на такие запросы. Если реализация поддерживает создание таких запросов, она должна включать в сообщение 3 элемент данных CP, содержащий по крайней мере поле типа INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Все остальные поля являются необязательными. Если реализация поддерживает отклики на такие запросы, она должна разбирать элемент CP типа CFG_REQUEST в сообщении 3 и распознавать поля типа INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Если реализация поддерживает выдачу временных адресов запрошенного типа, она должна возвратить элемент CP типа CFG_REPLY, содержащий адрес запрошенного типа. Ответчику следует включать все остальные связанные с адресом атрибуты, если они имеются.

Минимальная реализация ответчика IPv4 будет игнорировать все содержимое элемента CP, кроме атрибута INTERNAL_IP4_ADDRESS, и будет отвечать на сообщение с включением адреса и других атрибутов, независимо от того, что запрашивал инициатор.

Минимальная реализация инициатора IPv4 будет генерировать элементы CP, содержащие только атрибут INTERNAL_IP4_ADDRESS и разбирать полученный отклик, игнорируя атрибуты, которые она не может использовать. Единственным атрибутом, который должна обрабатывать такая реализация, является атрибут INTERNAL_ADDRESS_EXPIRY, ограничивающий время жизни SA, если она не будет обновлена до завершения срока жизни. От минимальной реализации инициатора не требуется поддержка запросов на обновление аренды адреса, а минимальные реализации ответчиков не поддерживают откликов на такие запросы.

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

  • сертификатов PKIX, содержащих ключи RSA размером 1024 или 2048 и подписанных с использованием таких ключей, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR или ID_DER_ASN1_DN;
  • идентификации с разделяемым ключом, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN или ID_RFC822_ADDR;
  • идентификации в случаях идентифицирования ответчика с использованием сертификатов PKIX, а инициатора с использованием разделяемого ключа.
2007 - 2017 © Русские переводы RFC, IETF, ISOC.