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

Ниже перечислены специфические требования для прохождения через NAT [RFC3715]. Поддержка работы через NAT является необязательной. Приведенные в этом параграфе требования типа «должно» относятся только к реализациям, поддерживающим работу через NAT.

  • IKE должен прослушивать порты 4500 и 500. IKE должен отвечать по адресам IP и портам, с которых были приняты пакеты.
  • Как инициатор, так и ответчик IKE должны включать в свои пакеты IKE_SA_INIT элементы данных Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти элементы могут использоваться для детектирования наличия NAT между хостами и определения, какой из хостов находится за NAT. Эти элементы располагаются в пакетах IKE_SA_INIT после элементов Ni и Nr (перед необязательным элементом CERTREQ).
  • Если ни один из полученных элементов NAT_DETECTION_SOURCE_IP не соответствует хэшу IP-адреса и порта отправителя в заголовке IP содержащего элемент пакета, это означает, что другая сторона расположена за NAT (где-то на пути доставки адрес отправителя исходного пакета заменен на адрес устройства NAT). В таких случаях данной стороне следует разрешить динамическое обновление IP-адреса другой стороны, как описано ниже.
  • Если полученный элемент данных NAT_DETECTION_DESTINATION_IP не соответствует хэшу IP-адреса и номера порта получателя из заголовка IP пакета, содержащего элемент данных, это означает, что другая сторона расположена за NAT. В этом случае локальной стороне следует начать передачу пакетов keepalive, как описано в [Hutt05].
  • Инициатор IKE должен проверить наличие этих элементов данных и при несоответствии адресам во внешнем пакете должен туннелировать все будущие пакеты IKE и ESP, связанные с данной IKE_SA через порт UDP 4500.
  • При туннелировании пакетов IKE через порт UDP 4500 заголовок IKE имеет четыре октета нулей, следующих сразу после заголовка UDP. При туннелировании пакетов ESP через порт UDP 4500 заголовок ESP следует сразу после заголовка UDP. Поскольку первые четыре байта заголовка ESP содержат значение SPI, которое не может быть нулевым, это позволяет всегда легко различать сообщения ESP и IKE.
  • Исходные IP-адреса отправителя и получателя, которые нужны в транспортном режиме для расчета контрольной суммы пакетов TCP и UDP (см. [Hutt05]), извлекаются из селекторов трафика, связанных с этим обменом. При работе через NAT селекторы трафика должны содержать в точности один адрес IP, который используется в качестве исходного адреса IP.
  • В некоторых случаях устройство NAT может удалить отображения, которые продолжают использоваться (например, интервал keepalive слишком велик или устройство NAT перезагружено). Для восстановления в таких случаях хостам, которые не расположены за NAT, следует передавать все пакеты (включая повторные) в адрес IP и порт из последнего корректно идентифицированного пакета от другой стороны (т. е., динамически обновлять адрес). Расположенному за NAT хосту не следует делать так, поскольку это будет открывать возможность организации DoS-атак. Любой идентифицированный пакет IKE или любой идентифицированный пакет ESP, инкапсулированный в UDP, можно использовать для детектирования смены IP-адреса и номера порта. Отметим, что похожие, но, возможно, не совсем идентичные, действия требуется выполнять при работе IKE через Mobile IP, но этот вопрос выходит за пределы данного документа.

2.24. Явные уведомления о перегрузке (ECN)

При развертывании туннелей IPsec в соответствии с исходной спецификацией [RFC2401], использование ECN во внешних заголовках IP было, по сути, невозможно, поскольку при екапсуляции туннеля индикаторы перегрузки ECN отбрасывались. Поддержка ECN для туннелей IPsec на базе IKEv1 требует множества режимов работы и согласований (см. [RFC3168]). IKEv2 упрощает ситуацию, вводя требование возможности использования ECN во внешних заголвках IP для всех IPsec SA в туннельном режиме, создаваемых IKEv2. В частности, точки инкапсуляции и декапсуляции туннельных SA, создаваемых IKEv2, должны поддерживать опцию полной функциональности ECN для туннелей, заданную в [RFC3168], а также должны реализовать инкапсуляцию и декапсуляцию в соответствии с [RFC4301] для предотвращения отбрасывания индикации перегрузки ECN.

2007 - 2018 © Русские переводы RFC, IETF, ISOC.