учебники, программирование, основы, введение в,

 

Архитектура безопасности для IP (часть 1)

Введение
Рассмотрим архитектуру семейства протоколов IPsec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP в окружении как IPv4, так и IPv6. Кроме того, будут представлены сервисы безопасности, предоставляемые протоколами IPsec, и применение этих сервисов в IP окружении. Затем мы обсудим следующие компоненты архитектуры безопасности IPsec:

  1. Протоколы безопасности – Authentication Header (AH) и Encapsulating Security Payload (ESP).
  2. Безопасные Ассоциации – что это такое, как они работают и как ими управлять.
  3. Управление ключом – ручное и автоматическое (Internet Key Exchange – IKE).
  4. Алгоритмы, используемые для аутентификации и шифрования.

Цели разработки
IPsec предназначен для безопасного взаимодействия на основе криптографии для IPv4 и IPv6. Набор сервисов безопасности включает управление доступом, целостность соединения, аутентификацию исходных данных, защиту от replay-атак (целостность последовательности), конфиденциальность (шифрование) и конфиденциальный поток трафика. Эти сервисы предоставляются на уровне IP, обеспечивая защиту для IP и/или протоколов более высокого уровня.
IPsec поддерживает две формы целостности: целостность соединения и частичную целостность последовательности. Целостность соединения является сервисом безопасности, который определяет модификацию конкретной IP датаграммы, безотносительно последовательности датаграмм в потоке трафика. Частичная целостность последовательности является anti-reply сервисом, с помощью которого определяется получение дубликатов IP датаграм.
Эти сервисы реализуются с использованием двух протоколов обеспечения безопасного трафика, Authentication Header (AH) и Encapsulating Security Payload (ESP), и с помощью процедур и протоколов управления криптографическим ключом. Множество применяемых IPsec протоколов и метод их использования определяются требованиями безопасности.
Когда данные механизмы установлены корректно, они не мешают пользователям, хостам и другим компонентам Internet, которые не применяют данные механизмы безопасности для защиты своего трафика. Эти механизмы являются алгоритмонезависимыми. Это означает возможность выбора различного набора алгоритмов без воздействия на другие части реализации. Например, различные группы пользователей могут выбрать при необходимости различные наборы алгоритмов.
Определен стандартный набор алгоритмов по умолчанию для обеспечения интероперабельности. Использование этих алгоритмов совместно с защитой трафика на основе IPsec и протоколами управления ключа позволяет обеспечить высокую степень криптографической безопасности.
Безопасность, обеспечиваемая IPsec, зависит от многих факторов операционного окружения, в котором IPsec выполняется. Например, от безопасности ОС, источника случайных чисел, плохих протоколов управления системой и т.д.
Обзор системы
Опишем функционирование IPsec, компоненты системы и то, как они взаимодействуют друг с другом для обеспечения сервисов безопасности.
IPsec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP- трафика. Термин «шлюз безопасности» используется для обозначения промежуточной системы, которая реализует IPsec-протоколы. Защита основана на требованиях, определенных в Базе Данных Политики Безопасности (Security Policy Database- SPD), определяемой и поддерживаемой системным администратором. Пакеты обрабатываются одним из трех способов на основании соответствия информации заголовка IP или транспортного уровня записям в SPD. Каждый пакет либо отбрасывается сервисом безопасности IPsec, либо пропускается без изменения, либо обрабатывается сервисом IPsec на основе применения определенной политики.
IPsec обеспечивает сервисы безопасности на IP-уровне, выбирая нужные протоколы безопасности, определяя алгоритмы, используемые сервисами, и предоставляя все криптографические ключи требуемым сервисам. IPsec может использоваться для защиты одного или нескольких «путей» между парой хостов, между парой шлюзов безопасности или между шлюзом безопасности и хостом.
Как работает IPsec
IPsec использует два протокола для обеспечения безопасности трафика – Authentication Header (AH) и Encapsulating Security Payload (ESP).

  • Authentication Header (AH) обеспечивает целостность соединения, аутентификацию исходных данных и дополнительно может обеспечивать anti-replay сервис.
  • Encapsulating Security Payload (ESP) протокол может обеспечивать конфиденциальность (шифрование) трафика. ESP также может обеспечивать целостность соединения, аутентификацию исходных данных и дополнительно anti-replay сервис. Целостность обеспечивается только для протоколов более высокого уровня. Хотя бы один из этих сервисов должен быть задействован при использовании ESP.

Эти протоколы могут применяться как по отдельности так и в комбинации с друг другом для обеспечения необходимого набора сервисов безопасности в IPv4 и IPv6. Каждый протокол поддерживает два режима использования: режим транспорта и режим туннелирования. В транспортном режиме протоколы обеспечивают защиту главным образом для протоколов более высокого уровня; в режиме туннелирования протоколы применяются для скрытия IP-заголовков исходных пакетов. Разница между двумя режимами рассматривается дальше.
IPsec позволяет системному администратору управлять детализацией, с которой предоставляется сервис безопасности. Например, можно создать единственный зашифрованный туннель между двумя безопасными шлюзами, или для каждого ТСР соединения может быть создан зашифрованный туннель между парой хостов. IPsec позволяет указывать следующие параметры:

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

Где может размещаться IPsec
Существует несколько способов реализации IPsec на хосте или в соединении с роутером или firewall (для создания безопасного шлюза). Приведем несколько общих примеров:

  1. Интеграция IPsec в конкретную реализацию IP. Это требует доступа к исходному коду IP и применимо как к хостам, так и к шлюзам безопасности.
  2. Bump-in-the-stack (BITS) реализации, где IPsec реализован «внизу» существующей реализации стека протоколов IP, между обычным IP и локальными сетевыми драйверами. Доступа к исходному коду стека IP в данном контексте не требуется, что делает такой подход пригодным для встраивания в существующие системы. Данный подход обычно реализуется на хостах.
  3. Использование внешнего криптопроцессора (обычно в военных и в некоторых коммерческих системах). Как правило, это является Bump-in-the-stack (BITS) реализацией. Такие реализации могут использоваться как на хостах, так и на шлюзах. Обычно BITS-устройства являются IP-адресуемыми.

Безопасные Ассоциации
Понятие «Безопасные Ассоциации» (Security Association – SA) является фундаментальным в IPsec.
SA есть симплексное (однонаправленное) логическое соединение, создаваемое для обеспечения безопасности. Весь трафик, передаваемый по SA, некоторым образом обрабатывается в целях обеспечения безопасности. И AH, и ESP используют в своей работе SAs. Одной из основных функций IKE является установление SA. Опишем различные аспекты управления SA, определим требуемые характеристики управления политикой SA, обработку трафика и технологии управления SA.
Определения
SA есть совокупность параметров соединения, которые дают возможность сервисам обеспечивать безопасный трафик. SA определяет использование AH или ESP. Если к потоку трафика применяются оба протокола, AH и ESP, то создаются две SAs. При двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется два SA (по одному на каждое направление).
SA однозначно определяется тройкой, состоящей из Security Parameter Index (SPI), IP Destination Address (адресом назначения) и идентификатора протокола безопасности (AH или ESP). В принципе адрес назначения может быть единственным адресом, широковещательным (broadcast) адресом или групповым (multicast) адресом. Однако механизм управления SA в настоящее время определяется только для единственной SA. Следовательно, SAs будут описаны в контексте point-to-point соединения, даже если концепция также применяется в случае point-to-multipoint.
Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим SA обеспечивает безопасную связь между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP заголовка и всех опций и перед любыми протоколами более высокого уровня (ТСР или UDP). В случае ESP транспортный режим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае AH защита также распространяется на отдельные части IP-заголовка.
Другим режимом SA является режим туннелирования. Если хотя бы одним из концов соединения является шлюз безопасности, то SA обязательно должна выполняться в туннелирующем режиме. SA между двумя шлюзами безопасности всегда находится в туннелирующем режиме, так же, как и SA между хостом и шлюзом безопасности. Заметим, что когда трафик предназначен для шлюза безопасности, например, в случае SNMP-команд, шлюз безопасности рассматривается как хост, и допустим транспортный режим. Два хоста могут при желании так же устанавливать туннелирующий режим.
B туннелирующем режиме SA существует «внешний» IP заголовок, который определяет пункт назначения IPsec, и «внутренний» IP заголовок, который определяет конечный пункт назначения для пакета. Заголовок протокола безопасности расположен после внешнего IP заголовка и перед внутренним IP заголовком. Если AH используется в туннелирующем режиме, части внешнего IP заголовка являются защищенными, как и весь туннелируемый IP пакет, т.е. все внутренние заголовки защищены, как и все протоколы более высокого уровня. Если применяется ESP, зашита обеспечивается только для туннелируемого пакета, а не для внешнего IP-заголовка.
Кратко подытожим:

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

Функциональности SA
Набор реализуемых SA сервисов безопасности зависит от выбранного протокола безопасности, режима SA, конечных точек SA и выбора дополнительных сервисов в протоколе. Например, AH обеспечивает аутентификацию исходных данных и целостность соединения для IP датаграм (в дальнейшем будем называть это «аутентификацией»). «Точность» сервиса аутентификации является функцией от степени детализованности SA, для которой используется AH.
AH также предоставляет анти-replay сервис (целостность отдельной последовательности) для получателя, помогая предотвратить атаки отказа в сервисе. AH применяется, когда не требуется конфиденциальность. AH также обеспечивает аутентификацию отдельных частей IP заголовка, за исключением изменяющихся частей IP заголовка.
ESP обеспечивает конфиденциальность трафика. Сила сервиса конфиденциальности зависит от используемого алгоритма шифрования. ESP также может дополнительно обеспечивать аутентификацию. Область аутентификации, обеспечиваемая ESP, является более узкой по сравнению с AH, т.е. IP-заголовок (заголовки), «внешние» по отношению к ESP заголовку, не защищены. Если аутентификация нужна только протоколам более высокого уровня, то аутентификация ESP является подходящей альтернативой, причем более эффективной, чем использование AH, инкапсулирующего ESP. Если для ESP SA используется аутентификация, получатель также может выбрать усиление использованием анти-replay сервиса с теми же самыми возможностями, что и AH анти-replay сервис. Хотя и конфиденциальность, и аутентификация являются необязательными, оба сервиса не могут быть опущены. По крайней мере, один из них должен присутствовать.
Использование туннелирующего режима позволяет зашифровывать внутренние IP заголовки, скрывая отправителя и получателя. Следует заметить, что сильно детализированные SAs обычно являются более уязвимыми для анализа трафика, чем слабо детализированные.
Комбинации SA
Иногда политика безопасности может требовать комбинации сервисов для конкретного потока трафика. В таких случаях необходимо установить несколько SAs для реализации принятой политики безопасности. Термин «узел безопасных ассоциаций» или «узел SA» применяется к последовательности SA, через которые должен проходить трафик для обеспечения требуемой политики безопасности. Заметим, что SAs, которые образуют узел, могут заканчиваться в различных точках.
Безопасные aссоциации могут комбинироваться в узлы двумя способами: транспортное соседство и повторное туннелирование.

  • Транспортное соседство означает применение более одного протокола для одной и той же IP датаграммы без использования туннелирования. Данный подход при комбинировании AH и ESP допускает только один уровень комбинации; дальнейшие вложенные поля не добавляют преимущества (в случае использования одинаково сильных алгоритмов для каждого протокола).
  • Повторное туннелирование означает применение нескольких протоколов, выполняющих туннелирование.

Существует три основных варианта повторного туннелирования:

  1. Оба конца SAs являются одинаковыми – внутренний и внешний туннели могут быть каждый AH или ESP, хотя маловероятно, что протоколы будут одинаковые, например, AH внутри AH или ESP внутри ESP.
  2. Один конец нескольких SAs является одним и тем же – внутренний и внешний туннели могут оба быть AH или ESP.
  3. Ни один из концов нескольких SAs не является одним и тем же – каждый внутренний и внешний туннели могут быть AH или ESP.

Эти два подхода также могут комбинироваться, например, узел SA может быть сконструирован из одного SA туннелироющего режима и одного или двух SAs транспортного режима, применяемых последовательно.

Базы данных безопасной ассоциации
Многие детали, связанные с обработкой IP-трафика в реализации IPsec не являются предметом стандартизации. Тем не менее, некоторые внешние аспекты обработки должны быть стандартизованы для обеспечения интероперабельности IPsec. Рассмотрим общую модель обработки IP трафика, относящуюся к безопасным ассоциациям. Внешнее поведение каждой реализации должно соответствовать характеристикам данной модели.
Существуют две БД: БД Политики Безопасности (SPD) и БД Безопасной Ассоциации (SAD). Первая описывает политики, которые определяют характер обработки всего IP трафика. Вторая БД содержит параметры, которые связаны с каждой активной безопасной ассоциацией. Определим также понятие Селектора как множества значений полей IP протокола и протокола более высокого уровня, которые используются БД Политики Безопасности для отображения трафика на SA.
Каждый сетевой интерфейс, для которого необходима обработка IPsec, требует определения баз данных для входящего и исходящего трафика.
БД политики безопасности (SPD)
В конечном счете, SA используется для осуществления политики безопасности в окружении IPsec. Таким образом, существенным элементом выполнения SA является лежащая в основе База Данных Политики Безопасности (SPD), которая определяет, какие сервисы обрабатывают IP датаграммы и каким образом. Форма БД и ее интерфейс находятся вне области стандартизации. Тем не менее определим основные возможности управления, которые должны быть представлены, чтобы системный администратор мог управлять применением IPsec к трафику, передаваемому или получаемому хостом или проходящему через шлюз безопасности.
SPD должна рассматриваться при обработке всего трафика (входящего и исходящего), включая не-IPsec трафик. Для того чтобы это поддерживать, SPD требует различных записей для входящего и выходящего трафика. Можно считать, что это отдельные SPDs (входящая и выходящая). Кроме того, отдельная SPD должна существовать для каждого IPsec-интерфейса.
SPD должна распознавать трафик, который разрешен защитой IPsec, и трафик, которому разрешено проходить IPsec без обработки. Для любой выходящей или входящей датаграммы существует три возможных способа обработки: отбросить датаграмму, обойти IPsec или применить IPsec. Первый вариант означает, что трафик не разрешен для хоста, не может пересекать шлюз безопасности или не может быть доставлен на уровень приложения. Второй вариант означает, что трафику разрешено проходить без дополнительной IPsec защиты. Третий вариант означает, что к трафику применяется IPsec защита и для такого трафика SPD должна специфицировать применяемые сервисы безопасности, применяемые протоколы, используемые алгоритмы и т.д.
Каждая реализация IPsec должна иметь программный интерфейс, который позволяет системному администратору управлять SPD. SPD должна определять, какие действия должны быть выполнены в том или ином случае. Таким образом, программный интерфейс должен позволять специфицировать обработку, применяемую к любому пакету, входящему или выходящему из системы. Интерфейс управления для SPD должен допускать создание последовательности записей, и должна поддерживаться упорядоченность этих записей. Возможно использование символа «*» в различных полях.
Определим стандартный набор элементов SPD, который должны поддерживать все реализации IPsec.
SPD содержит упорядоченный список записей политики. Каждая запись политики является ключом для одного или более селекторов, которые определяют множество IP трафика, соответствующего данной записи политики. Это определяет детализированность политики и создаваемых SAs. Каждая запись включает индикатор, показывающий, что трафик, соответствующий данной политике, должен быть пропущен, отброшен или обработан IPsec. Если применяется обработка IPsec, запись содержит описание SA (или узла SA), список применяемых протоколов, режимов и алгоритмов, включая любые дополнительные требования. Например, запись может указывать, что трафик защищается ESP в транспортном режиме, используя 3DES-CBC с явным IV, и вложен в AH в туннелирующем режиме с помощью НМАС /SHA-1.
Записи SPD должны быть упорядочены, и SPD должна всегда просматриваться в одном и том же порядке. Это требование является необходимым, чтобы воздействие на обрабатываемый трафик записей SPD было детерминированным.
Так как политика безопасности может требовать, чтобы более одной SA применялось к трафику в определенной последовательности, запись политики в SPD должна эту последовательность определять.
SA (или узел SA) может быть хорошо структурирована или грубоструктурирована в зависимости от селекторов, используемых для определения трафика, обрабатываемого SA. Например, весь трафик между двумя хостами может быть направлен через единственную SA, и может быть определен лишь один набор сервисов безопасности. В другом случае трафик между парой хостов может направляться через несколько SAs, в зависимости от используемых приложений, с различными сервисами безопасности, предоставляемыми различными SAs. Аналогично, весь трафик между парой шлюзов безопасности может быть направлен через единственную SA, или для каждой взаимодействующей пары хостов может быть определена своя SA.
База данных Безопасной Ассоциации (SAD)
В IPsec существует База Данных Безопасных Ассоциаций, в которой каждая запись определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола IPsec и SPI. Рассмотрим минимально необходимые элементы данных, требуемые для поддержки SA в реализации IPsec.
Для входящей обработки следующие поля пакета используются для поиска SA в SAD:

  • IP адрес назначения внешнего заголовка: IPv4 или IPv6 адрес назначения.
  • Протокол IPsec: AH или ESP, используемый в качестве индекса SA в данной БД. Определяет протокол IPsec, применяемый к трафику для данной SA.
  • SPI: 32-битное значение, применяемое для идентификации различных SA, заканчивающихся одним и тем же адресом назначения и использующих один и тот же IPsec протокол.

Следующие поля SAD используются для IPsec-обработки:

  • Sequence Number Counter: 32-битное значение, используемое для создания поля Sequence Number в AH или ESP заголовках (используется только для исходящего трафика).
  • Sequence Number Overflow: флаг, указывающий, было ли переполнение Sequence Number Counter, должен вызывать событие аудита и предотвращать передачу дополнительных пакетов по данной SA (используется только для исходящего трафика).
  • Anti-Replay Window: 32-битный счетчик или битовая карта (или некий эквивалент), используемые для проверки, является ли входящий AH или ESP пакет повтором. (Используется только для входящего трафика. Замечание: если anti-reply сервис не используется получателем, например, в случае ручных ключей SA, когда anti-reply window не используется.)
  • Алгоритм аутентификации для AH, ключи и т.д.
  • Алгоритм шифрования для ESP, ключи, режим, IV и т.д.
  • Алгоритм аутентификации для ESP, ключи и т.д. Если сервис аутентификации не выбран, данное поле будет нулевым.
  • Время жизни данной SA: интервал времени, после которого SA должна быть заменена новой SA (и новым SPI) или завершение SA, а также определения того, какое из этих действий должно выполняться. Это может быть выражено в виде времени или количества байтов, или и того, и другого одновременно. Реализации должны поддерживать оба типа времени жизни и одновременное применение обоих типов. Если используется время и если IKE задействует сертификаты Х.509 для установления SA, то время жизни SA должно входить в допустимый интервал для сертификатов. В этом смысле как инициатор, так и получатель ответственны за установление корректного времени жизни SA.

Должно быть два типа времени жизни: soft – время жизни, по истечении которого выдается предупреждение начать действия по замене SA, и hard – время жизни, когда текущая SA завершается.

  • Режим IPsec протокола: туннель или транспорт. Определяет применяемый режим AH или ESP к трафику для данной SA.

 


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


=

-

одна или более SA (AH или ESP, транспорт или туннель);

-

соединение (или административная граница);

Нх

-

хост х;

SGx

-

шлюз безопасности х;

Х*

-

Х поддерживает IPsec.

Замечание: рассматриваемые ниже безопасные ассоциации могут быть как AH, так и ESP. Режим (туннель или транспорт) определяется характером конечных точек. Для host-to-host SAs режим может быть как транспортным, так и туннелирующим.
В данном случае как транспортный, так и туннелирующей режим могут быть хостами. Заголовки в пакете между Н1 и Н2 должны выглядеть как в.

Вариант 1. Обеспечение end-to-end безопасности между двумя хостами через Internet (или intranet)


Таблица 23.1. Последовательность заголовков при соединении Host-Host

Transport

Tunnel

1. [IP1] [AH] [upper]

1. [IP2] [AH] [IP1] [upper]

2. [IP1] [ESP] [upper]

2. [IP2] [ESP] [IP1] [upper]

3. [IP1] [AH] [ESP] [upper]

 

Во втором варианте требуется только туннелирующий режим. При этом заголовки в пакете между SG1 и SG2 должны выглядеть как в.

Вариант 2. Создание простых виртуальных частных сетей


Таблица 23.2. Последовательность заголовков при соединении SG-SG

Tunnel

1. [IP2] [AH] [IP1] [upper]

2. [IP2] [ESP] [IP1] [upper]

Вариант 3. Комбинация вариантов 1 и 2 путем добавления end-to-end безопасности между хостами отправителя и получателя. Для хостов или шлюзов безопасности не вводится новых требований, кроме требования, чтобы шлюз безопасности был сконфигурирован для прохождения IPsec-трафика (включая ISAKMP трафик) для хостов позади него.
Вариант 4. Рассматривается случай, когда удаленный хост (Н1) использует Internet для достижения firewall'a организации ( SG2) и затем получает доступ к некоторому серверу или другой машине (Н2). Удаленный хост может быть мобильным хостом (Н1), подсоединяющимся по dial up к локальному РРР серверу (на диаграмме это не показано) по Internet и затем проходящему по Internet к firewall организации (SG2) и т.д.
Между Н1 и SG2 возможен только туннелирующий режим. Вариант для SA между Н1 и SG2 может быть быть один из тех, что представлены в варианте 2. Альтернатива для SA между Н1 и Н2 должна быть одной из тех, что представлены в варианте 1.
Заметим, что в данном варианте отправитель должен применять транспортный заголовок перед туннелирующим заголовком. Следовательно, интерфейс управления в реализациях IPsec должен поддерживать конфигурацию SPD и SAD, гарантирующую данную упорядоченность заголовка IPsec.
Поддержка дополнительных комбинаций AH и ESP не является обязательной. Дополнительные комбинации могут неблагоприятно сказываться на интероперабельности.
SA и Управление Ключом
IPsec поддерживает как ручные, так и автоматически созданные SA и соответствующее управление криптографическими ключами. Протоколы AH и ESP практически не зависят от используемых технологий управления ключом, хотя эти технологии могут некоторым образом влиять на сервисы безопасности, предоставляемые протоколами. Например, дополнительные anti-replay сервисы требуют автоматического управления SA. Более того, детализированность используемого распределения ключа определяет детализированность предоставляемой аутентификации.
Ручные технологии
Простейшей формой управления является ручное управление, при котором администратор вручную конфигурирует каждую систему материалом ключа и данными управления безопасной ассоциацией. Ручные технологии применяются в маленьких, статичных окружениях, и они не масштабируются. Например, компания может создать VPN, используя IPsec на хостах. Если количество хостов мало, и если все хосты расположены в пределах одного административного домена, то возможно применение ручных технологий управления. В данном случае хост должен выборочно защищать трафик и от других хостов в организации, используя вручную сконфигурированные ключи, допуская незащищенный трафик для других получателей. Данные технологии можно задействовать и в том случае, когда только выборочные коммуникации должны быть безопасны. Аналогичный аргумент может быть применен для использования IPsec в организации с небольшим числом хостов и/или шлюзов.
Автоматические SA и Управление Ключом
Широкое использование IPsec требует стандартного для Internet, масштабируемого, автоматического протокола управления SA. Такая поддержка необходима для использования anti-replay возможностей AH и ESP и для возможности создания SAs.
Протоколом автоматического управления ключом по умолчанию является IKE, но могут быть реализованы и другие протоколы автоматического управления ключом.
Проблемы выполнения
Использование IPsec навязывает высокую вычислительную стоимость на хостах и шлюзах безопасности, которые реализуют эти протоколы. Эта цена связана с памятью, необходимой для структур данных IPsec, вычисление значений проверки целостности, шифрование и дешифрование, а также дополнительное управление пакетом. Использование протоколов управления SA/ ключом, особенно тех, которые реализуют криптографию с открытым ключом, также добавляет соответствующую вычислительную стоимость в использование IPsec.
Использование IPsec также увеличивает стоимость компонентов, осуществляющих пересылку и роутинг в инфраструктуре Internet, но не реализующих IPsec. Это происходит из-за возрастания размера пакета в результате добавления заголовков AH и/или ESP, AH и ESP туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве примеров это возрастание не будет сильно влиять на инфраструктуру Internet.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика