1. 1 История tcpIP
 Скачать 340.83 Kb.
|
3.3.3.2 Протокол IKEv2Протокол IKEv2 был первоначально описан в RFC 4306. Сейчас этот RFC является устаревшим. Актуальным на данный момент является RFC 7296. IKEv1 и IKEv2 обратно не совместимы, так как в IKEv2 изменен порядок обмена. В IKEv1 определен обмен фазы I и обмен фазы II. В фазе I стороны обмениваются 6 или 3 сообщениями в зависимости от используемого режима. В фазе II стороны обмениваются 3 сообщениями. Взаимодействие по протоколу IKEv2 начинается с двух обменов: IKE_SA_INIT и IKE_AUTH. Этот первоначальный обмен обычно состоит из четырех сообщений, хотя в некоторых случаях их количество может увеличиться. Это зависит от сложности выполняемой аутентификации. Первая пара сообщений (IKE_SA_INIT) является начальным обменом, в котором узлы устанавливают IKE SA. С помощью них согласовываются криптографические алгоритмы, отправляются nonce и выполняется обмен Диффи-Хеллмана. Вторая пара сообщений (IKE_AUTH) аутентифицирует предыдущие сообщения, обменивается идентичностями и сертификатами, устанавливает первую и обычно единственную Child SA для протокола AH или ESP. Содержимое этих сообщений зашифровано, и целостность их защищена с помощью ключей, установленных в процессе обмена IKE_SA_INIT. Таким образом, идентичности скрыты от перехватчиков и все поля сообщений аутентифицированы. Все сообщения, следующие за первоначальным обменом, криптографически защищены с помощью криптографических алгоритмов и ключей, согласованных в процессе обмена IKE_SA_INIT. Если дополнительно требуется создать новые Child SA или обновить ключи текущих IKE SA и Child SA, используется обмен CREATE_CHILD_SA. Этот обмен состоит из единственной пары сообщений. Информационный обмен в IKEv2 выполняет те же функции, что и в IKEv1. Он позволяет сторонам доставлять друг другу управляющие сообщения об ошибках или уведомлять об определенных событиях. Информационные обмены должны осуществляться только после выполнения обмена ключом, чтобы они были криптографически защищены. 3.3.4 Использование NAT в протоколе IPSec Для обеспечения целостности данных (одного из сервисов IPSec) запрещается какое-либо их изменение в процессе передачи. Это является основным препятствием, с которым можно столкнуться при совместном использовании NAT и IPSec. Все несовместимости между NAT и IPSec описаны в RFC 3715 «IPsec-Network Address Translation (NAT) Compatibility Requirements». Поскольку NAT изменяет заголовок IP, то это влияет на проверку целостности пакета IP в случае использования протокола АН. При любом режиме (транспортном или туннельном) протокол АН осуществляет аутентификацию отдельных частей заголовка IP. Именно поэтому протокол АН и NAT совместно работать не могут. Следовательно, единственный вариант — использовать протокол ESP в транспортном или в туннельном режиме. В туннельном режиме ESP защищает весь внутренний IP-пакет, включая весь внутренний IP-заголовок и заголовок транспортного уровня. Внешний заголовок IP остается нетронутым и может быть изменен, что и происходит при преобразовании NAT. Таким образом, этот процесс может функционировать до тех пор, пока речь не заходит о пакете TCP. Однако, как только возникает необходимость в передаче пакета TCP с преобразованием портов (NAPT), маршрутизатор NAT начинает работать с портами TCP и заново рассчитывает контрольную сумму заголовка TCP. А поскольку заголовок TCP защищен протоколом ESP, можно ожидать следующих проблем: Если заголовок TCP и данные зашифрованы, то маршрутизатор NAT не сумеет заново рассчитать контрольную сумму TCP, и передача данных окажется невозможна. Если заголовок TCP и данные не зашифрованы, то маршрутизатор NAT заново рассчитает контрольную сумму TCP и нарушит целостность данных с точки зрения протокола ESP. Отсюда следует: NAT и ESP способны совместно функционировать в транспортном режиме только в том случае, если сторонами IPSec отменена проверка контрольной суммы. Но существует еще одна трудность: при использовании IKE с аутентификацией на основе PSK в большинстве реализаций IPSec происходит идентификация IP-адреса партнера по заранее заданному паролю. Изменение этого IP-адреса при использовании NAT может привести к сложностям с аутентификацией. Однако если идентификация партнера IPSec происходит на основе идентификационных данных (ID) пользователя или имени домена, то такая проблема не возникает. Для решения вышеописанных проблем была создана функция NAT Traversal (NAT-T), которая позволяет передавать пакеты IPSec через NAT или NAPT, дополнительно упаковывая их в дейтаграмму UDP. Работа протокола IKEv1 при использовании NAT описана в RFC 3947 «Negotiation of NAT-Traversal in the IKE». Определение поддержки двумя сторонами IKEv1 функции NAT-Traversal и обнаружение устройств NAT на пути между ними выполняется на фазе I в обоих режимах. RFC 3947 требует, чтобы в первых двух сообщениях фазы I стороны обменялись Vendor ID payload. Она является одной из нагрузок сообщений ISAKMP и используется для уведомления о поддержке функции NAT-Traversal. Содержимым Vendor ID payload является хэш-код MD5, вычисленный для строки «RFC 3947». После этого может быть определено наличие NAT между двумя противоположными сторонами IKE и его расположение. Для определения NAT между двумя узлами необходимо определить изменялись ли IP-адреса и порты при пересылке. Для этого стороны отправляют друг другу нагрузки NAT Discovery (NAT-D). Их содержимым являются хэши IP-адресов и портов из пакетов обоих сторон. Нагрузки NAT-D включаются в третий и четвертый пакеты Main Mode и второй и третий пакеты Aggressive Mode. Каждая сторона IKE отправляет две или более нагрузки NAT-D. Каждая нагрузка содержит один хэш. IP-адрес и номер порта назначения исходящего пакета IKE используются для вычисления хэша, который содержится в первой нагрузке NAT-D. IP-адрес и номер порта источника исходящего пакета IKE используются для вычисления хэша, который содержится во второй нагрузке NAT-D. Обычно стороны обмениваются только двумя нагрузками NAT-D. Однако если отправитель пакета имеет множество IP-адресов и не знает, какой адрес использовать для отправки пакета, он может поместить в пакет несколько нагрузок NAT-D для каждого IP-адреса. Если на обоих концах вычислены те же самые хэши, что и в полученных сообщениях, это означает, что между участниками нет NAT. Если хэши не совпадают, где-то была выполнена трансляция адреса или порта. Это означает, что для получения IPSec-пакетов необходимо обеспечить прохождение NAT. Когда между двумя сторонами IKE обнаружено одно или более устройств NAT, в сообщениях 1 и 2 Quick mode не должно предлагаться использование транспортного или туннельного режима инкапсуляции. Для переговоров о прохождении NAT добавлено два новых режима инкапсуляции: UDP-Encapsulated-Transport и UDP-Encapsulated-Tunnel. Когда между двумя сторонами IKE нет NAT, переговоры об использовании этих режимов вестись не должны. Для возможности изменения контрольных сумм ТСР обоим участникам может понадобиться знать исходные IP-адреса, которые использовались участниками при создании пакета. Для этих целей RFC 3947 определил нагрузку NAT Original Address (NAT-OA), которая содержит IP-адреса. Когда инициатор обмена в Quick mode отправляет предложение об использовании транспортного режима UDP-Encapsulated-Transport, в первом сообщении должны содержаться две нагрузки NAT-OA. Первая нагрузка NAT-OA содержит исходный IP-адрес инициатора, вторая — исходный IP-адрес ответчика. Когда ответчик принимает предложение об использовании режима UDP-Encapsulated-Transport, он отправляет две нагрузки NAT-OA во втором сообщении, которые содержат исходные IP-адреса инициатора и ответчика. В туннельном режиме UDP-Encapsulated-Tunnel обе стороны не должны посылать друг другу исходные IP-адреса. RFC 7296 описывает механизм обнаружения NAT и определения его размещения на пути между двумя сторонами IKEv2. Для этого инициатор и ответчик должны включать в свои сообщения IKE_SA_INIT нагрузку Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти нагрузки могут использоваться для определения расположения NAT и стороны, расположенной за NAT. Каждая нагрузка содержит один хэш. SPI, IP-адрес и номер порта источника исходящего пакета IKE_SA_INIT используются для вычисления хэша, который содержится в нагрузке NAT_DETECTION_SOURCE_IP. Этих нагрузок в сообщении может быть много, если отправить не знает, в какую из присоединенных сетей будет отправлен пакет. SPI, IP-адрес и номер порта назначения исходящего пакета IKE_SA_INIT используются для вычисления хэша, который содержится в нагрузке NAT_DETECTION_DESTINATION_IP. Если получатель определил, что полученные и вычисленные хэши NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP не совпадают, он должен активировать функцию NAT-Traversal. В случае, если не совпадают вычисленный и принятый хэш NAT_DETECTION_DESTINATION_IP, это означает, что система, получившая эту нагрузку, находится за NAT. Если ни одна из полученных нагрузок NAT_DETECTION_SOURCE_IP не совпадает с ожидаемыми значениями IP-адреса и порта источника из IP-заголовка, это означает, что система, отправившая эти нагрузки, находится за NAT. Если между двумя сторонами IKEv2 определен NAT и при установлении Child SA ведутся переговоры об использовании транспортного режима, для защиты передаваемого по ней трафика будет использоваться режим UDP-Encapsulated-Transport. Если при установлении Child SA ведутся переговоры об использовании туннельного режима, для защиты передаваемого трафика будет использоваться режим UDP-Encapsulated-Tunnel. При этом стек TCP/IP должен обрабатывать полученные пакеты ESP инкапсулированные в UDP, даже в том случае, если NAT не определен. Для возможности изменения контрольных сумм ТСР при использовании транспортного режима обоим участникам может понадобиться знать их исходные IP-адреса. Исходные IP-адреса содержатся в нагрузках Traffic Selector. Когда NAT был определен и инициатор предлагает использовать транспортный режим, запрос должен включать нагрузки Traffic Selector, которые содержат исходные IP-адреса инициатора и ответчика. Когда ответчик принимает предложение об использовании транспортного режима, его ответ содержит нагрузки Traffic Selector, которые содержат исходные IP-адреса инициатора и ответчика. Способ передачи ESP-пакетов при обнаружении NAT описан в RFC 3948 «UDP Encapsulation of IPsec ESP Packets». Пакет IP, защищенный ESP, дополнительно упаковывается в дейтаграмму UDP, в результате чего он избегает проверки идентичности и целостности заголовка IP и TCP. То есть NAPT трактует ESP-пакет как обычную дейтаграмму UDP и обрабатывает ее обычным образом. Заголовок UDP вставляется перед заголовком ESP во всех режимах. Номера порта источника и порта приемника в заголовке UDP аналогичны номерам, используемым для пакетов IKE. Контрольная сумма всегда установлена в 0, что позволяет избежать проверки контрольной суммы промежуточными устройствами. Использование порта UDP 4500 Преобразования NAT, которые знают о наличии IPSec, могут вызвать проблемы. Наилучшим способом избежать проблем является использование номера порта UDP, отличного от 500. Напомним, что UDP-порт 500 зарезервирован для IKE. RFC 3947 и RFC 7296 требуют, чтобы инициатор, расположенный за NAT, изменял номер порта UDP на 4500 сразу, как только определит существование NAT. Порт 4500 зарезервирован для трафика ESP и IKE, инкапсулированного в UDP. В Main mode IKEv1 инициатор определяет существование NAT, когда обрабатывает сообщение 4 и переключается на использование UDP-портов источника и назначения с номером 4500. В Aggressive mode IKEv1 инициатор определяет существование NAT, когда обрабатывает сообщение 2 и переключается на использование UDP-портов источника и назначения с номером 4500 при отправке сообщения 3. В IKEv2 инициатор определяет существование NAT, когда обрабатывает ответ IKE_SA_INIT. Когда ответчик отправляет инициатору сообщение, он должен использовать значения портов из последнего сообщения, полученного от инициатора. После того как стороны определили наличие NAT, они должны отправлять все последующие сообщения с номером UDP-порта 4500. При этом RFC 7296 позволяет инициатору использовать UDP-порт 4500 для трафика IKEv2 независимо от того, существует NAT или нет даже при отправке первого сообщения IKE_SA_INIT. Инициатор всегда ожидает, что сообщения будет передаваться с порта 4500 и приниматься на порт 4500. Для ответчика, если он расположен за NAPT, номер порта источника в сообщении может измениться на значение отличное от 4500. В этом случае ответчик получает сообщение с произвольным портом источника Х и портом назначения 4500. После получения этого сообщения, все последующие сообщения ответчик отправляет с использованием порта источника 4500 и порта назначения Х. Для отправки UDP-инкапсулированного трафика ESP используются те же номера портов, что и в пакетах IKE. Для того чтобы можно было отличать UDP-инкапсулированный трафик ESP от трафика IKE, в каждое сообщение IKE добавляется маркер non-ESP. Это маркер длиной 4 байта со значением 0. |