Автореферат магистерской выпускной работы
ВВЕДЕНИЕ

Широкое проникновение протокола 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.

Таким образом, если мы используем IPsec, то сможем защитить передачу данных в сети для всех приложений и для всех пользователей более прозрачно, чем при использовании любых других средств.

Активное слияние компаний и образование новых конгломератов и альянсов заставляет задуматься об организации безопасности работы в общих сетях. Как правило, появляется необходимость в обмене коммерческой или другой важной информацией и далеко не факт, что компании имеют специальный выделенный канал под эти задачи. В основном вся эта информация идет по сети общего пользования. Для решения данной проблемы можно использовать технологию защищенных виртуальных частных сетей Virtual Private Network(VPN), которая базируется на протоколе  IPSec.

1 КРАТКИЙ ОБЗОР СТЕКА ПРОТОКОЛОВ TCP/IP

1.1 История и перспективы стека TCP/IP

Transmission Control Protocol/Internet Protocol (TCP/IP) - это промышленный стандарт стека протоколов, разработанный для глобальных сетей. Стандарты TCP/IP опубликованы в серии документов, названных Request for Comment (RFC). Документы RFC описывают внутреннюю работу сети Internet. Некоторые RFC описывают сетевые сервисы или протоколы и их реализацию, в то время как другие обобщают условия применения. Стандарты TCP/IP всегда публикуются в виде документов RFC, но не все RFC определяют стандарты. Стек был разработан по инициативе Министерства обороны США (Department of Defence, DoD) более 20 лет назад для связи экспериментальной сети ARPAnet с другими сателлитными сетями как набор общих протоколов для разнородной вычислительной среды. Сеть ARPA поддерживала разработчиков и исследователей в военных областях. В сети ARPA связь между двумя компьютерами осуществлялась с использованием протокола Internet Protocol (IP), который и по сей день является одним из основных в стеке TCP/IP и фигурирует в названии стека.

Большой вклад в развитие стека TCP/IP внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Широкое распространение ОС UNIX привело и к широкому распространению протокола IP и других протоколов стека. На этом же стеке работает всемирная информационная сеть Internet, чье подразделение Internet Engineering Task Force (IETF) вносит основной вклад в совершенствование стандартов стека, публикуемых в форме спецификаций RFC.

Итак, лидирующая роль стека TCP/IP объясняется следующими его свойствами:

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

-         почти все большие сети передают основную часть своего трафика с помощью протокола TCP/IP.

-         это метод получения доступа к сети Internet.

-         этот стек служит основой для создания intranet-корпоративной сети, использующей транспортные услуги Internet и гипертекстовую технологию WWW, разработанную в Internet.

-         все современные операционные системы поддерживают стек TCP/IP.

-         это гибкая технология для соединения разнородных систем как на уровне транспортных подсистем, так и на уровне прикладных сервисов.

-         это устойчивая масштабируемая межплатформенная среда для приложений клиент-сервер.

1.2 Структура стека TCP/IP и краткая характеристика протоколов

Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.

В модели OSI, называемой также моделью взаимодействия открытых систем (Open Systems Interconnection - OSI) и разработанной Международной Организацией по Стандартам (International Organization for Standardization - ISO), средства сетевого взаимодействия делятся на семь уровней, для которых определены стандартные названия и функции.

Ниже перечислены(в направлении снизу вверх) уровни модели OSI и указаны их общие функции.

Физический уровень выполняет передачу битов по физическим каналам, таким, как коаксиальный кабель, витая пара или оптоволоконный кабель. На этом уровне определяются характеристики физических сред передачи данных и параметров электрических сигналов.

Канальный уровень обеспечивает передачу кадра данных между любыми узлами в сетях с типовой топологией либо между двумя соседними узлами в сетях с произвольной топологией. В протоколах канального уровня заложена определенная структура связей между компьютерами и способы их адресации. Адреса, используемые на канальном уровне в локальных сетях, часто называют МАС-адресами.

Сетевой уровень обеспечивает доставку данных между любыми двумя узлами в сети с произвольной топологией, при этом он не берет на себя никаких обязательств по надежности передачи данных.

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

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

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

Прикладной уровень - это в сущности набор разнообразных сетевых сервисов, предоставляемых конечным пользователям и приложениям. Примерами таких сервисов являются, например, электронная почта, передача файлов, подключение удаленных терминалов к компьютеру по сети.

 Структура протоколов TCP/IP приведена на рисунке 1.1. Протоколы TCP/IP делятся на 4 уровня.

Рисунок 1.1 – Стек TCP/IP

Самый нижний (уровень IV) соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: для локальных сетей это Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN, для глобальных сетей - протоколы соединений "точка-точка" SLIP и PPP, протоколы территориальных сетей с коммутацией пакетов X.25, Frame Relay. Разработана также специальная спецификация, определяющая использование технологии ATM в качестве транспорта канального уровня. Обычно при появлении новой технологии локальных или глобальных сетей она быстро включается в стек TCP/IP за счет разработки соответствующего RFC, определяющего метод инкапсуляции пакетов IP в ее кадры.

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

К уровню межсетевого взаимодействия относятся и все протоколы, связанные с составлением и модификацией таблиц маршрутизации, такие как протоколы сбора маршрутной информации RIP (Routing Internet Protocol) и OSPF (Open Shortest Path First), а также протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol). Последний протокол предназначен для обмена информацией об ошибках между маршрутизаторами сети и узлом - источником пакета. С помощью специальных пакетов ICMP сообщается о невозможности доставки пакета, о превышении времени жизни или продолжительности сборки пакета из фрагментов, об аномальных величинах параметров, об изменении маршрута пересылки и типа обслуживания, о состоянии системы и т.п.

Следующий уровень (уровень II) называется основным. На этом уровне функционируют протокол управления передачей TCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования виртуальных соединений. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным способом, как и IP, и выполняет только функции связующего звена между сетевым протоколом и многочисленными прикладными процессами.

Верхний уровень (уровень I) называется прикладным. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и сервисов прикладного уровня. К ним относятся такие широко используемые протоколы, как протокол копирования файлов FTP, протокол эмуляции терминала telnet, почтовый протокол SMTP, используемый в электронной почте сети Internet, гипертекстовые сервисы доступа к удаленной информации, такие как WWW и многие другие. Остановимся несколько подробнее на некоторых из них.

Протокол пересылки файлов FTP (File Transfer Protocol) реализует удаленный доступ к файлу. Для того чтобы обеспечить надежную передачу, FTP использует в качестве транспорта протокол с установлением соединений - TCP. Кроме пересылки файлов протокол FTP предлагает и другие услуги. Так, пользователю предоставляется возможность интерактивной работы с удаленной машиной, например, он может распечатать содержимое ее каталогов. Наконец, FTP выполняет аутентификацию пользователей. Прежде, чем получить доступ к файлу, в соответствии с протоколом пользователи должны сообщить свое имя и пароль. Для доступа к публичным каталогам FTP-архивов Internet парольная аутентификация не требуется, и ее обходят за счет использования для такого доступа предопределенного имени пользователя Anonymous.

В стеке TCP/IP протокол FTP предлагает наиболее широкий набор услуг для работы с файлами, однако он является и самым сложным для программирования. Приложения, которым не требуются все возможности FTP, могут использовать другой, более экономичный протокол - простейший протокол пересылки файлов TFTP (Trivial File Transfer Protocol). Этот протокол реализует только передачу файлов, причем в качестве транспорта используется более простой, чем TCP, протокол без установления соединения - UDP.

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

Протокол SNMP (Simple Network Management Protocol) используется для организации сетевого управления. Изначально протокол SNMP был разработан для удаленного контроля и управления маршрутизаторами Internet, которые традиционно часто называют также шлюзами. С ростом популярности протокол SNMP стали применять и для управления любым коммуникационным оборудованием - концентраторами, мостами, сетевыми адаптерами и т.д. и т.п. Проблема управления в протоколе SNMP разделяется на две задачи.

Первая задача связана с передачей информации. Протоколы передачи управляющей информации определяют процедуру взаимодействия SNMP-агента, работающего в управляемом оборудовании, и SNMP-монитора, работающего на компьютере администратора, который часто называют также консолью управления. Протоколы передачи определяют форматы сообщений, которыми обмениваются агенты и монитор. Вторая задача связана с контролируемыми переменными, характеризующими состояние управляемого устройства. Стандарты регламентируют, какие данные должны сохраняться и накапливаться в устройствах, имена этих данных и синтаксис этих имен. В стандарте SNMP определена спецификация информационной базы данных управления сетью. Эта спецификация, известная как база данных MIB (Management Information Base), определяет те элементы данных, которые управляемое устройство должно сохранять, и допустимые операции над ними.

2. IPSec - ОСНОВА БЕЗОПАСТНОГО ОБМЕНА ИНФОРМАЦИЕЙ В IP-СЕТЯХ

2.1 Архитектура протокола 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-адресов, которые в явном виде не были бы ею восприняты.

Ниже представлена анимация, визуализирующая процесс работы протокола IPSec:

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

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

-         индекс параметра защиты (Security Parameter Index, SPI) — 32-разрядное число, уведомляющее получателя о том, какую группу протоколов и алгоритмов защиты использует отправитель;

-         номер в последовательности — счетчик количества отправленных пакетов с данным SPI; обеспечивает защиту от ретрансляционных атак (когда хакер посылает копию пакета с нарушением порядка следования);

-         собственно данные;

-         заполнитель — поле переменного размера (0—255 байт), маскирующее истинную длину передаваемых данных;

-         длина предыдущего поля;

-         новый заголовок — поле, аналогичное полю Next в заголовке IP-пакета и указывающее тип передаваемых данных и используемый протокол. В случае применения протокола IPv6 в этом месте могут располагаться некоторые дополнительные поля заголовка.

 

Рисунок 2.1 – Структура TCP/IP пакета при использовании протокола ESP

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

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

Рисунок 2.2 – Структура пакета уровня ESP

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

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

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

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

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

Рисунок 2.3 – Заголовок пакета AH

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

-         следующий заголовок — поле, указывающее тот протокол (например, ESP или TCP), чей заголовок следует за AH;

-         длина заголовка — восьмиразрядное поле со значением, равным длине заголовка AH в четырехбайтных словах минус два слова (для совместимости с более ранней спецификацией AH);

-         зарезервированное поле, устанавливаемое в нулевое значение;

-         индекс параметра защиты (SPI). Это и следующее поле полностью аналогичны одноименным полям в заголовке ESP;

-         данные аутентификации — поле, содержащее цифровую подпись ICV и, возможно, заполнитель для выравнивания длины заголовка до целого значения, кратного 32 (IPv4) или 64 (IPv6) битам.

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

 

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

2.2.1 Группа протоколов IKE

Протоколы 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.

2.2.2 Установления «канала» IKE SA      

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

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

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

Рисунок 2.4 – Схема основного режима обмена информацией

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

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

Рисунок 2.5 – Схема агрессивного режима обмена информацией

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

Рисунок 2.6 – Схема быстрого режима обмена информацией

После процедур обмена, описанных выше, установление основного «канала» 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.

 

 

2.2.3 Алгоритм Диффи-Хеллмана

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

Рассмотрим более подробно математическую сторону алгоритма. Алгоритм Диффи-Хелмана  использует функцию дискретного возведения в степень и похож на метод Эль-Гамаля.  Сначала генерируются два больших простых числа n и q. Эти два числа не обязательно хранить в секрете. Далее один из партнеров P1 генерирует случайное число x и посылает другому участнику будущих обменов P2 значение

A = q^x mod n

По получении А партнер P2 генерирует случайное число у и посылает P2 вычисленное значение

B = q^y mod n

Партнер P1, получив В, вычисляет K_x = B^x mod n, а партнер P2 вычисляет K_y = A^y mod n. Алгоритм гарантирует, что числа K_y и K_x равны и могут быть использованы в качестве секретного ключа для шифрования. Ведь даже перехватив числа А и В, трудно вычислить K_x или K_y.

3.VPN– ТЕХНОЛОГИЯ ЗАЩИЩЕННЫХ ВИРТУАЛЬНЫХ СЕТЕЙ

Виртуальные частные сети (Virtual Private Networks -- VPN), позволяющие       передавать конфиденциальную информацию по сетям общего пользования,       возникли как альтернатива дорогостоящим частным сетям, базировавшимся на       выделенных каналах связи. В последнее время благодаря развитию электронных       форм ведения бизнеса, его глобализации и увеличению числа мобильных и       удаленных пользователей, которым необходим безопасный доступ к       корпоративной сети, интерес к ним возрос. По оценкам IDC (International Data Corp.), мировой рынок услуг IP VPN к 2004 г. вырастет до 17,6 млрд долларов. Сущность виртуальных частных сетей  заключается в использовании публичной телекоммуникационной инфраструктуры  для обеспечения безопасного доступа удаленных филиалов и пользователей к основной сети организации (Remote Access VPN) или для объединения географически удаленных локальных сетей (LAN-to-LAN VPN). Наиболее универсальным способом построения VPN является использование технологии туннелирования, или инкапсуляции. Эта технология позволяет передавать пакеты одной сети (первичной) по каналам связи другой (вторичной). Для этого пакет первичной сети (данные и протоколы)       инкапсулируется в пакет вторичной сети и становится виден, как данные.       Вообще говоря, инкапсуляция не предусматривает кодирования. Если для      повышения уровня безопасности оно необходимо, то должно выполняться       средствами частной сети до процедуры инкапсуляции. Туннель можно представить как сквозной виртуальный канал, имеющий начальную точку (инициатор туннеля) и одну или более конечных  (терминаторов туннеля). Этими точками могут быть компьютер удаленного пользователя, работающий как VPN-клиент, маршрутизатор, шлюз или сервер  доступа к сети (Network Access Server -- NAS). На обоих концах необходимо установить аппаратное и программное обеспечение (включая шифрование/дешифрование, если оно присутствует), работающее в соответствии  с теми протоколами, посредством которых был образован туннель. Хотя термин "туннель" ассоциируется с фиксированным путем, на самом деле для сетей с  коммутацией пакетов (Internet в частности) это не так. Зашифрованные и инкапсулированные пакеты могут использовать различные маршруты между  конечными точками. Основное назначение туннеля – обеспечить конфиденциальность сессии. Это значит, что никто, кроме получателя, не  расшифрует (в идеале) пакет, и чужие пакеты не могут попасть в туннель, поскольку маршрутная информация для VPN хранится отдельно от общей. Традиционно VPN (туннелирование и/или шифрование) организуют на нижних    уровнях коммуникационного стека протоколов -- канальном (Layer 2) и   сетевом (Layer 3). В соответствии с этим различают виртуальные частные       сети на уровне 2 (Layer 2 VPN) и на уровне 3 (Layer 3 VPN). Для построения туннелей на различных уровнях существуют несколько   протоколов. Типичным протоколом для Layer 2 VPN является L2F (Layer 2   Forwarding), предложенный Cisco, который инкапсулирует пакеты во фреймы Frame Relay или в ячейки ATM. Для Layer 3 VPN наиболее распространенным   является протокол IPSec. В настоящее время протокол IPSec применяется главным образом в различных решениях VPN в двух областях: для организации надежных соединений между офисами и для удаленного доступа. В случае VPN между офисами трафик между двумя локальными сетями направляется на межсетевые экраны (Firewall) или маршрутизаторы с поддержкой IPSec с обеих сторон соединения. Шлюз шифрует пакеты IP и отправляет их через общедоступную сеть далее к шлюзу назначения, где те расшифровываются и аутентифицируются. В противоположность этому, в случае удаленного доступа шифрование и дальнейшую передачу пакетов берет на себя клиентская программа на удаленной рабочей станции или портативный компьютер внештатного сотрудника. В сценарии с применением VPN протокол IPSec работает в туннельном режиме, т. е. передача пакета IPSec происходит «по туннелю» в пакетах IP. Его сессию можно представить следующими этапами. Компьютер инициирует туннель, связываясь с другим компьютером и посылая ему свой сертификат. В ответ инициатор получает сертификат удаленного компьютера. Затем машины начинают обмен данными, используя публичный и частный ключи для их шифрования и дешифрования, равно как и другую   информацию, необходимую для успешной и безопасной передачи.

Исторически сложились три различных варианта IP VPN. Эволюцию технологии VPN лучше всего оценивать по стоимости внедрения и обслуживания каждого решения, а также по их масштабируемости и управляемости. На рисунке 3.1 отражен анализ доходов на рынке IP VPN.

Рисунок 3.1 – Рост доходов на рынке IP VPN.

 Ниже мы рассмотрим основные «за» и «против» каждого подхода.

Раньше других услуги IP VPN начали предоставляться на базе frame relay. Стремящимся в мир IP-сетей провайдерам услуг frame relay приходилось заниматься сложным процессом конфигурирования постоянных виртуальных каналов (Permanent Virtual Circuit, PVC) и настройкой приложений Extranet, а заказчики видели только подключенный к сети Ethernet маршрутизатор и логику функционирования на канальном уровне. Поддержка высокого качества услуг (QoS), как правило, не составляла проблемы, однако необходимость ручной настройки PVC между различными офисами при каждом изменении топологии сети заказчика превращала организацию связи «всех со всеми» в слишком сложную задачу (рисунок 3.2). И хотя другие виды VPN на базе IP тоже зачастую с трудом справляются с данной задачей, VPN на основе frame relay находились в этом смысле в наихудшем положении.

Рисунок 3.2 – Управляемые VPN на базе frame relay.

К положительным моментам относится хорошее понимание этой технологии; многие провайдеры полностью возместили свои затраты на внедрение frame relay, поэтому стоимость оборудования была амортизирована, а операционные процедуры четко налажены. Пользователи доверяют данной технологии, поэтому провайдерам не нужно прикладывать много усилий, чтобы продать им эти услуги. Однако IP VPN на базе frame relay не могут помочь провайдерам поддерживать пользовательские приложения электронной коммерции, удовлетворить потребности в организации сетей Extranet и в распространении VPN на надомных сотрудников и мобильных пользователей. И это представляет серьезную проблему. Несмотря на то что использование frame relay остается самым простым и быстрым способом организации VPN, компания The Yankee Group прогнозирует весьма незначительный рост в данном сегменте рынка до 2005 г.

Значительно большей популярностью пользуются традиционные услуги VPN на базе CPE, в которых маршрутизаторы доступа к VPN и другие необходимые средства устанавливаются и обслуживаются на территории заказчика. В таких маршрутизаторах для установления связи через Internet или частную магистраль обычно используется протоколы PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer-2 Tunneling Protocol) или IPSec. В зависимости от потребностей своей сети заказчики могут выбирать и устанавливать у себя устройства разных типов: маршрутизаторы IP VPN, специально предназначенные для туннелирования; стандартные маршрутизаторы, оснащенные программной логикой VPN; шлюзы IP VPN, работающие с внешними маршрутизаторами; устройства IP VPN для небольших офисов, а также межсетевые экраны, функционирующие как шлюзы IP VPN (рисунок 3.3).

Рисунок 3.3 – Услуги IP VPN на базе CPE.

Сети IP VPN, для организации которых используется оборудование, установленное у заказчика, лучше подходят для поддержки географически распределенных пользователей и сложных сетей заказчика. Провайдер может модернизировать и заменять оборудование для поддержки новых заказчиков или технологий по мере необходимости. Этот подход также популярен среди пользователей, которые предпочитают, чтобы обслуживанием сети занимался провайдер. И именно в этом состоит главный минус. Для обслуживания VPN на базе CPE требуется много времени и квалифицированных специалистов, и такой отток ресурсов не позволяет провайдерам расширять свои услуги до массовых масштабов.

Тем не менее The Yankee Group прогнозирует для данной разновидности VPN устойчивый рост в будущем, хотя и несколько меньший, чем предсказывается производителями. К причинам подобного положения дел, похоже, можно отнести недостаточную реальную потребность в расширенных возможностях VPN, таких, как приложения удаленного доступа, Extranet и электронная коммерция. До сих пор для большинства функций Extranet пользователи полагались на встроенные средства защиты браузеров, использующих протокол SSL (Secure Sockets Layer). Другие же ждали, когда победит один из стандартов туннелирования. Эта ситуация должна измениться, поскольку сети IP VPN стали более надежными и простыми в управлении. Еще одним фактором является сложность реализации PKI в IP VPN. Большинство провайдеров обеспечивает лишь ограниченную поддержку PKI, теряя из-за этого пользователей, которым необходимы средства защиты более высокого уровня, и, фактически, заставляя их идти другим путем. И, конечно, большие усилия по-прежнему прилагаются к обеспечению в общедоступном Internet качества обслуживания (QoS). Лучшим решением можно считать использование частной IP-магистрали и оборудования CPE, с поддержкой распределения трафика по приоритетам и резервирование пропускной способности.

Третьим основным типом VPN является IP VPN на базе сети. В этих VPN вся логика функционирования, управление, защита и функции, которые составляют основу сети VPN конкретного заказчика, реализуются в точке присутствия провайдера. А поскольку весь «интеллект» VPN в этом случае находится в сети провайдера, заказчику требуется установить у себя только простой стандартный маршрутизатор. Таким образом, VPN «выносится» в сеть провайдера и развертывается внутри ее границ, а пользователь подключается к ней через обычный канал связи. Маршрутизация в VPN на базе сети может осуществляться двумя различными способами. При первом способе используются протоколы Multiprotocol Label Switching (MPLS) и Border Gateway Protocol (BGP), так что пограничные маршрутизаторы провайдера могут прокладывать через сети виртуальные каналы MPLS, по которым передается трафик от различных офисов, самой сети Internet и сетей других провайдеров. (Заметим, что стандартизация MPLS еще не завершена, поэтому оборудование разных производителей имеет различные варианты реализации этого протокола, и их совместимость пока под вопросом.) На рисунке 3.4 показана IP VPN на базе сети, в которой используются протоколы MPLS/BGP.

Рисунок 3.4 – IP VPN на базе сети с использованием MPLS/BGP.

Второй способ маршрутизации в IP VPN на базе сети реализуется с помощью протоколов PPTP, L2TP или IPSec, устанавливающих туннели между маршрутизаторами на границе сети провайдера (рисунок 3.5).

Рисунок 3.5. – Второй вид реализации IP VPN на базе сети.

Хотя IP VPN, использующие MPLS/BGP, обеспечивают простой переход от сетей на базе frame relay к их разновидности на базе IP, операторов не оставляют сомнения относительно организации IP VPN на базе сети провайдера в целом. Пользователи тоже настроены скептически, боясь положиться на единственного провайдера и отказаться от проверенного подхода — распределения услуг и устройств. VPN на базе MPLS/BGP являются исключением, пользуясь почти единодушным признанием как пользователей, так и провайдеров.

Однако IP VPN на базе сети популярны у провайдеров не только потому, что обладают лучшей масштабируемостью и управляемостью, но и потому, что поддерживают давно ожидаемые дополнительные дифференцированные услуги — от межсетевого экранирования до антивирусной защиты, кэширования и т. д. Большинство аналитиков предполагают, что в будущем основной моделью будет VPN на базе сети. Для провайдеров это вопрос масштабируемости и экономии, а также способ реализации QoS. Нелегко обслуживать тысячи/миллионы единиц CPE, а решение на базе сети позволит им работать более масштабно.

Потребность в услугах VPN на базе сети обеспечит быстрый рост рынка VPN, годовой доход от которого, по прогнозам The Yankee Group, превысит к 2000 г. 5 млрд долларов. Почему? VPN на базе сети больше подходят для небольших и средних организаций, а также зданий, где расположено много офисов и есть спрос на приложения Еxtranet.

Подводя итоги, хотелось бы отметить, что помимо обеспечения защиты от посторонних передаваемых данных, VPN имеет и ряд других достоинств, в том числе и экономических. Исследовательская компания Forrester Research опубликовала данные, характеризующие преимущества применения VPN поверх Интернет (из расчета на 1000 пользователей) по сравнению с созданием центра удаленного доступа (Remote Access Service). Эти данные можно представить в виде таблицы 4.1. Из таблицы можно видеть, что использование VPN позволяет снизить многие статьи затрат, включая закупку коммуникационного оборудования, оплату услуг Интернет-провайдера и т.д. Эти и другие исследования позволили Международной ассоциации компьютерной безопасности (International Computer Security Association, ICSA) включить технологию VPN в десятку самых известных технологий, которые будут в первую очередь применяться многими компаниями.

Таблица 3.1 – Преимущества применения VPN

 Это подтверждает и компания Gartner Group, которая в своем отчете предсказала, что средства построения VPN будут применяться в 2004 году в 90% компаний.

ВЫВОДЫ

Сегодня проблема обеспечения эффективной защиты корпоративной  регионально распределенной информационной системы является одной из самых важных и приоритетных проблем любой компании и организации. В основе этой проблемы лежит проблема безопасности TCP/IP. Одним из самых грамотных и экономически выгодных решений является технология защищенных виртуальных частных сетей – VPN, которая основывается на протоколе IPSec.

 Составные части архитектуры 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 сегодня действует еще одна группа, разрабатывающая спецификации для процедур сжатия отдельных полей в передаваемом пакете.

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

ПЕРЕЧЕНЬ ССЫЛОК

1.     Мамаев М., Петренко С. Технология защиты информации в Интернете. Специальный справочник.  – СПб.: Питер, 2002. – 848 с., ил.

2.     ALCATEL Technical Paper: Understanding the IPSec Protocol Suite, 2000

3.     Intoto White Paper: Virtual Private Network, 2002

4.  www.cimicorp.com/services.html