IPSec: защита сетевого уровня

Средства построения VPN, рассмотренные в наших последних обзорах (см. «Сети», 1999, № 11, с. 84 и материал «Защищая последнюю милю» в этом номере), по большей части работают на третьем, сетевом, уровне модели OSI. Для аутентификации участников обмена, шифрования IP-пакетов и туннелирования трафика большинство производителей используют стек протоколов IPSec, который в своем сегодняшнем виде был одобрен консорциумом IETF в ноябре 1998 г. В статье дано краткое описание архитектуры IPSec и предусмотренных ею процедур защиты сетевого трафика.

Широкое проникновение протокола IP в сети различного масштаба неслучайно. Гибкость, эффективность и способность выступать в роли коммуникационного «мостика» между платформами разных типов обеспечили ему заслуженную популярность. Однако повсеместное распространение этого протокола обнажило и его слабые стороны. Создавая свое детище, архитекторы IP не видели причин особенно беспокоиться о защите сетей, строящихся на его основе. Они и не думали, что когда-нибудь отсутствие эффективных средств защиты станет основным фактором, сдерживающим применение IP.

Обнаружившийся изъян первоначально предполагалось восполнить в шестой версии протокола. В 1993 г. в составе консорциума IETF была создана рабочая группа IP Security Working Group, занявшаяся разработкой архитектуры и протоколов для шифрования данных, передаваемых по сетям IPv6. Однако по мере продвижения в этом направлении становилось все очевиднее, что разработки, изначально ориентированные на IP шестой версии, могут пригодиться и в более традиционной среде IPv4. В результате на свет появился набор протоколов IPSec, основанных на современных технологиях электронной цифровой подписи и шифрования данных.

Универсальный подход

Проблема защиты данных, передаваемых по глобальным IP-сетям, возникла не вчера. Первые средства защиты появились практически сразу после того, как уязвимость IP-сетей дала о себе знать на практике. Характерными примерами разработок в этой области могут служить PGP/Web-of-Trust для шифрования сообщений электронной почты, Secure Sockets Layer (SSL) для защиты Web-трафика, Secure SHell (SSH) для защиты сеансов telnet и процедур передачи файлов.

Общим недостатком подобных широко распространенных решений является их «привязанность» к определенному типу приложений, а значит, неспособность удовлетворить тем разнообразным требованиям к системам сетевой защиты, которые предъявляют крупные корпорации или Internet-провайдеры. Самый радикальный способ преодолеть указанное ограничение сводится к тому, чтобы строить систему защиты не для отдельных классов приложений (пусть и весьма популярных), а для сети в целом. Применительно к IP-сетям это означает, что системы защиты должны действовать на сетевом уровне модели OSI.

Преимущество такого выбора заключается в том очевидном факте, что в IP-сетях именно данный уровень отличается наибольшей гомогенностью: независимо от вышележащих протоколов, физической среды передачи и технологии канального уровня транспортировка данных по сети не может быть произведена в обход протокола IP. Поэтому реализация защиты сети на третьем уровне автоматически гарантирует как минимум такую же степень защиты всех сетевых приложений, причем без какой-либо модификации последних. Для пользователей процедуры защиты окажутся столь же прозрачными, как и сам протокол IP. Раз архитектура IPSec совместима с протоколом IPv4, ее поддержку достаточно обеспечить на обоих концах соединения; промежуточные сетевые узлы могут вообще ничего «не знать» об IPSec.

Опасности на каждом шагу

На практике IP-сети уязвимы для нескольких способов несанкционированного вторжения в процесс обмена данными. По мере развития компьютерных и сетевых технологий (например, с появлением мобильных Java-приложений и элементов ActiveX) список возможных типов сетевых атак на IP-сети постоянно расширяется. На сегодняшний день наиболее распространенными являются следующие варианты:

• подмена IP-адреса отправителя другим адресом (IP spoofing);
• перехват сеанса (session hijacking), для чего по окончании начальной процедуры аутентификации установленное соединение, скажем, с почтовым сервером переключается на новый хост-компьютер, а исходному серверу выдается команда разорвать соединение. В результате ваш «собеседник» оказывается незаметно подмененным;
• перехват пароля, передаваемого по сети в незашифрованной форме, путем «прослушивания» канала (password sniffing);
• посредничество в обмене незашифрованными ключами (man-in-the-middle). Если атаки трех предыдущих типов увенчались успехом, их автор может вмешаться в процесс передачи ключей между сторонами и подсунуть им собственный ключ для дальнейшего использования.

Нетрудно видеть, что перечисленные сетевые атаки возможны в силу ряда причин. Во-первых, аутентификация отправителя осуществляется исключительно по его IP-адресу. Во-вторых, процедура аутентификации выполняется только на стадии установления соединения, а в дальнейшем подлинность принимаемых пакетов не проверяется. Наконец, важнейшие данные, имеющие отношение к системе защиты, передаются по сети в незашифрованном виде.

Устранить эти слабые места и призваны процедуры, регламентируемые протоколами IPSec.

Действующие лица и элементы архитектуры

Пользователь воспринимает сеть как надежно защищенную среду только в том случае, если он уверен, что его «собеседник» — именно тот, за кого он себя выдает (аутентификация сторон), что передаваемые пакеты не просматриваются посторонними лицами (конфиденциальность связи) и что получаемые данные не подверглись изменению в процессе передачи (целостность данных). Чтобы достичь соответствия перечисленным критериям, разработчики IPSec предлагают воспользоваться тремя инструментальными средствами защиты:

• протоколом аутентификации (Authentication Header, AH), который «привязывает» данные в составе пакета к своеобразной подписи, позволяющей удостовериться как в подлинности отправителя, так и в целостности принятых от него данных;
• протоколом Encapsulated Security Payload (ESP), отвечающим за шифрование содержимого отдельных пакетов (и даже некоторых IP-адресов, передаваемых в их составе);
• протоколами обмена ключами (Internet Key Exchange, IKE), которые предназначены для согласования используемых алгоритмов аутентификации и шифрования, ключей и продолжительности их действия, а также для защищенного обмена ключами.

Программное обеспечение перечисленных протоколов (утилиты шифрования, цифровой подписи и пр.) может функционировать на серверах или компьютерах конечных пользователей. Однако чаще его устанавливают на маршрутизаторах или специальных устройствах — брандмауэрах, которые в архитектуре IPSec именуются шлюзами безопасности (security gateway). В соответствии с этим различают два режима использования протоколов IPSec — транспортный и туннельный. В транспортном режиме зашифрованные данные транспортируются непосредственно между хост-компьютерами, но защита распространяется только на пакеты четвертого и вышележащих уровней.

В туннельном режиме ситуация выглядит несколько сложнее. Основная роль здесь отводится шлюзам безопасности, поскольку предполагается, что клиентские станции (или серверы) не поддерживают IPSec и отправляют в сеть обычный IP-трафик. Однако перед тем как достичь каналов глобальной сети, каждый IP-пакет сначала попадает в шлюз, который помещает этот пакет целиком в «оболочку» IPSec, зашифровывая его содержимое вместе с исходным IP-заголовком. Чтобы обеспечить возможность маршрутизации получившегося пакета, шлюз снабжает его новым IP-заголовком и только после этого отправляет в сеть. Шлюз, находящийся на противоположном конце соединения, дешифрует пакет и передает его на оконечное устройство в первоначальном виде. Описанная процедура и называется туннелированием. Она позволяет распространить действие средств защиты на сетевой уровень модели OSI, в частности скрыть истинные IP-адреса источника и получателя для уменьшения риска атак, основанных на детальном анализе трафика. Менее очевидная задача туннелирования — транспортировка через общедоступную сеть некорректных IP-адресов, которые в явном виде не были бы ею восприняты.

Слагаемые защиты

Шифрование. Протокол ESP допускает применение практически любого симметричного алгоритма для шифрования отдельных пакетов. Более того, в одном приложении можно использовать разные методы шифрования в разных соединениях. Вместе с тем для специальных целей, например обмена ключами, предназначенными для последующего шифрования передаваемых пакетов, служат асимметричные алгоритмы. По умолчанию в качестве алгоритма шифрования стандартом предусмотрен симметричный метод DES-CBC (Cipher Block Chaining) с 56-разрядным ключом.

Рис.1 Местоположение заголовка ESP в пакете данных (а) и его структура (б)

Заголовок ESP помещается в передаваемый пакет между заголовками протоколов четвертого (например, TCP) и третьего (IP) уровней (рис. 1,а). Пакет уровня ESP включает шесть полей (рис. 1,б), из которых зашифровываются только четыре последних:

• индекс параметра защиты (Security Parameter Index, SPI) — 32-разрядное число, уведомляющее получателя о том, какую группу протоколов и алгоритмов защиты использует отправитель;
• номер в последовательности — счетчик количества отправленных пакетов с данным SPI; обеспечивает защиту от ретрансляционных атак (когда хакер посылает копию пакета с нарушением порядка следования);
• собственно данные;
• заполнитель — поле переменного размера (0—255 байт), маскирующее истинную длину передаваемых данных;
• длина предыдущего поля;
• новый заголовок — поле, аналогичное полю Next в заголовке IP-пакета и указывающее тип передаваемых данных и используемый протокол. В случае применения протокола IPv6 в этом месте могут располагаться некоторые дополнительные поля заголовка.

Заметим, что поля протокола ESP следуют после стандартного IP-заголовка, а это означает, что такой пакет может маршрутизироваться в сети с помощью обычного оборудования, поддерживающего IP.

Туннелирование. Этот тип сервиса VPN также обеспечивается средствами ESP. Туннелирование заключается в помещении первоначального IP-пакета внутрь пакета ESP и в последующем добавлении нового IP-заголовка, содержащего адрес шлюза.

Аутентификация. Функциями шифрования и туннелирования назначение протокола ESP не ограничивается. Поле аутентификации, которое может присутствовать в его заголовке, содержит параметр проверки целостности пакета (Integrity Check Value, ICV), позволяющий реализовать симметричную схему аутентификации. По сути, он представляет собой цифровую подпись, помещаемую в поле аутентификации и позволяющую отправителю подписать результат предварительного хеширования содержательной части пакета ESP (если отправитель не хеширует ее самостоятельно). Анализ содержимого этого поля дает возможность получателю идентифицировать источник данных и убедиться в том, что они не были изменены в процессе передачи.

В текущей версии стандарта IPSec в качестве обязательной симметричной схемы использования цифровой подписи выбрана HMAC и функции хеширования SHA-1 и MD5 с применением ключей.

Если для протокола ESP функции аутентификации являются факультативными, то основное действующее лицо в этой области — протокол AH. В IP-сети он может использоваться самостоятельно, совместно с ESP или в виде «вложенного» сервиса (при условии выбора режима туннелирования).

Возможности AH в плане аутентификации отличаются от таковых для протокола ESP прежде всего тем, что последний не обеспечивает защиту внешнего IP-заголовка, который предшествует заголовку ESP. Впрочем, и протокол AH защищает этот заголовок не полностью, поскольку часть его полей изменяется в процессе передвижения пакета по сети и такие изменения отправитель не может предсказать заранее.

Информация, добавляемая в пакет протоколом AH, помещается после IP-заголовка, но перед заголовком ESP (если таковой присутствует) и заголовками протоколов вышележащих уровней типа TCP. В пакетах IPv6 она располагается за дополнительными заголовками (extension headers), которые не были предусмотрены в четвертой версии IP и используются при маршрутизации и фрагментации пакетов.

Рис.2 Заголовок Authentication Header (AH)

Заголовок AH включает в себя пять полей (рис. 2):

• следующий заголовок — поле, указывающее тот протокол (например, ESP или TCP), чей заголовок следует за AH;
• длина заголовка — восьмиразрядное поле со значением, равным длине заголовка AH в четырехбайтных словах минус два слова (для совместимости с более ранней спецификацией AH);
• зарезервированное поле, устанавливаемое в нулевое значение;
• индекс параметра защиты (SPI). Это и следующее поле полностью аналогичны одноименным полям в заголовке ESP;
• данные аутентификации — поле, содержащее цифровую подпись ICV и, возможно, заполнитель для выравнивания длины заголовка до целого значения, кратного 32 (IPv4) или 64 (IPv6) битам.

Подобно ESP, протокол AH может применяться для туннелирования пакетов.

В целях достижения базовой совместимости различных реализаций процедур аутентификации стандартом IPSec предусмотрено использование в рамках AH тех же схем цифровой подписи и хеширования, что и в протоколе ESP.

Согласование протоколов и управление ключами

Протоколы ESP и AH позволяют сделать реальностью важнейшие атрибуты защищенной передачи — конфиденциальность связи, аутентификацию сторон и целостность данных. Между тем очевидно, что их функции потеряют всякую ценность в отсутствие мощной поддерживающей инфраструктуры, которая обеспечивала бы распределение ключей и согласование протоколов между участниками обмена.

Роль такой инфраструктуры в IPSec выполняет группа протоколов Internet Key Exchange (IKE). Это название в 1998 г. пришло на смену более раннему — ISAKMP/Oakley, которое непосредственно указывало на происхождение средств управления ключами в составе IPSec. Протокол Internet Security Association and Key Management Protocol (ISAKMP), описанный в документе RFC 2408, был разработан в 1997 г. в Управлении национальной безопасности США. Он позволяет согласовать алгоритмы и математические структуры (так называемые мультипликативные группы, определенные на конечном поле) для процедуры обмена ключами Диффи — Хеллмана (см. ниже), а также процессов аутентификации. Протокол Oakley (RFC 2412) был предложен в том же году сотрудниками Университета штата Аризона и служит для непосредственного обмена ключами.

Протоколы IKE решают три задачи: согласовывают алгоритмы шифрования и характеристики ключей, которые будут использоваться в защищенном сеансе; обеспечивают непосредственный обмен ключами (в том числе возможность их частой смены); наконец, контролируют выполнение всех достигнутых соглашений.

Исторически разработчики IPSec начали свою деятельность с решения последней задачи. В результате на свет появилась концепция выделенных защищенных виртуальных «каналов» (или «соединений») и соответствующих им структур данных, в английском языке получивших не вполне адекватное название Security Association (SA). Именно в рамках SA определяются алгоритм аутентификации протокола AH и его ключи, алгоритм шифрования, используемый протоколом ESP, и его ключи, наличие или отсутствие криптографической синхронизации, способы аутентификации партнеров и защиты сеанса обмена, частота смены ключей и ряд других параметров. Объединение столь обширной служебной информации в рамках SA предоставляет пользователю возможность сформировать разные классы защиты, предназначенные, например, для электронного общения с разными «собеседниками». Другими словами, применение структур SA открывает путь к построению множества виртуальных частных сетей, различающихся своими параметрами.

«Канал» SA полностью определяется тремя величинами: уже упоминавшимся 32-разрядным индексом SPI, IP-адресом узла назначения и идентификатором протокола защиты (AH или ESP). Узел-получатель выбирает значение индекса SPI из числа не используемых в данный момент (и желательно не фигурировавших ранее) и сообщает его отправителю. Если тот соглашается на предложенное значение индекса, данный SPI становится идентификатором «канала» SA между двумя сторонами и именно по нему в дальнейшем будут выбираться служебные данные, необходимые для защиты информационного обмена между участниками сеанса.

В целях работы с параметрами SA на каждой стороне создается база данных таких «каналов» (Security Association Database). Каждому согласованному «каналу» в ней соответствует отдельная запись.

Что касается способов использования протоколов IPSec отдельными приложениями, то они определяются в записях базы данных, содержащей наборы правил, или стратегии, информационной безопасности (Security Policy Database). Такая БД формируется и поддерживается на каждом узле, где установлено программное обеспечение IPSec. Выбирая ту или иную запись из этой БД, приложение определяет способ защиты генерируемых IP-пакетов, который затем реализуется в рамках согласованного «канала» SA.

Генерация ключей. Использование ключей направлено на уменьшение риска перехвата передаваемых данных. Понятно, что операция обмена зашифрованными ключами, предшествующая обмену собственно данными, также может стать объектом сетевой атаки. Вероятность перехвата и, главное, успешной расшифровки ключей, очевидно, падает с ростом их длины. В то же время чрезмерное увеличение размера ключей способно негативно сказаться на общей производительности процедур обмена.

Компромиссное решение могло бы состоять в частой смене ключей, имеющих умеренную длину. Однако здесь возникает еще одна проблема. Необходимо, чтобы вновь сгенерированный ключ был воспринят другой стороной, тогда как его генерация никак не должна базироваться на предыдущих ключах либо на тех числовых массивах, по которым они генерировались. Обойти эту трудность помогает комбинационный алгоритм Диффи — Хеллмана (Diffie—Hellman), взятый на вооружение создателями IPSec.

Процедура обмена ключами выглядит следующим образом. Стороны направляют друг другу записи cookies, в дальнейшем позволяющие предотвратить атаку типа перегрузки ресурсов (когда атакующий пытается создать избыточную нагрузку на вычислительные ресурсы своей жертвы, например инициируя сразу несколько сеансов обмена ключами по алгоритму Диффи — Хеллмана). Затем каждая из сторон независимо от другой случайным образом генерирует пару значений, являющихся аналогами открытого и секретного ключей. Сгенерированные открытые ключи стороны передают друг другу через сеть, после чего каждая сторона комбинирует принятый открытый ключ с собственным секретным, используя алгоритм Диффи — Хеллмана. Не вдаваясь в математические детали, отметим, что основная изюминка данного алгоритма состоит в том, что в результате указанной процедуры обе стороны получат один и тот же комбинированный ключ. Другими словами, этот алгоритм дает возможность перейти от традиционных асимметричных процедур шифрования на основе пары ключей к симметричной схеме с применением комбинированного ключа, которая характеризуется большей производительностью. Комбинированный ключ можно использовать при последующих обменах данными либо для шифрования новых ключей, сгенерированных независимо от предыдущих.

Алгоритм Диффи — Хеллмана, очевидно, имеет смысл применять только в сочетании с процедурой аутентификации сторон с целью предотвратить атаку типа посредничества при обмене незашифрованными ключами. Такая аутентификация обычно производится сразу после обмена открытыми ключами с использованием цифровых подписей.

Режимы функционирования. Структура SA активно используется протоколами IKE, функционирующими в два этапа. На первом оба IKE-узла (в их роли выступают настольные компьютеры, поддерживающие IPSec или шлюзы безопасности) устанавливают защищенное «соединение» для процедуры обмена (IKE SA). На втором этапе по этому «каналу» осуществляется согласование всех параметров, ассоциируемых с общим «каналом» SA.

Перед тем как установить «канал» IKE SA, инициирующая сторона должна предложить для согласования шесть пунктов: алгоритмы шифрования, алгоритмы хеширования, метод аутентификации, информацию о группе узлов, на которые будет распространяться алгоритм Диффи — Хеллмана, псевдослучайную функцию, с помощью которой предстоит хешировать величины, используемые при обмене ключами (впрочем, допускается непосредственное использование алгоритма хеширования), и тип протокола защиты (ESP или AH).

Схемой Oakley предусмотрены три режима обмена информацией об алгоритмах и параметрах защиты и установления «канала» SA. Два из них (основной и агрессивный) относятся к первой фазе функционирования протоколов IKE и один (быстрый) — ко второй.

Основной режим (Main mode) реализует стандартный механизм установления «канала» IKE SA. Он включает в себя три процедуры двунаправленного обмена (рис. 3,а). Сначала стороны договариваются о базовых алгоритмах и используемых методах хеширования. Затем осуществляется обмен открытыми ключами в рамках алгоритма Диффи — Хеллмана и случайными числами (nonce), которые подписываются принимающими сторонами и отправляются обратно для идентификации. Наконец, в ходе третьего обмена по пришедшим обратно подписанным значениям nonce проверяется подлинность сторон.

Процедуры обмена IKE в основном (а) и агрессивном (б) режимах. Cert - сертификат, ID - идентификатор, Key - данные, используемые при обмене ключами, Nonce - случайное число, SA - предлагаемые параметры SA, Sig - цифровая подпись, [] - необязательное поле

Открытый ключ, полученный по схеме Диффи — Хеллмана, каждой из сторон хешируется трижды — для генерации первого комбинированного ключа, ключа аутентификации и ключа шифрования, используемого в IKE SA.

Агрессивный режим (Aggressive mode) предназначен для тех же целей, что и основной, однако он проще в реализации и одновременно производительнее. Плата за эти преимущества заключается в том, что агрессивный режим не обеспечивает защиту информации, служащей для идентификации сторон, поскольку такая информация передается по сети до согласования параметров защищенного «канала» SA, т. е. в незашифрованном виде.

Данный режим требует только двух операций обмена, а количество передаваемых по сети пакетов удается уменьшить с шести до трех (рис. 3,б). Инициатор обмена старается включить в первый же пакет максимум требуемой от него информации: предлагаемый идентификатор SA, открытый ключ алгоритма Диффи — Хеллмана, значение nonce для подписи другой стороной и даже пакет с собственным идентификатором, позволяющим противоположной стороне «опознать» своего собеседника. Получатель в ответ также отправляет все те параметры, которые необходимы для завершения первой фазы IKE и в основном режиме разбились бы по трем пакетам. В результате инициатору остается только отправить уведомление о том, что обмен успешно произведен.

Быстрый режим (Quick mode) обеспечивает согласование параметров основного «канала» SA и генерацию новых ключей. Поскольку в быстром режиме все передачи осуществляются по защищенному туннельному соединению, в реализации он проще двух предыдущих. Пакет, передаваемый в данном режиме, обязательно начинается с хеша, который содержит ключ аутентификации, полученный в основном режиме для IKE SA, и служит для аутентификации остальной части пакета. Один цикл в быстром режиме включает в себя передачу трех пакетов и во многом аналогичен процедуре обмена, реализуемой в агрессивном режиме.

Если при генерации новых ключей необходимо обеспечить их полную независимость от предыдущих, по установленному «каналу» SA осуществляется дополнительный обмен в соответствии с алгоритмом Диффи — Хеллмана. Однако в том случае, когда указанное требование не является таким жестким, уже существующие ключи можно обновить с помощью дополнительного хеширования, обменявшись случайными числами nonce по защищенному соединению.

Согласование параметров SA. После процедур обмена, описанных выше, установление основного «канала» SA представляет собой сравнительно простую задачу. Сторона, заинтересованная в установлении нового SA, направляет своему партнеру сообщение-запрос быстрого режима, которое должно содержать предлагаемый индекс SPI и защищено средствами IKE SA. Получатель отвечает на запрос собственным индексом SPI. Каждый из индексов, в соответствии с IP-адресом получателя и протоколом защиты, определяет отдельный «канал» SA. Другими словами, одна процедура согласования завершается формированием двух каналов, один из которых для данной стороны является входящим, а другой — исходящим. Все параметры этих двух каналов (кроме идентификаторов SPI) полностью идентичны.

Такая пара «каналов» SA устанавливается для каждого протокола защиты. Поэтому если для целей аутентификации используются два протокола (AH и ESP), каждому из них будут соответствовать два «канала». Более того, даже в рамках одного протокола между двумя фиксированными узлами можно сформировать множество «каналов» SA. Все определяется тем, ориентированы ли эти «каналы» на использование хост-компьютером в целом, индивидуальными пользователями или предназначены для отдельных коммуникационных сеансов.

Первичная идентификация сторон. В описанных выше процедурах установления «канала» IKE SA и последующего согласования алгоритмов и параметров защищенного обмена есть одно «но»: все они оправданны лишь в том случае, если у каждой из сторон имеется полная уверенность в том, что ее партнер — именно тот, за кого он себя выдает.

При осуществлении первичной идентификации не обойтись без привлечения третьего участника; в архитектуре IPSec он именуется органом сертификации (Certification Authority, CA). Этот орган призван засвидетельствовать подлинность обеих сторон и, очевидно, должен пользоваться их полным доверием. Для подтверждения подлинности служат цифровые сертификаты, включающие три части: уникальный идентификатор, позволяющий однозначно опознать участника будущего обмена, открытый ключ, используемый при подписании электронных документов, и открытый ключ CA, дающий возможность подписать, а затем идентифицировать весь сертификат.

Привлечение органа сертификации позволяет предотвратить атаки, сводящиеся к посредничеству при обмене ключами. Сторона, обмен с которой вы пытаетесь инициировать, обязана подписать свой ответ электронной подписью, и эту подпись можно проверить в CA. Аналогичным образом на следующем этапе проверяется подпись на сертификате — она должна совпадать с подписью, поставленной CA.

Может показаться, что общение через сеть с органом сертификации также не гарантирует того, что подпись CA в процессе передачи не будет заменена на другую. Риск подобной посреднической атаки удается минимизировать благодаря распространению подписи CA. Активная работа с органом сертификации множества компаний означает, что открытый ключ CA должен храниться в нескольких местах, так что подмена сразу же обнаружится. Кроме того, для шифрования подписи CA имеет смысл использовать сложные алгоритмы и очень длинные редко обновляемые ключи. Последнее обстоятельство позволяет распространять ключи на электронных носителях, например с тем же ПО, которое примменяется для идентификации подписи CA. В спецификациях IPSec для сертификатов IKE выбран стандартный формат X.509.

*  *  *

Составные части архитектуры IPSec в своем нынешнем виде (RFC 2401—2411 и RFC 2451) получили статус предварительного стандарта IETF (IETF Proposed Standard) в позапрошлом году. Определив общую архитектуру системы защиты данных в IP-сетях, члены IPSec Working Group не сочли свое детище абсолютным совершенством и продолжают над ним работать. Так, еще в середине 1998 г. на чикагском заседании IETF был образован комитет IPSecond, сосредоточивший свои усилия на стандартизации средств поддержки удаленных клиентов IPSec, использующих протоколы Mobile IP и DHCP, и методов обнаружения оконечных устройств или шлюзов, с которыми установлены туннельные соединения, на внедрении в среду IPSec управления на базе правил, на вопросах поддержки разных уровней качества сервиса (QoS) и на проработке возможности использования IPSec в тех сетях, где не применяется IP.

В рамках IETF сегодня действует еще одна группа, разрабатывающая спецификации для процедур сжатия отдельных полей в передаваемом пакете. Несмотря на то что процессы сжатия и шифрования данных тесно взаимосвязаны, в первом варианте стандарта (RFC 1827, август 1995 г.) протокол ESP не поддерживал сжатие данных. В результате при выполнении шифрования на уровне IP получившийся пакет уже не мог быть подвергнут сжатию протоколами более низких уровней. Возможно, упомянутая рабочая группа предложит технологию сжатия пакетов протоколами транспортного и вышележащих уровней или алгоритмы сжатия непосредственно на уровне IP.

Этим перечнем, к сожалению, сегодня не исчерпывается круг проблем, которые возникают на стадии практического применения IPSec. В их числе можно упомянуть еще согласование средств защиты с процедурами преобразования адресов (NAT) и обеспечение более органичной поддержки многоадресного IP-трафика. Однако широкая распространенность протокола IP и обязательность использования средств защиты IPSec в сетях IPv6 позволяют надеяться, что в следующих версиях стандарта оставшиеся «белые пятна» обретут ясно различимые цветовые оттенки.

Так ли уж хороша защита на сетевом уровне?

Туннелирование средствами IPSec и PPTP