2.6. Cookie
Термин cookies, введенный Karn и Simpson [RFC2522] в Photuris — раннем варианте системы управления ключами IPsec, продолжает использоваться до настоящего времени. Фиксированный заголовок протокола управления ключами и защищенными связями Internet (ISAKMP) [MSST98] включает два восьмиоктетных поля cookies и этот синтаксис используется в IKEv1 и IKEv2, хотя в последнем эти поля обозначаются, как IKE SPI, и имеется новое отдельное поле в элементе Notify, которое сохраняет значение cookie.
Изначально два восьмиоктетных поля в заголовке использовались в качестве идентификаторов соединений в начальных пакетах IKE. Каждая из конечных точек выбирает одно или два значения SPI, которые следует выбирать так, чтобы они однозначно идентифицировали IKE_SA. Нулевое значение SPI является специальным и показывает, что удаленное значение SPI отправителю еще не известно.
В отличие от ESP и AH, где только значение SPI для получателя появляется в заголовке пакета, в IKE каждое сообщение содержит также SPI отправителя. Поскольку значение SPI, выбранное исходным инициатором IKE_SA, всегда передается первым, конечная точка со множеством открытых IKE_SA, которая хочет найти подходящую IKE_SA по выбранному для нее значению SPI, должна просматривать значение флага I (инициатор) в заголовке для определения где искать — в первой или второй группе из 8 октетов.
В первом сообщении начального обмена IKE инициатор не знает значение SPI отвечающей стороны и будет, следовательно, помещать в это поле нулевое значение.
Возможной атакой на IKE является истощение ресурсов на хранение состояний и ресурсов CPU, когда объект атаки в лавинном режиме получает запросы на организацию сессий с подставных адресов IP. Воздействие таких атак можно снизить, если реализация отвечающей стороны по минимуму использует CPU и не фиксирует состояния SA до того, как узнает, что инициатор может получать пакеты по адресу, указанному в запросе. Для решения этой задачи ответчику следует при обнаружении большого числа полуоткрытых IKE_SA отвергать стартовые сообщения IKE, если они не содержат элемента Notify типа COOKIE. Взамен ответчику следует передавать в качестве отклика незащищенное сообщение IKE и включать в него COOKIE Notify с данными cookie для возврата. Инициатор, получивший такой отклик, должен повторить IKE_SA_INIT с элементом Notify типа COOKIE, содержащим предложенные ответчиком данные cookie в качестве первого элемента, сохраняя остальные элементы данных. Начальный обмен в таком случае будет иметь вид:
Инициатор Ответчик
----------- ----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
Два первых сообщения не оказывают влияния на состояние инициатора и ответчика за исключением обмена cookie. В частности, порядковые номера в четырех первых сообщениях будут иметь нулевые значения, а в двух последних сообщениях приведенного примера номера будут иметь значение 1. «A» обозначает значение SPI, присвоенное инициатором, а «B» — значение, присвоенное ответчиком.
Реализации IKE следует поддерживать генерацию cookie ответчиком так, чтобы не требовалось сохранять какое-либо состояние для проверки корректности cookie при получении второго сообщения IKE_SA_INIT. Выбор алгоритма и используемый для cookie синтаксис не оказывают влияния на интероперабельность, поэтому не задаются данной спецификацией. Ниже приведен пример использования cookie конечной точкой для частичной защиты от DoS-атак. Хорошим способом реализации такой защиты является установка ответчиком cookie по следующему алгоритму:
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
где <secret> — случайное значение, известное только ответчику и периодически сменяемое, | указывает конкатенацию. Значение <VersionIDofSecret> следует менять всякий раз при смене <secret>. Значение cookie может быть рассчитано заново при получении IKE_SA_INIT второй раз и полученное значение сравнивается со значением cookie в принятом сообщении. Если значения совпадают, ответчик знает, что значение cookie было создано после замены <secret> и значение IPi должно совпадать с адресом отправителя, полученным в первом сообщении. Включение SPIi в расчет обеспечивает создание различных значений cookie для случаев, когда множество IKE_SA создается одновременно (предполагается, что инициаторы устанавливают уникальные значения SPIi). Включение в хэш значения Ni не позволяет атакующему, который увидел только сообщение 2, корректно подменить сообщение 3.
Если значение <secret> меняется в процессе инициализации соединения, сообщение IKE_SA_INIT может быть возвращено с отличным от текущего значением <VersionIDofSecret>. Ответчик в таком случае может отвергнуть сообщение, передавая другой отклик с новым значением cookie, или может сохранять старое значение <secret> на короткое время после его замены и принимать cookie, рассчитанные с использованием этого значения. Ответчику не следует воспринимать cookie неограниченно долго после смены <secret>, поскольку это будет нарушать часть защиты от DoS-атак. Ответчику следует менять значение <secret> достаточно часто, особенно во время атак.