RFC: 3631
Оригинал: Security Mechanisms for the Internet
Категория: Информационный
Дата публикации:
Авторы: , ,
Перевод: Мельников Дмитрий Анатольевич

RFC 3631, Страница 7 из 18

3.3. IPsec-архитектура

Протоколы аутентификации и шифрования на IP-уровне (сетевом уровне), составляющие основу IPsec-архитектуры, представлены в стандартах RFC-2401, RFC-2402, RFC-2406, RFC-2407 и RFC-2411. По сути, данная архитектура безопасности защищает протоколы верхних уровней, включая ТСР- и UDP-протоколы. Она обеспечивает нормальное (однородное) распределение защиты, то есть «IP-узел ⇔ IP-узел», «IP-узел ⇔ шлюз безопасности» и «шлюз безопасности ⇔ шлюз безопасности». Функциональность IPsec-архитектуры позволяет пользователю самому распределять защиту, но это бывает сравнительно редко. По существу, применение IPsec-архитектуры теряет всякий смысл, если распределение защиты на самом IP-узле слишком неоднородно.

Так как программный IPsec-модуль встраивается в программное обеспечение сетевого уровня (IP-уровня), то тогда скорее всего оно будет внедряться непосредственно в листинг программы (код программы). Такое встраивание, как правило, требует либо замены аппаратной части или обновления архитектуры, связанной с заменой отдельных протоколов. С другой стороны, IPsec-архитектура совершенно прозрачна для прикладных служб. Прикладные службы, функционирующие над IPsec-протоколами, могут значительно повысить свою защищенность вообще без каких-либо изменений в собственных протоколах. Но сейчас, по крайней мере, пока IPsec-архитектура не нашла своего повсеместного применения в Internet-сети, большинство прикладных служб не должны «гадать», что они функционируют над IPsec-протоколами, которые выступают как альтернатива их собственным способам обеспечения ИБ. Большинство современных операционных систем способны функционировать совместно с программным IPsec-модулем, однако, большинство маршрутизаторов — нет, по крайней мере, с точки зрения управления. Прикладная служба, использующая TLS-протокол (Transport Level Security — TLS, RFC-2246), вероятнее всего имеет больше возможностей для учета собственных особенностей при проведении надежной процедуры аутентификации. Управление ключевой информацией в интересах IPsec-архитектуры может основываться на использовании электронных сертификатов или распределенных секретных ключей. Очевидно, что по многим причинам сертификаты более предпочтительнее, однако, они могут представлять большую «головную боль» для системного администратора.

В настоящее время существует серьезный конфликт между функционированием IPsec-протоколов и NAT-модулями (RFC-2993). Просто NAT-модуль не может сосуществовать с любым протоколом, сообщения которого содержат дополнительно размещаемые в них IP-адреса. Это касается IPsec-протоколов, каждого IP-пакета с сообщением любого протокола верхнего уровня, содержащего IP-адреса, если только они в заголовках. Этот конфликт иногда может быть преодолен за счет применения режима туннелирования (РТУ), но это не всегда приемлемо по различным причинам. В настоящее время идет работа по созданию стандарта, обеспечивающего более легкое преодоление NAT-модулей IPsec-пакетами.

Наиболее широко IPsec-протоколы используются в виртуальных корпоративных сетях (Virtual Private Network — VPN). Исходя из того, что встречаются и другие ограничения, IPsec-протоколы наиболее применимы в VPN-подобных ситуациях, включая вариант удаленного доступа, когда удаленный компьютер формирует обратный туннель (защищенное виртуальное соединение) в свою корпоративную сеть через Internet, используя для этого IPsec-протоколы.

Страница 7 из 18

2007 - 2022 © Русские переводы RFC, IETF, ISOC.