Использование NAT в протоколе IPSec
Протокол DPD
DPD позволяет ликвидировать недостатки схем keepalive и heartbeat введением определенной логики управления обменом сообщений. В частности, keepalive и heartbeat должны обязательно обмениваться HELLO через определенные интервалы времени. В отличие от этого при использовании DPD каждый участник в большей степени не зависит от другого. Участник может запрашивать доказательство жизнеспособности в тот момент, когда это ему необходимо, а не через фиксированный интервал времени. Такая асинхронность 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 следующий:
Где
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-сообщением. Обмен определен следующим образом:
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 имеет следующий формат:
Так как данное сообщение является IKE NOTIFY, то поля Next Payload, RESERVED и Payload Length должны быть установлены в соответствии с требованиями протокола IKE. Остальные поля установлены следующим образом:
- DOI – IPSEC-DOI.
- Protocol ID – должно быть установлено в ID протокола для IKE.
- SPI Size – установлено в 16, длина двух IKE Cookies.
- Тип Notify-сообщения должен быть R-U-THERE
- SPI установлен в 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-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве случаев это возрастание не будет сильно влиять на производительность. Тем не менее, иногда такое влияние может быть большим, например, передача зашифрованного трафика по низкоскоростным каналам.