Вначале опишем изменения в фазе I IKE, необходимые для прохождения NAT. Это включает определение, поддерживает ли противоположная сторона прохождение NAT и определение, сколько преобразований NAT существует между участниками.
Далее опишем, какие следует вести переговоры в Quick Mode IKE об использовании UDP для инкапсуляции IPSec-пакетов. Также опишем, как при необходимости передавать исходные адреса отправителя и получателя противоположной стороне. Эти адреса используются в транспортном режиме для изменения TCP/IP контрольных сумм, чтобы они были правильными после преобразования NAT. (NAT не может сделать это, потому что контрольная сумма TCP/IP находится внутри UDP, инкапсулирующего IPSec-пакет.)
Базовым сценарием в данном документе является предположение, что Инициатор расположен за NA(P)T, а Получатель имеет фиксированный IP-адрес.
Фаза I
В фазе I выполняется определение поддержки прохождения NAT обоими участниками и определение того, что между участниками имело место преобразование NAT.
NAT может изменить UDP-порт источника в IKE-пакетах, поэтому Получатель должен уметь обрабатывать IKE-пакеты, чей порт источника отличается от 500. NAT не должен менять порт источника, если только один IPSec-хост расположен за NAT. Для первого IPSec-хоста NAT может оставить порт 500 и изменять номера портов только для последующих коммуникаций.
Получатель должен возвращать пакеты на адрес источника, указанный в пакете. Это означает, что Получатель, выполняющий повторные переговоры о ключах или посылающий оповещение Инициатору, должен посылать пакеты, используя тот же самый набор портов и IP-адресов, который использовался в последней IKE SA.
Например, когда Инициатор посылает пакет с портами источника и получателя 500, NAT может изменить их на порт источника 12312 и порт получателя 500. Получатель должен иметь возможность обработать пакет с портом источника 12312. Он должен ответить, указав в пакете порт источника 500 и порт получателя 12312. Затем NAT будет преобразовывать в данном пакете порт источника на 500 и порт получателя на 500.
Определение поддержки прохода NAT
Возможность прохождения NAT удаленным хостом определяется посредством обмена содержимыми ID производителя (VID). В первых двух сообщениях фазы I должно посылаться содержимое ID производителя для определения возможности прохождения NAT. Содержимым является хэш-код MD5, вычисленный для строки "RFC 3947".
Определение наличия NAT
В фазе I посылается содержимое NAT-D, которое не только определяет наличие NAT между двумя противоположными сторонами IKE, но и определяет, где находится NAT. Расположение NAT важно, так как поддержка инициируется участником, расположенным за NAT.
Для определения NAT между двумя хостами необходимо определить изменялись ли IP-адреса и порты при пересылке. Это делается посылкой в содержимом NAT-D хэшей IP-адресов и портов обоих участников друг другу. Если на обоих концах вычислены те же самые хэши, что и полученные в сообщениях NAT-D, то это означает, что между участниками нет NAT. Если хэши не совпадают, где-то была выполнена трансляция адреса или порта. Это означает, что для получения IPSec-пакетов необходимо выполнить прохождение NAT.
Если отправитель пакета не знает свой собственный IP-адрес (в случае нескольких интерфейсов может быть неизвестно, какой IP-адрес будет использоваться для маршрутизации пакета), отправитель может поместить в пакет несколько хэшей локальных IP-адресов в виде отдельных NAT-D со-держимых. В этом случае NAT присутствует тогда и только тогда, когда ни для одного из хэшей не найдено соответствие.
Содержимые NAT-D включаются в третий и четвертый пакеты Main Mode и второй и третий пакеты Aggressive Mode.
Хэш вычисляется для следующих значений:
HASH = HASH (CKY-I | CKY-R | IP | Port)
Первое содержимое NAT-D содержит IP-адрес и порт удаленной стороны, т.е. адрес получателя UDP-пакета. оставшиеся содержимые NAT-D содержат возможные IP-адреса и порты на локальной стороне, т.е. все возможные адреса источника UDP-пакета.
Если между участниками нет NAT, первое полученное содержимое NAT-D должно соответствовать одному из локальных содержимых NAT-D, а другое содержимое NAT-D должно соответствовать IP-адресу и порту удаленной стороны. Если первая проверка не проходит, т.е. первое содержимое NAT-D не соответствует ни одному локальному IP-адресу и порту, то это означает, что между участниками существует динамический NAT, и данная сторона должна начать посылать пакеты, учитывая наличие NAT.
CKY-I и CKY-R являются Cookie Инициатора и Получателя. Они добавлены в хэш, чтобы предотвратить атаки, связанные с заранее вычисленными IP-адресами и портами.
Приведем пример обменов фазы I с определением прохождения NAT в Main Mode с аутентификацией с помощью цифровых подписей.
(рис 9.1) Main Mode с аутентификацией с помощью цифровых подписей и определением наличия NAT
Приведем пример обменов фазы I с определением прохождения NAT в Aggerissive Mode с аутентификацией с помощью цифровых подписей.
(рис 9.2) Aggressive Mode с аутентификацией с помощью цифровых под-писей и определением наличия NAT
Символ "#" означает, что данные пакеты посылаются с измененным номером порта, если определено наличие NAT.
Изменение на новые порты
Преобразования NAT, которые знают о наличии IPSec, могут вызвать проблемы. Некоторые преобразования NAT не изменяют IKE-порт источника 500, даже если существует несколько клиентов позади NAT. Они могут также использовать IKE Cookies для пересылки пакетов нужному получателю за NAT вместо использования порта источника. Эти возможности обеспечивают определенную прозрачность NAT, в результате чего IKE трудно определить наличие NAT. Наилучшим подходом считается просто передавать IKE-трафик на порт 500 и по возможности избегать использова-ния NAT, которые могут учитывать наличие IPSec.
Рассмотрим случай, когда Инициатор расположен за NAT. Инициатор должен сразу же изменить порт на 4500 после того, как он определит наличие NAT, чтобы минимизировать проблемы, связанные с NAT, которые могут учитывать наличие IPSec.
В Main Mode Инициатор должен изменить порты при посылке содержимого ID, если между хостами есть NAT. Инициатор устанавливает оба UDP-порта (и источника, и получателя) в 4500. Кроме того, к IKE-данным добавляются с помощью UDP-инкапсуляции не-ESP маркеры, которые позволят доставить трафик получателю, расположенному за NAT.
Таким образом, IKE-пакет теперь выглядит следующим образом:
IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT,]SIG_I
В данном случае предполагается аутентификация с использованием цифровых подписей.
Когда Получатель получает данный пакет, он выполняет обычную об-работку различных содержимых. Если обработка завершается успешно, то Получатель должен изменить локальное состояние таким образом, чтобы все последующие пакеты (включая информационные уведомления) к про-тивоположной стороне использовали новый порт и возможно новый IP-адрес, полученные из входящего пакета. Обычно порт отличается, так как NAT отображает UDP (500, 500) на UDP (X, 500) и UDP (4500, 4500) на UDP (Y, 4500). IP-адрес редко отличается от изначально имеющегося IP-адреса. Получатель должен посылать всю последовательность IKE-пакетов, используя UDP (4500, Y).
Аналогично, если Получатель решает выполнить обновление ключей для фазы I SA, то переговоры об обновлении ключей должны начинаться с использованием порта 4500. В этом случае нет необходимости изменять что-то еще.
После того, как выполнено изменение порта, если какой-либо пакет получен на порт 500, то считается, что это старый пакет.
Приведем пример обмена фазы I с использованием прохождения NAT в Main Mode при аутентификации с использованием цифровых подписей и с изменением порта:
(рис 9.3) Main Mode с определением наличия NAT и изменением портов
(рис 9.4) Пример SA с содержимом VID для прохождения NAT
(рис 9.5) Пример обмена с содержимым NAT-D
В Aggressive Mode последовательность аналогичная. После того, как определен NAT, Инициатор посылает
IPUDP (4500, 4500) <4 байта не-ESPмаркера>HDR*, [CERT,] NAT-D, SIG_I
Получатель выполняет обработку, аналогичную предыдущей, и, если она успешна, он должен изменить свои собственные IKE-порты. Получатель должен отвечать на все последующие IKE-пакеты, используя UDP (4500, Y).
(рис 9.6) Сообщения фазы I при прохождении NAT
Если включена поддержка прохождения NAT, порт содержимого ID как в Main, так и в Aggressive режимах должен быть установлен в 0.
В большинстве случаев для Получателя, расположенного позади NAT, NAT выполняет простое преобразование адреса 1:1. В этом случае Инициатор все еще продолжает изменять оба порта на 4500. Получатель использует алгоритм, описанный выше, хотя в этом случае Y будет равен 4500, так как никакого преобразования порта не происходит.
Изменение порта на другое значение может привести к необходимости использовать нестандартные способы определения используемых портов. Например, если Получатель расположен за NAT, преобразующим порты, и Инициатору необходимо установить соединение в первый раз, то Инициа-тор должен определить используемые порты, обычно соединяясь с некото-рым другим сервером. После того, как Инициатор выяснит, какие порты используются для прохождения NAT, обычно UDP (Z, 4500), он начинает использовать эти порты. Это аналогично случаю, когда Получатель начи-нает новые переговоры о ключах, при которых используемые порты уже известны, и никаких дополнительных обменов нет.
Quick Mode
После завершения фазы I оба участника знают, есть ли между ними NAT. Окончательное решение об использовании прохождения NAT при-нимается в Quick Mode. Об использовании прохождения NAT ведутся переговоры в содержимых SA Quick Mode. В Quick Mode оба участника так-же могут послать исходные адреса IPSec-пакетов (в случае транспортного режима), поэтому каждый может фиксировать поле контрольной суммы ТСР/IP после преобразования NAT.
Переговоры об инкапсуляции для обхода NAT
Для переговоров о прохождении NAT добавлено два новых инкапсулирующих режима:
Обычно одновременно не используются простой туннельный или транспортный режим и UDP-инкапсулирующие режимы.
Если между хостами есть NAT, то обычная транспортная или туннельная инкапсуляция не работает. В этом случае следует использовать UDP-инкапсуляцию.
Если между хостами нет NAT, то UDP-инкапсуляция не используется.
Также Инициатор не должен включать в свои предложения одновременно как обычный туннельный или транспортный режим, так и UDP-инкапсулирующий туннельный или транспортный режим.
Посылка исходных адресов отправителя и получателя
Для возможности изменения контрольных сумм ТСР обоим участникам может понадобиться знать исходные IP-адреса, которые использовались участниками при создании пакета.
Исходные IP-адреса посылаются в содержимом NAT-OA.
Инициатор <---------> NAT <---------> Получатель ^ ^ ^ Iaddr NatPub Raddr
Инициатор расположен за NAT, который в свою очередь взаимодействует с публично доступным Получателем. Инициатор и Получатель име-ют IP-адреса Iaddr и Raddr. NAT имеет публичный IP-адрес NatPub.
Инициатор:
NAT-OAi = Iaddr NAT-OAr = Raddr
Получатель:
NAT-OAi = NATPub NAT-OAr = Raddr
Инициатор <---> NAT1 <---> NAT2 <---> Получатель ^ ^ ^ ^ Iaddr Nat1Pub Nat2Pub Raddr
Здесь NAT2 "публикует" Nat2Pub в качестве адреса Получателя и перенаправляет весь трафик с данного адреса к Получателю.
Инициатор:
NAT-OAi = Iaddr NAT-OAr = Nat2Pub
Получатель:
NAT-OAi = Nat1Pub NAT-OAr = Raddr
В случае транспортного режима обе стороны должны посылать друг другу исходные адреса Инициатора и Получателя. В туннельном режиме обе стороны не должны посылать друг другу исходные адреса.
Содержимое NAT-OA посылается в первом и втором пакетах в Quick Mode. Инициатор должен послать содержимое, если он предложил UDP-инкапсулирующий транспортный режим, Получатель должен послать содержимое, если он выбрал UDP-инкапсулирующий режим. Возможна ситуация, когда Инициатор посылает NAT-OA содержимое, но предлагает и транспортный, и туннельный UDP-инкапсулирующий режимы. Если Получатель выбирает туннельный UDP-инкапсулирующий режим, то он не посылаетNAT-OA содержимое.
Пример Quick Mode, использующий NAT-OA содержимые:
(рис 9.7) Сообщения Quick Mode при прохождении NAT
(рис 9.8) Пример задания параметров прохождения NAT в транспортном режиме (часть 1)
(рис 9.9) Пример задания параметров прохождения NAT в транспортном режиме (2 часть)
(рис 9.10) Пример дампа трафика с инкапсулирующим режимом UDP Transport
Уведомления начального взаимодействия
IP-адрес и порт отправителя в уведомлении INITIAL-CONTACT для хоста, расположенного за NAT, не важны, так как NAT может изменить их, поэтому IP-адреса и номера портов не должны использоваться для определения того, какие IKE/IPSec SA следует удалять. Для этих целей следует использовать содержимое ID. Например, когда посылается INITIAL-CONTACT уведомление, то получившая его сторона должна удалить все SA, связанные с этим содержимым ID
Восстановление при истечении таймаута преобразования NAT
В некоторых случаях NAT решает удалить записи о сессиях, которые с точки зрения NAT больше не существуют (например, когда интервал подтверждения жизнеспособности SA превышен или когда NAT перезапускают). В этом случае для восстановления участники, которые не расположены за NAT, должны использовать последний действительный UDP-инкапсулирующий IKE- или IPsec-пакет от противоположной стороны, чтобы определить, какой IP-адрес и порт следует использовать. Хост позади динамического NAT не должен делать этого, так как в этом случае он может стать уязвимым для DoS-атаки, так как IP-адрес или порт другого хоста не изменился, если он не расположен за NAT.
Для этих целей не может использоваться анализ жизнеспособности, так как он не аутентифицирован, но для определения того, был ли изменен IP-адрес или порт может использоваться любой аутентифицированный IKE-пакет или ESP-пакет.
Обсуждение безопасности
Аутентификационные механизмы, основанные на IP-адресах, не могут использоваться, если выполняется преобразование NAT. Аутентификация не может основываться на IP-адресах. Это означает, что аутентификация по pre-shared ключам не может использоваться в Main Mode без использования ключей, разделяемых всеми, расположенными за NAT. Использование групповых ключей создает большой риск, потому что позволяет любому из группы аутентифицироваться в качестве VPN-шлюза, после чего просматривать и модифицировать трафик всей группы.
Ни содержимое NAT-D, ни содержимое Vendor ID не аутентифициро-ваны ни в Main Mode, ни в Aggressive Mode. Это означает, что атакующий может удалить эти содержимые, модифицировать их или добавить. Это может привести к DoS-атакам. Вставляя пакеты NAT-D, атакующий может заставить обоих участников использовать UDP-инкапсулированные пакеты вместо простого туннельного или транспортного режимов.
При взаимодействии по протоколам IKE и IPSec может возникнуть ситуация, когда между двумя участниками внезапно пропадает соединение. Такая ситуация возникает в результате проблем с маршрутизацией, переза-пуска одного из хостов и т.п. В этом случае часто не существует способа противоположной стороне определить потерю соединения. При этом SA могут существовать до тех пор, пока не истечет их время жизни. В результате этого образуется "черная дыра", в которую уходят пакеты. Часто тре-буется обнаружить черные дыры как можно скорее, чтобы обеспечить отказоустойчивость. Более того, часто необходимо определить черные дыры, чтобы предотвратить расходование лишних ресурсов.
Проблема определения падения противоположной стороны IKE реша-ется на стадии посылки Proposal, в которых указывается требование пе-риодической посылки сообщений HELLO/ACK, которые бы доказывали жизнеспособность противоположной стороны. Такая схема может быть как однонаправленной (только HELLO) или двунаправленной (пара HELLO/ACK). Часто используется термин "heartbeat" ("биение сердца") для однонаправленного сообщения проверки жизнеспособности, а термин "keepalive" используется для двунаправленных сообщений.
Как однонаправленные, так и двунаправленные сообщения посылаются через одинаковые интервалы времени. Частота, с которой они посылаются, во многом зависит от возможности их обработки. Если существует большое число одновременных IKE-сессий, то обработка доказательства жизнеспособности может быть затруднена.
Производители могут реализовать свои собственные подходы для определения жизнеспособности противоположной стороны без необходимости посылки сообщений через определенные интервалы. Данная схема, называемая Dead Peer Detection (DPD), основана на IKE-сообщениях Notify, в которых запрашивается жизнеспособность противоположной стороны IKE.
Сначала объясним использование обмена IKE-сообщениями для определения жизнеспособности противоположной стороны. Затем рассмотрим разницу в подходах heartbeat и keepalive. И, наконец, опишем формат Предложения DPD, который используется в описанных подходах. В заключении рассмотрим возникающие проблемы безопасности.
Обмен периодическими сообщениями для доказательства жизнеспособности
Как уже отмечалось, часто бывает необходимо как можно скорее определить, что соединение с противоположной стороной потеряно. IKE не предоставляет способа выполнить это, кроме как ждать до тех пор, пока не истечет период обновления ключей. В большинстве случаев это неприем-лемо, поэтому необходим способ проверки состояния противоположной стороны. В этом случае обычно использует IKE Notify либо в двунаправленном обмене сообщениями "keepalive" (HELLO, затем ACK), либо в однонаправленной посылке сообщения "heartbeat" (только HELLO).
Сравнение keepalive и heartbeat
Keepalive
Рассмотрим схему keepalive, в которой каждой стороне требуется регулярное подтверждение жизнеспособности противоположной стороны. Обмен сообщениями происходит с использованием аутентифицированного сообщения Notify. Оба участника в фазе I согласовывают интервал, в течение которого посылаются сообщения, например, 10 секунд. Каждое сообщение HELLO служит доказательством жизнеспособности противоположной стороны. В свою очередь каждая из сторон должна подтвердить сообщениеHELLO. Если по истечении 10 секунд какая-либо из сторон не получила HELLO, она сама посылает сообщение HELLO, ожидая ACK от противоположной стороны в качестве доказательства жизнеспособности. При получении как HELLO, так и ACK таймер перезапускается.
Сценарий 1:
У участника А 10-секундный таймер истекает первым, и он посылает HELLO участнику В. В отвечает ACK
(рис 9.11) Сообщения в схеме keepalive
Сценарий 2:
У участника А таймер истекает первым, он посылает HELLO участнику В. Участник В не отвечает. Участник А может повторить передачу, если он предполагает, что первое HELLO потеряно. Данная ситуация описывает, как участник А определяет, что соединение с противоположной стороной потеряно.
(рис 9.12) Сообщения в схеме keepalive в случае сбоя на стороне участника В
После определенного числа ошибок А считает, что у В произошел сбой, удаляет все SA и, возможно, инициализирует защиту от сбоев.
Преимущество данной схемы состоит в том, что участник, заинтересованный в жизнеспособности противоположной стороны, начинает обмен сообщениями. В Сценарии 1 участник А заинтересован в жизнеспособности участника В и, следовательно, посылает HELLO. В такой схеме возможно, чтобы участник В никогда не интересовался жизнеспособностью А. В данном случае ответственность за жизнеспособность соединения всегда лежит на стороне А, инициирующей обмен.
Heartbeat
Рассмотрим схему доказательства жизнеспособности, состоящую из однонаправленных (без подтверждения) сообщений. Сторона, которая за-интересована в жизнеспособности противоположной стороны, должна полагаться на то, что противоположная сторона сама периодически будет посылать сообщения, демонстрирую свою жизнеспособность. В данной схеме обмен сообщениями может быть следующим:
Сценарий 3:
Участники А и В заинтересованы в жизнеспособности друг друга. Определение жизнеспособности каждым участником зависит от того, будет ли другой периодически посылать HELLO
(рис 9.13) Сообщения в схеме Heartbeat
Сценарий 4:
Определение сбоя противоположной стороны.
(рис 9.14) Сообщения в схеме Heartbeat в случае сбоя на сто-роне участника В
Недостатком данной схемы является то, что предполагается, что противоположная сторона будет демонстрировать свою жизнеспособность. Но с другой стороны, участник В может никогда не интересоваться жизнеспособностью участника А. Тем не менее, если А интересуется жизнеспособностью В, В должен отдавать себе отчет в этом и поддерживать необходимую информацию о состоянии, периодически посылая HELLO к А. Недостаток данной схемы становится очевидным в сценарии удаленного доступа. Рассмотрим VPN-шлюз, на котором закан-чивается большое количество сессий (порядка 50 000 или более участников). Если какому-то участнику, требуется поддержка отказоустойчивости, то шлюз должен будет посылать HELLO-пакеты каждые 10 секунд. Такая схема плохо масштабируема, так как шлюз должен посылать 50 000 сообщений каждые несколько секунд.
В обеих схемах должны быть выполнены определенные переговоры, чтобы каждая сторона знала, как часто противоположная сторона предполагает получать сообщения HELLO. Это добавляет определенную слож-ность. Аналогично, необходимость периодически посылать сообщения (не зависимо от другого трафика IPSec/IKE) также добавляет вычислительную нагрузку на систему.
DPD позволяет ликвидировать недостатки схем keepalive и heartbeat введением определенной логики управления обменом сообщений. В частности, keepalive и heartbeat должны обязательно обмениваться HELLO через определенные интервалы времени. В отличие от этого при использовании DPD каждый участник в большей степени не зависит от другого. Участник может запрашивать доказательство жизнеспособности в тот момент, когда это ему необходимо, а не через фиксированный интервал времени. Такая асинхронность DPD-обменов позволяет посылать разное количество сообщений, чем достигается большая масштабируемость.
(рис 9.15) Веб-интерфейс для указания использования протокола DPD
Рассмотрим взаимодействие двух DPD-участников А и В. Если между ними существует IPSec-трафик, то нет необходимости в регулярном доказательстве жизнеспособности. С другой стороны, если существует период простоя, в течение которого между ними нет обмена пакетами, то жизне-способность каждого участника может вызывать сомнения. Однако знание о жизнеспособности противоположной стороны необходимо только в том случае, если должен быть передан трафик. Например, если участник А должен послать IPSec-пакеты после определенного периода простоя, он должен быть уверен в жизнеспособности В. В этот момент участник А может инициировать DPD-обмен.
Кроме того, каждая сторона может иметь разные требования к определению жизнеспособности. Участнику А, например, может требоваться высокая отказоустойчивость, в то время как требования к ресурсам не столь жесткие. При использовании DPD каждая сторона может определить свою собственную "метрику волнения" - интервал, который определяет необходимость DPD-обмена. В данном примере участник А может определить DPD-интервал в 10 секунд. Затем, если сторона А посылает исходящий IPSec-трафик, но в течение 10 секунд происходит сбой при получении входящего трафика, она может инициировать DPD-обмен.
С другой стороны, участник В определяет DPD-интервал 5 минут. Если IPSec-сессия простаивает в течение 5 минут, то участник В может инициировать DPD-обмен, если в следующий момент он собирается послать IPSec-пакет к А.
Следует заметить, что решение о том, когда следует инициировать DPD-обмен, во многом зависит от реализации. Возможна реализация, когда DPD-сообщения посылаются через определенные интервалы после периода простоя.
DPD Vendor ID
Для указания возможностей DPD участник должен послать DPD Vendor ID. Оба участника IKE-сессии должны послать DPD Vendor ID перед тем, как начинать DPD-обмены. Формат DPD Vendor ID следующий:
(рис 9.16) Формат DPD Vendor ID
Где
HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}
Сторона IKE должна послать Vendor ID, если она хочет выполнять DPD-обмены.
Обмены сообщениями
DPD-обмен является двунаправленным (HELLO/ACK) Notify-сообщением. Обмен определен следующим образом:
(рис 9.17) Сообщения протокола DPD
R-U-THERE сообщение соответствует HELLO, а R-U-THERE-ACK соответствует ACK. Оба сообщения являются просто содержимыми IKE Notify. Определены два новых типа Notify-сообщений IKE: R-U-THERE и R-U-THERE-ACK.
Участник, который послал DPD Vendor ID, должен ответить на запрос R-U-THERE. Участник должен отбрасывать незашифрованные R-U-THERE и R-U-THERE-ACK сообщения.
Формат сообщения NOTIFY (R-U-THERE / R-U-THERE-ACK)
Сообщение R-U-THERE имеет следующий формат:
(рис 9.18) Формат сообщения R-U-THERE
Так как данное сообщение является IKE NOTIFY, то поля Next Payload, RESERVED и Payload Length должны быть установлены в соответствии с требованиями протокола IKE. Остальные поля установлены следующим образом:
DOI – IPSEC-DOI.Protocol ID – должно быть установлено в ID протокола для IKE.SPI Size – установлено в 16, длина двух IKE Cookies.Notify-сообщения должен быть R-U-THERESPI установлен в Cookie Инициатора и Получателя IKE SA.Notification Data содержат последовательный номер, соответствующий данному сообщению.Формат R-U-THERE-ACK тот же самый, за исключением того, что тип сообщения Notify есть R-U-THERE-ACK, и данные содержат последовательный номер, соответствующий полученному R-U-THERE сообщению.
Начало DPD-обмена
Вместо того, чтобы основываться на определенном временном интервале, в течение которого необходимо выполнить обмен сообщениями, предполагается, что R-U-THERE сообщения могут быть посланы в любое время. Участник IKE посылает R-U-THERE запрос противоположной стороне только в том случае, если его интересует жизнеспособность противо-положной стороны. С этой точки зрения, если существует регулярный трафик между участниками, то любая из сторон может использовать данный трафик как доказательство жизнеспособности противоположной стороны, и обоим участникам не следует инициировать DPD-обмен.
Участник хранит состояние данного DPD-обмена. Этого означает, что после того, как был послан R-U-THERE запрос, он ожидает получить ACK в ответе в течение определенного времени. Если не получен ACK, то переда-ется повторный запрос. После определенного количества повторных передач считается, что противоположная сторона не отвечает, и удаляются IPSec и IKE SA с противоположной стороной.
Возможные реализации
Так как жизнеспособность противоположной стороны запрашивается только тогда, когда отсутствует трафик, производители могут начинать отслеживать состояние только при отсутствии трафика. В этом случае жизнеспособность противоположной стороны важна только в том случае, если требуется посылать исходящий трафик. Чтобы сделать это, можно иниции-ровать DPD-обмен (т.е. послать R-U-THERE сообщение), если есть определенный период простоя, после которого требуется послать исходящий трафик. Кроме того, DPD-обмен может инициироваться, если был послан исходящий IPSec-трафик, но в ответ не были получены входящие IPSec-пакеты. Полный DPD-обмен (т.е. передать R-U-THERE и получить соответствующий R-U-THERE-ACK) служит доказательством жизнеспособности до тех пор, пока не начнется следующий период простоя.
Также, так как в DPD нет никакого обязательного интервала, этот "период простоя" (или "метрика волнения") зависит от реализации. Переговоры об этом значении, как правило, не ведутся.
Сравнение протокола DPD со схемами keepalive и heartbeat
Выигрыш в производительности, который дает DPD по сравнению с традиционными схемами keepalive и heartbeat, получается из-за того, что нет необходимости регулярно посылать сообщения. Реализация схемы keepalive требует одного таймера для сигнализации, когда следует посылать HELLO-сообщение, и одного таймера для отслеживания таймаута ACK от противоположной стороны, который также может являться таймером повторной передачи. В схеме heartbeat необходимо иметь один таймер для сигнализации о том, что следует ожидать HELLO от противоположной стороны. В отличие от этих схем, в схеме DPD необходимо хранить отметку времени, когда был получен последний трафик от противоположной стороны (что является началом "периода простоя"). После того, как было посла-но DPD R-U-THERE сообщение, необходимо иметь таймер, который будет сигнализировать о необходимости повторной передачи. Таким образом, уменьшается необходимость в поддержке состояния таймера, в результате чего улучшается масштабируемость. (Предполагается, что поддерживать отметку времени проще, чем таймер.)
Более того, так как DPD-обмен возникает только тогда, когда не получен трафик от противоположной стороны, количество IKE-сообщений, которые должны быть посланы и обработаны, уменьшается. Как следствие, масшабируемость DPD гораздо лучше, чем при использовании keepalive и heartbeat.
DPD поддерживает модель HELLO/ACK, существующую в keepalive, при этом обмен инициируется только тогда, когда участнику важна жизнеспособность противоположной стороны.
Защита от replay-атак и фальшивого доказательства жизнеспособности
1. Последовательный номер в DPD-сообщениях
Для защиты от replay-атак и фальшивого доказательства жизнеспособности в каждом R-U-THERE сообщении используется 32-битный последовательный номер. Получатель R-U-THERE сообщения должен послать R-U-THERE-ACK с тем же самым номером. При получении R-U-THERE-ACK сообщения проверяется правильность полученного последовательного номера.
Кроме того, отправители и R-U-THERE сообщения, иR-U-THERE-ACK сообщения проверяют корректность Cookies Инициатора и Получателя, которые указаны в поле SPI.
2. Выбор и поддержка последовательных номеров
Оба DPD-участника могут инициировать DPD-обмен, т.е. оба участника могут послать R-U-THERE сообщение. При этом каждый участник под-держивает свой собственный последовательный номер для R-U-THERE сообщений. Первое R-U-THERE сообщение, посланное в течение данной сессии, имеет случайно выбранный номер. Для предотвращения переполнения 32-битного значения старший бит установлен в ноль. В следующих R-U-THERE сообщениях последовательный номер возрастает на единицу. Последовательные номера могут быть выбраны заново при истечении IKE SA. Каждый участник также хранит последовательный номер R-U-THERE сообщения противоположной стороны.
Как правило, поддерживается окно принимаемых последовательных номеров.
Обсуждение безопасности
Как уже говорилось, DPD использует последовательные номера для проверки жизнеспособности. Рассмотрим преимущества использования последовательных номеров по сравнению со случайными числами.
Хотя использование последовательных номеров требует поддержки состояния противоположной стороны, они также обеспечивают дополнительный способ защиты от некоторых replay-атак. Рассмотрим случай, когда участник А посылает участнику В действительное DPD R-U-THERE сообщение. Атакующий С может перехватить данное сообщение и послать несколько его копий. В расшифрует и обработает каждый пакет (не зависимо от того, используются ли последовательные номера или nonces). При использовании последовательных номеров В может определить, что пакеты являются повторами, так как их последовательные номера не возрастают. В этом случае В не будет создавать, шифровать и отправлять ACK. Если же используются nonces, то для предотвращения replay-атак В должен поддерживать список недавно полученных nonces.
Использование IPSec имеет высокую вычислительную нагрузку на хостах и шлюзах безопасности, которые реализуют эти протоколы. Это связано с памятью, необходимой для хранения структур данных IPSec, вычисление значений проверки целостности, шифрование и расшифрование. Использование протоколов управления SA/ ключом, особенно тех, которые реализуют криптографию с открытым ключом, также добавляет соответствующую вычислительную нагрузку при использовании IPSec.
Использование IPSec также увеличивает стоимость компонентов, осуществляющих пересылку и маршрутизацию, но не использующих IPSec. Это происходит из-за возрастания размера пакета в результате добавления заголовков АН и/или ESP, АН и ESP туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве случаев это возрастание не будет сильно влиять на производительность. Тем не менее, иногда такое влияние может быть большим, например, передача зашифрованного трафика по низкоскоростным каналам.
Вначале опишем изменения в фазе I IKE, необходимые для прохождения NAT. Это включает определение, поддерживает ли противоположная сторона прохождение NAT и определение, сколько преобразований NAT существует между участниками.
Далее опишем, какие следует вести переговоры в Quick Mode IKE об использовании UDP для инкапсуляции IPSec-пакетов. Также опишем, как при необходимости передавать исходные адреса отправителя и получателя противоположной стороне. Эти адреса используются в транспортном режиме для изменения TCP/IP контрольных сумм, чтобы они были правильными после преобразования NAT. (NAT не может сделать это, потому что контрольная сумма TCP/IP находится внутри UDP, инкапсулирующего IPSec-пакет.)
Базовым сценарием в данном документе является предположение, что Инициатор расположен за NA(P)T, а Получатель имеет фиксированный IP-адрес.
Фаза I
В фазе I выполняется определение поддержки прохождения NAT обоими участниками и определение того, что между участниками имело место преобразование NAT.
NAT может изменить UDP-порт источника в IKE-пакетах, поэтому Получатель должен уметь обрабатывать IKE-пакеты, чей порт источника отличается от 500. NAT не должен менять порт источника, если только один IPSec-хост расположен за NAT. Для первого IPSec-хоста NAT может оставить порт 500 и изменять номера портов только для последующих коммуникаций.
Получатель должен возвращать пакеты на адрес источника, указанный в пакете. Это означает, что Получатель, выполняющий повторные переговоры о ключах или посылающий оповещение Инициатору, должен посылать пакеты, используя тот же самый набор портов и IP-адресов, который использовался в последней IKE SA.
Например, когда Инициатор посылает пакет с портами источника и получателя 500, NAT может изменить их на порт источника 12312 и порт получателя 500. Получатель должен иметь возможность обработать пакет с портом источника 12312. Он должен ответить, указав в пакете порт источника 500 и порт получателя 12312. Затем NAT будет преобразовывать в данном пакете порт источника на 500 и порт получателя на 500.
Определение поддержки прохода NAT
Возможность прохождения NAT удаленным хостом определяется посредством обмена содержимыми ID производителя (VID). В первых двух сообщениях фазы I должно посылаться содержимое ID производителя для определения возможности прохождения NAT. Содержимым является хэш-код MD5, вычисленный для строки "RFC 3947".
Определение наличия NAT
В фазе I посылается содержимое NAT-D, которое не только определяет наличие NAT между двумя противоположными сторонами IKE, но и определяет, где находится NAT. Расположение NAT важно, так как поддержка инициируется участником, расположенным за NAT.
Для определения NAT между двумя хостами необходимо определить изменялись ли IP-адреса и порты при пересылке. Это делается посылкой в содержимом NAT-D хэшей IP-адресов и портов обоих участников друг другу. Если на обоих концах вычислены те же самые хэши, что и полученные в сообщениях NAT-D, то это означает, что между участниками нет NAT. Если хэши не совпадают, где-то была выполнена трансляция адреса или порта. Это означает, что для получения IPSec-пакетов необходимо выполнить прохождение NAT.
Если отправитель пакета не знает свой собственный IP-адрес (в случае нескольких интерфейсов может быть неизвестно, какой IP-адрес будет использоваться для маршрутизации пакета), отправитель может поместить в пакет несколько хэшей локальных IP-адресов в виде отдельных NAT-D со-держимых. В этом случае NAT присутствует тогда и только тогда, когда ни для одного из хэшей не найдено соответствие.
Содержимые NAT-D включаются в третий и четвертый пакеты Main Mode и второй и третий пакеты Aggressive Mode.
Хэш вычисляется для следующих значений:
HASH = HASH (CKY-I | CKY-R | IP | Port)
Первое содержимое NAT-D содержит IP-адрес и порт удаленной стороны, т.е. адрес получателя UDP-пакета. оставшиеся содержимые NAT-D содержат возможные IP-адреса и порты на локальной стороне, т.е. все возможные адреса источника UDP-пакета.
Если между участниками нет NAT, первое полученное содержимое NAT-D должно соответствовать одному из локальных содержимых NAT-D, а другое содержимое NAT-D должно соответствовать IP-адресу и порту удаленной стороны. Если первая проверка не проходит, т.е. первое содержимое NAT-D не соответствует ни одному локальному IP-адресу и порту, то это означает, что между участниками существует динамический NAT, и данная сторона должна начать посылать пакеты, учитывая наличие NAT.
CKY-I и CKY-R являются Cookie Инициатора и Получателя. Они добавлены в хэш, чтобы предотвратить атаки, связанные с заранее вычисленными IP-адресами и портами.
Приведем пример обменов фазы I с определением прохождения NAT в Main Mode с аутентификацией с помощью цифровых подписей.
(рис 9.1) Main Mode с аутентификацией с помощью цифровых подписей и определением наличия NAT
Приведем пример обменов фазы I с определением прохождения NAT в Aggerissive Mode с аутентификацией с помощью цифровых подписей.
(рис 9.2) Aggressive Mode с аутентификацией с помощью цифровых под-писей и определением наличия NAT
Символ "#" означает, что данные пакеты посылаются с измененным номером порта, если определено наличие NAT.
Изменение на новые порты
Преобразования NAT, которые знают о наличии IPSec, могут вызвать проблемы. Некоторые преобразования NAT не изменяют IKE-порт источника 500, даже если существует несколько клиентов позади NAT. Они могут также использовать IKE Cookies для пересылки пакетов нужному получателю за NAT вместо использования порта источника. Эти возможности обеспечивают определенную прозрачность NAT, в результате чего IKE трудно определить наличие NAT. Наилучшим подходом считается просто передавать IKE-трафик на порт 500 и по возможности избегать использова-ния NAT, которые могут учитывать наличие IPSec.
Рассмотрим случай, когда Инициатор расположен за NAT. Инициатор должен сразу же изменить порт на 4500 после того, как он определит наличие NAT, чтобы минимизировать проблемы, связанные с NAT, которые могут учитывать наличие IPSec.
В Main Mode Инициатор должен изменить порты при посылке содержимого ID, если между хостами есть NAT. Инициатор устанавливает оба UDP-порта (и источника, и получателя) в 4500. Кроме того, к IKE-данным добавляются с помощью UDP-инкапсуляции не-ESP маркеры, которые позволят доставить трафик получателю, расположенному за NAT.
Таким образом, IKE-пакет теперь выглядит следующим образом:
IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT,]SIG_I
В данном случае предполагается аутентификация с использованием цифровых подписей.
Когда Получатель получает данный пакет, он выполняет обычную об-работку различных содержимых. Если обработка завершается успешно, то Получатель должен изменить локальное состояние таким образом, чтобы все последующие пакеты (включая информационные уведомления) к про-тивоположной стороне использовали новый порт и возможно новый IP-адрес, полученные из входящего пакета. Обычно порт отличается, так как NAT отображает UDP (500, 500) на UDP (X, 500) и UDP (4500, 4500) на UDP (Y, 4500). IP-адрес редко отличается от изначально имеющегося IP-адреса. Получатель должен посылать всю последовательность IKE-пакетов, используя UDP (4500, Y).
Аналогично, если Получатель решает выполнить обновление ключей для фазы I SA, то переговоры об обновлении ключей должны начинаться с использованием порта 4500. В этом случае нет необходимости изменять что-то еще.
После того, как выполнено изменение порта, если какой-либо пакет получен на порт 500, то считается, что это старый пакет.
Приведем пример обмена фазы I с использованием прохождения NAT в Main Mode при аутентификации с использованием цифровых подписей и с изменением порта:
(рис 9.3) Main Mode с определением наличия NAT и изменением портов
(рис 9.4) Пример SA с содержимом VID для прохождения NAT
(рис 9.5) Пример обмена с содержимым NAT-D
В Aggressive Mode последовательность аналогичная. После того, как определен NAT, Инициатор посылает
IPUDP (4500, 4500) <4 байта не-ESPмаркера>HDR*, [CERT,] NAT-D, SIG_I
Получатель выполняет обработку, аналогичную предыдущей, и, если она успешна, он должен изменить свои собственные IKE-порты. Получатель должен отвечать на все последующие IKE-пакеты, используя UDP (4500, Y).
(рис 9.6) Сообщения фазы I при прохождении NAT
Если включена поддержка прохождения NAT, порт содержимого ID как в Main, так и в Aggressive режимах должен быть установлен в 0.
В большинстве случаев для Получателя, расположенного позади NAT, NAT выполняет простое преобразование адреса 1:1. В этом случае Инициатор все еще продолжает изменять оба порта на 4500. Получатель использует алгоритм, описанный выше, хотя в этом случае Y будет равен 4500, так как никакого преобразования порта не происходит.
Изменение порта на другое значение может привести к необходимости использовать нестандартные способы определения используемых портов. Например, если Получатель расположен за NAT, преобразующим порты, и Инициатору необходимо установить соединение в первый раз, то Инициа-тор должен определить используемые порты, обычно соединяясь с некото-рым другим сервером. После того, как Инициатор выяснит, какие порты используются для прохождения NAT, обычно UDP (Z, 4500), он начинает использовать эти порты. Это аналогично случаю, когда Получатель начи-нает новые переговоры о ключах, при которых используемые порты уже известны, и никаких дополнительных обменов нет.
Quick Mode
После завершения фазы I оба участника знают, есть ли между ними NAT. Окончательное решение об использовании прохождения NAT при-нимается в Quick Mode. Об использовании прохождения NAT ведутся переговоры в содержимых SA Quick Mode. В Quick Mode оба участника так-же могут послать исходные адреса IPSec-пакетов (в случае транспортного режима), поэтому каждый может фиксировать поле контрольной суммы ТСР/IP после преобразования NAT.
Переговоры об инкапсуляции для обхода NAT
Для переговоров о прохождении NAT добавлено два новых инкапсулирующих режима:
Обычно одновременно не используются простой туннельный или транспортный режим и UDP-инкапсулирующие режимы.
Если между хостами есть NAT, то обычная транспортная или туннельная инкапсуляция не работает. В этом случае следует использовать UDP-инкапсуляцию.
Если между хостами нет NAT, то UDP-инкапсуляция не используется.
Также Инициатор не должен включать в свои предложения одновременно как обычный туннельный или транспортный режим, так и UDP-инкапсулирующий туннельный или транспортный режим.
Посылка исходных адресов отправителя и получателя
Для возможности изменения контрольных сумм ТСР обоим участникам может понадобиться знать исходные IP-адреса, которые использовались участниками при создании пакета.
Исходные IP-адреса посылаются в содержимом NAT-OA.
Инициатор <---------> NAT <---------> Получатель ^ ^ ^ Iaddr NatPub Raddr
Инициатор расположен за NAT, который в свою очередь взаимодействует с публично доступным Получателем. Инициатор и Получатель име-ют IP-адреса Iaddr и Raddr. NAT имеет публичный IP-адрес NatPub.
Инициатор:
NAT-OAi = Iaddr NAT-OAr = Raddr
Получатель:
NAT-OAi = NATPub NAT-OAr = Raddr
Инициатор <---> NAT1 <---> NAT2 <---> Получатель ^ ^ ^ ^ Iaddr Nat1Pub Nat2Pub Raddr
Здесь NAT2 "публикует" Nat2Pub в качестве адреса Получателя и перенаправляет весь трафик с данного адреса к Получателю.
Инициатор:
NAT-OAi = Iaddr NAT-OAr = Nat2Pub
Получатель:
NAT-OAi = Nat1Pub NAT-OAr = Raddr
В случае транспортного режима обе стороны должны посылать друг другу исходные адреса Инициатора и Получателя. В туннельном режиме обе стороны не должны посылать друг другу исходные адреса.
Содержимое NAT-OA посылается в первом и втором пакетах в Quick Mode. Инициатор должен послать содержимое, если он предложил UDP-инкапсулирующий транспортный режим, Получатель должен послать содержимое, если он выбрал UDP-инкапсулирующий режим. Возможна ситуация, когда Инициатор посылает NAT-OA содержимое, но предлагает и транспортный, и туннельный UDP-инкапсулирующий режимы. Если Получатель выбирает туннельный UDP-инкапсулирующий режим, то он не посылаетNAT-OA содержимое.
Пример Quick Mode, использующий NAT-OA содержимые:
(рис 9.7) Сообщения Quick Mode при прохождении NAT
(рис 9.8) Пример задания параметров прохождения NAT в транспортном режиме (часть 1)
(рис 9.9) Пример задания параметров прохождения NAT в транспортном режиме (2 часть)
(рис 9.10) Пример дампа трафика с инкапсулирующим режимом UDP Transport
Уведомления начального взаимодействия
IP-адрес и порт отправителя в уведомлении INITIAL-CONTACT для хоста, расположенного за NAT, не важны, так как NAT может изменить их, поэтому IP-адреса и номера портов не должны использоваться для определения того, какие IKE/IPSec SA следует удалять. Для этих целей следует использовать содержимое ID. Например, когда посылается INITIAL-CONTACT уведомление, то получившая его сторона должна удалить все SA, связанные с этим содержимым ID
Восстановление при истечении таймаута преобразования NAT
В некоторых случаях NAT решает удалить записи о сессиях, которые с точки зрения NAT больше не существуют (например, когда интервал подтверждения жизнеспособности SA превышен или когда NAT перезапускают). В этом случае для восстановления участники, которые не расположены за NAT, должны использовать последний действительный UDP-инкапсулирующий IKE- или IPsec-пакет от противоположной стороны, чтобы определить, какой IP-адрес и порт следует использовать. Хост позади динамического NAT не должен делать этого, так как в этом случае он может стать уязвимым для DoS-атаки, так как IP-адрес или порт другого хоста не изменился, если он не расположен за NAT.
Для этих целей не может использоваться анализ жизнеспособности, так как он не аутентифицирован, но для определения того, был ли изменен IP-адрес или порт может использоваться любой аутентифицированный IKE-пакет или ESP-пакет.
Обсуждение безопасности
Аутентификационные механизмы, основанные на IP-адресах, не могут использоваться, если выполняется преобразование NAT. Аутентификация не может основываться на IP-адресах. Это означает, что аутентификация по pre-shared ключам не может использоваться в Main Mode без использования ключей, разделяемых всеми, расположенными за NAT. Использование групповых ключей создает большой риск, потому что позволяет любому из группы аутентифицироваться в качестве VPN-шлюза, после чего просматривать и модифицировать трафик всей группы.
Ни содержимое NAT-D, ни содержимое Vendor ID не аутентифициро-ваны ни в Main Mode, ни в Aggressive Mode. Это означает, что атакующий может удалить эти содержимые, модифицировать их или добавить. Это может привести к DoS-атакам. Вставляя пакеты NAT-D, атакующий может заставить обоих участников использовать UDP-инкапсулированные пакеты вместо простого туннельного или транспортного режимов.
При взаимодействии по протоколам IKE и IPSec может возникнуть ситуация, когда между двумя участниками внезапно пропадает соединение. Такая ситуация возникает в результате проблем с маршрутизацией, переза-пуска одного из хостов и т.п. В этом случае часто не существует способа противоположной стороне определить потерю соединения. При этом SA могут существовать до тех пор, пока не истечет их время жизни. В результате этого образуется "черная дыра", в которую уходят пакеты. Часто тре-буется обнаружить черные дыры как можно скорее, чтобы обеспечить отказоустойчивость. Более того, часто необходимо определить черные дыры, чтобы предотвратить расходование лишних ресурсов.
Проблема определения падения противоположной стороны IKE реша-ется на стадии посылки Proposal, в которых указывается требование пе-риодической посылки сообщений HELLO/ACK, которые бы доказывали жизнеспособность противоположной стороны. Такая схема может быть как однонаправленной (только HELLO) или двунаправленной (пара HELLO/ACK). Часто используется термин "heartbeat" ("биение сердца") для однонаправленного сообщения проверки жизнеспособности, а термин "keepalive" используется для двунаправленных сообщений.
Как однонаправленные, так и двунаправленные сообщения посылаются через одинаковые интервалы времени. Частота, с которой они посылаются, во многом зависит от возможности их обработки. Если существует большое число одновременных IKE-сессий, то обработка доказательства жизнеспособности может быть затруднена.
Производители могут реализовать свои собственные подходы для определения жизнеспособности противоположной стороны без необходимости посылки сообщений через определенные интервалы. Данная схема, называемая Dead Peer Detection (DPD), основана на IKE-сообщениях Notify, в которых запрашивается жизнеспособность противоположной стороны IKE.
Сначала объясним использование обмена IKE-сообщениями для определения жизнеспособности противоположной стороны. Затем рассмотрим разницу в подходах heartbeat и keepalive. И, наконец, опишем формат Предложения DPD, который используется в описанных подходах. В заключении рассмотрим возникающие проблемы безопасности.
Обмен периодическими сообщениями для доказательства жизнеспособности
Как уже отмечалось, часто бывает необходимо как можно скорее определить, что соединение с противоположной стороной потеряно. IKE не предоставляет способа выполнить это, кроме как ждать до тех пор, пока не истечет период обновления ключей. В большинстве случаев это неприем-лемо, поэтому необходим способ проверки состояния противоположной стороны. В этом случае обычно использует IKE Notify либо в двунаправленном обмене сообщениями "keepalive" (HELLO, затем ACK), либо в однонаправленной посылке сообщения "heartbeat" (только HELLO).
Сравнение keepalive и heartbeat
Keepalive
Рассмотрим схему keepalive, в которой каждой стороне требуется регулярное подтверждение жизнеспособности противоположной стороны. Обмен сообщениями происходит с использованием аутентифицированного сообщения Notify. Оба участника в фазе I согласовывают интервал, в течение которого посылаются сообщения, например, 10 секунд. Каждое сообщение HELLO служит доказательством жизнеспособности противоположной стороны. В свою очередь каждая из сторон должна подтвердить сообщениеHELLO. Если по истечении 10 секунд какая-либо из сторон не получила HELLO, она сама посылает сообщение HELLO, ожидая ACK от противоположной стороны в качестве доказательства жизнеспособности. При получении как HELLO, так и ACK таймер перезапускается.
Сценарий 1:
У участника А 10-секундный таймер истекает первым, и он посылает HELLO участнику В. В отвечает ACK
(рис 9.11) Сообщения в схеме keepalive
Сценарий 2:
У участника А таймер истекает первым, он посылает HELLO участнику В. Участник В не отвечает. Участник А может повторить передачу, если он предполагает, что первое HELLO потеряно. Данная ситуация описывает, как участник А определяет, что соединение с противоположной стороной потеряно.
(рис 9.12) Сообщения в схеме keepalive в случае сбоя на стороне участника В
После определенного числа ошибок А считает, что у В произошел сбой, удаляет все SA и, возможно, инициализирует защиту от сбоев.
Преимущество данной схемы состоит в том, что участник, заинтересованный в жизнеспособности противоположной стороны, начинает обмен сообщениями. В Сценарии 1 участник А заинтересован в жизнеспособности участника В и, следовательно, посылает HELLO. В такой схеме возможно, чтобы участник В никогда не интересовался жизнеспособностью А. В данном случае ответственность за жизнеспособность соединения всегда лежит на стороне А, инициирующей обмен.
Heartbeat
Рассмотрим схему доказательства жизнеспособности, состоящую из однонаправленных (без подтверждения) сообщений. Сторона, которая за-интересована в жизнеспособности противоположной стороны, должна полагаться на то, что противоположная сторона сама периодически будет посылать сообщения, демонстрирую свою жизнеспособность. В данной схеме обмен сообщениями может быть следующим:
Сценарий 3:
Участники А и В заинтересованы в жизнеспособности друг друга. Определение жизнеспособности каждым участником зависит от того, будет ли другой периодически посылать HELLO
(рис 9.13) Сообщения в схеме Heartbeat
Сценарий 4:
Определение сбоя противоположной стороны.
(рис 9.14) Сообщения в схеме Heartbeat в случае сбоя на сто-роне участника В
Недостатком данной схемы является то, что предполагается, что противоположная сторона будет демонстрировать свою жизнеспособность. Но с другой стороны, участник В может никогда не интересоваться жизнеспособностью участника А. Тем не менее, если А интересуется жизнеспособностью В, В должен отдавать себе отчет в этом и поддерживать необходимую информацию о состоянии, периодически посылая HELLO к А. Недостаток данной схемы становится очевидным в сценарии удаленного доступа. Рассмотрим VPN-шлюз, на котором закан-чивается большое количество сессий (порядка 50 000 или более участников). Если какому-то участнику, требуется поддержка отказоустойчивости, то шлюз должен будет посылать HELLO-пакеты каждые 10 секунд. Такая схема плохо масштабируема, так как шлюз должен посылать 50 000 сообщений каждые несколько секунд.
В обеих схемах должны быть выполнены определенные переговоры, чтобы каждая сторона знала, как часто противоположная сторона предполагает получать сообщения HELLO. Это добавляет определенную слож-ность. Аналогично, необходимость периодически посылать сообщения (не зависимо от другого трафика IPSec/IKE) также добавляет вычислительную нагрузку на систему.
DPD позволяет ликвидировать недостатки схем keepalive и heartbeat введением определенной логики управления обменом сообщений. В частности, keepalive и heartbeat должны обязательно обмениваться HELLO через определенные интервалы времени. В отличие от этого при использовании DPD каждый участник в большей степени не зависит от другого. Участник может запрашивать доказательство жизнеспособности в тот момент, когда это ему необходимо, а не через фиксированный интервал времени. Такая асинхронность DPD-обменов позволяет посылать разное количество сообщений, чем достигается большая масштабируемость.
(рис 9.15) Веб-интерфейс для указания использования протокола DPD
Рассмотрим взаимодействие двух DPD-участников А и В. Если между ними существует IPSec-трафик, то нет необходимости в регулярном доказательстве жизнеспособности. С другой стороны, если существует период простоя, в течение которого между ними нет обмена пакетами, то жизне-способность каждого участника может вызывать сомнения. Однако знание о жизнеспособности противоположной стороны необходимо только в том случае, если должен быть передан трафик. Например, если участник А должен послать IPSec-пакеты после определенного периода простоя, он должен быть уверен в жизнеспособности В. В этот момент участник А может инициировать DPD-обмен.
Кроме того, каждая сторона может иметь разные требования к определению жизнеспособности. Участнику А, например, может требоваться высокая отказоустойчивость, в то время как требования к ресурсам не столь жесткие. При использовании DPD каждая сторона может определить свою собственную "метрику волнения" - интервал, который определяет необходимость DPD-обмена. В данном примере участник А может определить DPD-интервал в 10 секунд. Затем, если сторона А посылает исходящий IPSec-трафик, но в течение 10 секунд происходит сбой при получении входящего трафика, она может инициировать DPD-обмен.
С другой стороны, участник В определяет DPD-интервал 5 минут. Если IPSec-сессия простаивает в течение 5 минут, то участник В может инициировать DPD-обмен, если в следующий момент он собирается послать IPSec-пакет к А.
Следует заметить, что решение о том, когда следует инициировать DPD-обмен, во многом зависит от реализации. Возможна реализация, когда DPD-сообщения посылаются через определенные интервалы после периода простоя.
DPD Vendor ID
Для указания возможностей DPD участник должен послать DPD Vendor ID. Оба участника IKE-сессии должны послать DPD Vendor ID перед тем, как начинать DPD-обмены. Формат DPD Vendor ID следующий:
(рис 9.16) Формат DPD Vendor ID
Где
HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}
Сторона IKE должна послать Vendor ID, если она хочет выполнять DPD-обмены.
Обмены сообщениями
DPD-обмен является двунаправленным (HELLO/ACK) Notify-сообщением. Обмен определен следующим образом:
(рис 9.17) Сообщения протокола DPD
R-U-THERE сообщение соответствует HELLO, а R-U-THERE-ACK соответствует ACK. Оба сообщения являются просто содержимыми IKE Notify. Определены два новых типа Notify-сообщений IKE: R-U-THERE и R-U-THERE-ACK.
Участник, который послал DPD Vendor ID, должен ответить на запрос R-U-THERE. Участник должен отбрасывать незашифрованные R-U-THERE и R-U-THERE-ACK сообщения.
Формат сообщения NOTIFY (R-U-THERE / R-U-THERE-ACK)
Сообщение R-U-THERE имеет следующий формат:
(рис 9.18) Формат сообщения R-U-THERE
Так как данное сообщение является IKE NOTIFY, то поля Next Payload, RESERVED и Payload Length должны быть установлены в соответствии с требованиями протокола IKE. Остальные поля установлены следующим образом:
DOI – IPSEC-DOI.Protocol ID – должно быть установлено в ID протокола для IKE.SPI Size – установлено в 16, длина двух IKE Cookies.Notify-сообщения должен быть R-U-THERESPI установлен в Cookie Инициатора и Получателя IKE SA.Notification Data содержат последовательный номер, соответствующий данному сообщению.Формат R-U-THERE-ACK тот же самый, за исключением того, что тип сообщения Notify есть R-U-THERE-ACK, и данные содержат последовательный номер, соответствующий полученному R-U-THERE сообщению.
Начало DPD-обмена
Вместо того, чтобы основываться на определенном временном интервале, в течение которого необходимо выполнить обмен сообщениями, предполагается, что R-U-THERE сообщения могут быть посланы в любое время. Участник IKE посылает R-U-THERE запрос противоположной стороне только в том случае, если его интересует жизнеспособность противо-положной стороны. С этой точки зрения, если существует регулярный трафик между участниками, то любая из сторон может использовать данный трафик как доказательство жизнеспособности противоположной стороны, и обоим участникам не следует инициировать DPD-обмен.
Участник хранит состояние данного DPD-обмена. Этого означает, что после того, как был послан R-U-THERE запрос, он ожидает получить ACK в ответе в течение определенного времени. Если не получен ACK, то переда-ется повторный запрос. После определенного количества повторных передач считается, что противоположная сторона не отвечает, и удаляются IPSec и IKE SA с противоположной стороной.
Возможные реализации
Так как жизнеспособность противоположной стороны запрашивается только тогда, когда отсутствует трафик, производители могут начинать отслеживать состояние только при отсутствии трафика. В этом случае жизнеспособность противоположной стороны важна только в том случае, если требуется посылать исходящий трафик. Чтобы сделать это, можно иниции-ровать DPD-обмен (т.е. послать R-U-THERE сообщение), если есть определенный период простоя, после которого требуется послать исходящий трафик. Кроме того, DPD-обмен может инициироваться, если был послан исходящий IPSec-трафик, но в ответ не были получены входящие IPSec-пакеты. Полный DPD-обмен (т.е. передать R-U-THERE и получить соответствующий R-U-THERE-ACK) служит доказательством жизнеспособности до тех пор, пока не начнется следующий период простоя.
Также, так как в DPD нет никакого обязательного интервала, этот "период простоя" (или "метрика волнения") зависит от реализации. Переговоры об этом значении, как правило, не ведутся.
Сравнение протокола DPD со схемами keepalive и heartbeat
Выигрыш в производительности, который дает DPD по сравнению с традиционными схемами keepalive и heartbeat, получается из-за того, что нет необходимости регулярно посылать сообщения. Реализация схемы keepalive требует одного таймера для сигнализации, когда следует посылать HELLO-сообщение, и одного таймера для отслеживания таймаута ACK от противоположной стороны, который также может являться таймером повторной передачи. В схеме heartbeat необходимо иметь один таймер для сигнализации о том, что следует ожидать HELLO от противоположной стороны. В отличие от этих схем, в схеме DPD необходимо хранить отметку времени, когда был получен последний трафик от противоположной стороны (что является началом "периода простоя"). После того, как было посла-но DPD R-U-THERE сообщение, необходимо иметь таймер, который будет сигнализировать о необходимости повторной передачи. Таким образом, уменьшается необходимость в поддержке состояния таймера, в результате чего улучшается масштабируемость. (Предполагается, что поддерживать отметку времени проще, чем таймер.)
Более того, так как DPD-обмен возникает только тогда, когда не получен трафик от противоположной стороны, количество IKE-сообщений, которые должны быть посланы и обработаны, уменьшается. Как следствие, масшабируемость DPD гораздо лучше, чем при использовании keepalive и heartbeat.
DPD поддерживает модель HELLO/ACK, существующую в keepalive, при этом обмен инициируется только тогда, когда участнику важна жизнеспособность противоположной стороны.
Защита от replay-атак и фальшивого доказательства жизнеспособности
1. Последовательный номер в DPD-сообщениях
Для защиты от replay-атак и фальшивого доказательства жизнеспособности в каждом R-U-THERE сообщении используется 32-битный последовательный номер. Получатель R-U-THERE сообщения должен послать R-U-THERE-ACK с тем же самым номером. При получении R-U-THERE-ACK сообщения проверяется правильность полученного последовательного номера.
Кроме того, отправители и R-U-THERE сообщения, иR-U-THERE-ACK сообщения проверяют корректность Cookies Инициатора и Получателя, которые указаны в поле SPI.
2. Выбор и поддержка последовательных номеров
Оба DPD-участника могут инициировать DPD-обмен, т.е. оба участника могут послать R-U-THERE сообщение. При этом каждый участник под-держивает свой собственный последовательный номер для R-U-THERE сообщений. Первое R-U-THERE сообщение, посланное в течение данной сессии, имеет случайно выбранный номер. Для предотвращения переполнения 32-битного значения старший бит установлен в ноль. В следующих R-U-THERE сообщениях последовательный номер возрастает на единицу. Последовательные номера могут быть выбраны заново при истечении IKE SA. Каждый участник также хранит последовательный номер R-U-THERE сообщения противоположной стороны.
Как правило, поддерживается окно принимаемых последовательных номеров.
Обсуждение безопасности
Как уже говорилось, DPD использует последовательные номера для проверки жизнеспособности. Рассмотрим преимущества использования последовательных номеров по сравнению со случайными числами.
Хотя использование последовательных номеров требует поддержки состояния противоположной стороны, они также обеспечивают дополнительный способ защиты от некоторых replay-атак. Рассмотрим случай, когда участник А посылает участнику В действительное DPD R-U-THERE сообщение. Атакующий С может перехватить данное сообщение и послать несколько его копий. В расшифрует и обработает каждый пакет (не зависимо от того, используются ли последовательные номера или nonces). При использовании последовательных номеров В может определить, что пакеты являются повторами, так как их последовательные номера не возрастают. В этом случае В не будет создавать, шифровать и отправлять ACK. Если же используются nonces, то для предотвращения replay-атак В должен поддерживать список недавно полученных nonces.
Использование IPSec имеет высокую вычислительную нагрузку на хостах и шлюзах безопасности, которые реализуют эти протоколы. Это связано с памятью, необходимой для хранения структур данных IPSec, вычисление значений проверки целостности, шифрование и расшифрование. Использование протоколов управления SA/ ключом, особенно тех, которые реализуют криптографию с открытым ключом, также добавляет соответствующую вычислительную нагрузку при использовании IPSec.
Использование IPSec также увеличивает стоимость компонентов, осуществляющих пересылку и маршрутизацию, но не использующих IPSec. Это происходит из-за возрастания размера пакета в результате добавления заголовков АН и/или ESP, АН и ESP туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве случаев это возрастание не будет сильно влиять на производительность. Тем не менее, иногда такое влияние может быть большим, например, передача зашифрованного трафика по низкоскоростным каналам.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.