Протокол информационной безопасности сетевого уровня это

Обновлено: 29.05.2024

Рис. 1. Структурная схема организации телефонной связи через сеть Интернет с использованием шлюзов.
Протокол IP
Краеугольный камень сети Интернет - Internet Protocol (IP). Как уже отмечалось протокол Internet создан для использования в объединенных системах компьютерных коммуникационных сетей с коммутацией пакетов. Это протокол сетевого уровня, который обеспечивает маршрутизацию пакетов в сети. Однако он не гарантирует надежную доставку пакетов. Таким образом, пакеты могут искажаться, задерживаться, передаваться по различным маршрутам (а значит иметь различное время передачи) и т. д. На основе IP работают протоколы транспортного уровня Transport Control Protocol (TCP) и User Datagram Protocol (UDP).
Протокол Internet выполняет две главные функции: адресацию и фрагментацию.
Адресация: Выбор пути передачи называется маршрутизацией. Модули Internet используют адреса, помещенные в заголовок Internet, для передачи Internet датаграмм их получателям.
Фрагментация: Модули Internet используют поля в заголовке Internet для фрагментации и восстановления датаграмм Internet, когда это необходимо для их передачи через сети с малым размером пакетов.
Связь с другими протоколами
Следующая диаграмма иллюстрирует место протокола Internet в иерархии протоколов.

Табл. 1. Классификация типовых удаленных атак на распределенные ВС

Рис. 8 Архитектура IPSec
Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка протокола IKMP (Internet Key Management Protocol), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. В настоящее время рассматриваются концепции управления ключами с использованием спецификации ISAKMP (Internet Security Association and Key Management Protocol) и протокола Oakley установления ключа (Oakley Key Determination Protocol). Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Рассматриваются также возможности использования механизмов управления ключами протокола SKIP . Создаваемые стандарты управления
ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos.
Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. "контекста безопасности" - применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров. Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), представляющего собой указатель на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.
По сути, IPSec, работает на третьем уровне, т. е. на сетевом уровне. В результате передаваемые IP-пакеты защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (т. е. транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.

Рис. 10Формат заголовка AH
Последовательный номер пакета был введен в AH в 1997 году в ходе процесса пересмотра спецификации IPsec. Значение этого поля формируется отправителем и служит для защиты от атак, связанных с повторным использованием данных процесса аутентификации. Поскольку сеть Интернет не гарантирует порядок доставки пакетов, получатель должен хранить информацию о максимальном последовательном номере пакета, прошедшего успешную аутентификацию, и о получении некоторого числа пакетов, содержащих предыдущие последовательные номера (обычно это число равно 64).
В отличие от алгоритмов вычисления контрольной суммы, применяемых в протоколах передачи информации по коммутируемым линиям связи или по каналам локальных сетей и ориентированных на исправление случайных ошибок среды передачи, механизмы обеспечения целостности данных в открытых телекоммуникационных сетях должны иметь средства защиты от внесения целенаправленных изменений. Одним из таких механизмов является специальное применение алгоритма MD5: в процессе формирования AH последовательно вычисляется хэш-функция от объединения самого пакета и некоторого предварительно согласованного ключа, а затем от объединения полученного результата и преобразованного ключа. Данный механизм применяется по умолчанию в целях обеспечения всех реализаций IPv6, по крайней мере, одним общим алгоритмом, не подверженным экспортным ограничениям.
Заголовок ESP - Инкапсуляция зашифрованных данных
В случае использования инкапсуляции зашифрованных данных заголовок ESP является последним в ряду опциональных заголовков, "видимых" в пакете. Поскольку основной целью ESP является обеспечение конфиденциальности данных, разные виды информации могут требовать применения существенно различных алгоритмов шифрования. Следовательно, формат ESP может претерпевать значительные изменения в зависимости от используемых криптографических алгоритмов. Тем не менее, можно выделить следующие обязательные поля: SPI , указывающее на контекст безопасности, поле порядкового номера, содержащее последовательный номер пакета, и контрольная сумма, предназначенная для защиты от атак на целостность зашифрованных данных. Кроме этого, как правило, в теле ESP присутствуют параметры ( например, режим использования) и данные (например, вектор инициализации) применяемого алгоритма шифрования. Часть ESP заголовка может быть зашифрована на открытом ключе получателя или на совместном ключе пары отправитель-получатель. Получатель пакета ESP расшифровывает ESP заголовок и использует параметры и данные применяемого алгоритма шифрования для декодирования информации транспортного уровня.

Особенности IPSec SSL
Аппаратная независимость Да Да
Код Не требуется изменений для приложений. Может потребовать доступ к исходному коду стека TCP/IP. Требуются изменения в приложениях. Могут потребоваться новые DLL или доступ к исходному коду приложений.
Защита IP пакет целиком. Включает защиту для протоколов высших уровней. Только уровень приложений.
Фильтрация пакетов Основана на аутентифицированных заголовках, адресах отправителя и получателя, и т.п. Простая и дешёвая. Подходит для роутеров. Основана на содержимом и семантике высокого уровня. Более интеллектуальная и более сложная.
Производительность Меньшее число переключений контекста и перемещения данных. Большее число переключений контекста и перемещения данных. Большие блоки данных могут ускорить криптографические операции и обеспечить лучшее сжатие.
Платформы Любые системы, включая роутеры В основном, конечные системы (клиенты/серверы), также firewalls.
Firewall/VPN Весь трафик защищён. Защищён только трафик уровня приложений. ICMP, RSVP, QoS и т.п. могут быть незащищены.
Прозрачность Для пользователей и приложений. Только для пользователей.
Текущий статус Появляющийся стандарт. Широко используется WWW браузерами, также используется некоторыми другими продуктами.

Табл. 2. Классификация типовых удаленных атак на распределенные ВС
7.3 FireWall
Интернет-технологии FireWall (Межсетевые экраны)
Обзор
Когда Вы соединяете Вашу сеть с Internet или с другой сетью, фактор обеспечения безопасности доступа в Вашу сеть имеет критическое значение. Наиболее эффективный способ защиты при связи с Internet предполагает размещение межсетевого экрана FireWall между Вашей локальной сетью и Internet. Межсетевые экраны реализуют механизмы контроля доступа из внешней сети к внутренней путем фильтрации всего входящего и исходящего трафика, пропуская только авторизованные данные.
Существует три основных типа межсетевых экранов - пакетный фильтр (packet filtering), шлюз на сеансовом уровне (circuit-level gateway) и шлюз на прикладном уровне (application-level gateway). Очень немногие существующие межсетевые экраны могут быть однозначно отнесены к одному из названных типов. Как правило, МСЭ совмещает в себе функции двух или трех типов.
Как уже отмечалось, для того, чтобы эффективно обеспечивать безопасность сети, firewall обязан отслеживать и управлять всем потоком, проходящим через него. Для принятия управляющих решений для TCP/IP-сервисов (то есть передавать, блокировать или отмечать в журнале попытки установления соединений), firewall должен получать, запоминать, выбирать и обрабатывать информацию, полученную от всех коммуникационных уровней и от других приложений.
Недостаточно просто проверять пакеты по отдельности. Информация о состоянии соединения, полученная из инспекции соединений в прошлом и других приложений - главный фактор в принятии управляющего решения при попытке установления нового соединения. Для принятия решения могут учитываться как состояние соединения (полученное из прошлого потока данных), так и состояние приложения (полученное из других приложений).
Итак, управляющие решения требуют чтобы firewall имел доступ, возможность анализа и использования следующих вещей:
1. Информация о соединениях - информация от всех семи уровней в пакете.
2. История соединений - информация, полученная от предыдущих соединений. Например, исходящая команда PORT сессии FTP должна быть сохранена для того, чтобы в дальнейшем с его помощью можно было проверить входящее соединение FTP data.
3. Состояния уровня приложения - информация о состоянии, полученная из других приложений. Например, аутентифицированному до настоящего момента пользователю можно предоставить доступ через firewall только для авторизованных видов сервиса.
4. Манипулирование информацией - вычисление разнообразных выражений, основанных на всех вышеперечисленных факторах.
Сравнение альтернатив
В этом разделе описаны границы, в которых доступные технологии firewall обеспечивают эти четыре своих основных свойства.
Маршрутизаторы
Маршрутизаторы действуют на сетевом уровне и их очевидным недостатком является неспособность обеспечивать безопасность даже для наиболее известных сервисов и протоколов. Маршрутизаторы не являются устройствами обеспечения безопасности, так как они не имеют основных возможностей firewall:
1. Информация о соединении - маршрутизаторы имеют доступ лишь к ограниченной части заголовка пакетов.
2. Наследуемая информация о соединении и приложении - маршрутизаторы не поддерживают хранение информации о истории соединения или приложения.
3. Действия над информацией - маршрутизаторы имеют очень ограниченные возможности по действиям над информацией.
К тому же, маршрутизаторы трудно конфигурировать, следить за их состоянием и управлять. Они не обеспечивают должного уровня журналирования событий и механизмов оповещения.
Proxy
Proxy являются попыткой реализовать firewall на уровне приложения. Их основное преимущество - поддержка полной информации о приложениях. Proxy обеспечивают частичную информацию об истории соединений, полную информацию о приложении и частичную информацию о текущем соединении. Proxy также имеют возможность обработки и действий над информацией.
Однако, имеются очевидные трудности в использовании proxy на уровне приложения в качестве firewall, включая :
1. Ограничения на соединения - каждый сервис требует наличия своего собственного proxy, так что число доступных сервисов и их масштабируемость ограничены.
2. Ограничения технологии – шлюзы прикладного уровня не могут обеспечить proxy для UDP, RPC2 и других сервисов общих семейств протоколов.
3. Производительность - реализация на уровне приложения имеет значительные потери в производительности.
В добавление, proxy беззащитны к ошибкам в приложениях и ОС, неверной информации в нижних уровнях протоколов и в случае традиционных proxy очень редко являются прозрачными.
Исторически proxy уровня приложений удовлетворяли применению общему их применению и нуждам Internet. Однако, по мере превращения Internet в постоянно меняющуюся динамичную среду, постоянно предлагающую новые протоколы, сервисы и приложения, proxy более не способны обработать различные типы взаимодейстывий в Internet или отвечать новым нуждам бизнеса, высоким требованиям к пропускной способности и безопасности сетей.
7.4 Check Point FireWall-1 технология проверки с учетом состояния протокола (Stateful Inspection Technology)
Технология FireWall-1
В отличие от описанных альтернатив, FireWall-1 вводит передовую архитектуру, названную технологией проверки с учетом состояния протокола, которая реализует все необходимые возможности firewall на сетевом уровне.
Предлагая проверку с учетом состояния протокола, FireWall-1 модуль инспекции имеет доступ и анализирует данные, полученные от всех уровней коммуникаций. Эти данные о "состоянии" и "контексте" запоминаются и обновляются динамически, обеспечивая виртуальную информацию о сессии для отслеживания протоколов без установки соединений (таких как RPC и приложений основанных на UDP). Данные, собранные из состояний соединений и приложений, конфигурации сети и правил безопасности, используются для генерации соответствующего действия и либо принятия, либо отвержения, либо шифрации канала связи. Любой трафик, который намеренно не разрешен правилами безопасности блокируется по умолчанию и одновременно в реальном времени генерируются сигналы оповещения, обеспечивая системного администратора полной информацией о состоянии сети.
Табл. 3. Сравнение технологий
Свойство firewall Маршрутизаторы Proxy Проверка с учетом состояния протокола
Информация о канале связи Частично Частично Да
Информация об истории соединений Нет Частично Да
Информация о состоянии приложения Нет Да Да
Действия над информацией Частично Да Да

Итак, FireWall-1 совмещает прозрачность на сетевом уровне, полноту, надежность и высокую производительность с гибкостью на уровне приложений, обеспечивая тем самым превосходное решение для обеспечения безопасности, которое значительно превосходит возможности предыдущих решений.
Политика безопасности
Политика безопасности FireWall-1 выражается в виде базы правил и свойств. База правил - это упорядоченный набор правил, с помощью которых проверяется каждое соединение. Если источник соединения, назначение и тип сервиса соответствуют правилу, с соединением будет выполнено действие, описанное в правиле (Accept - принять, Encrypt-зашифровать, Reject-отклонить, Drop-оставить). Если соединение не соответствует ни одному из правил, оно блокируется, в соответствии с принципом "Что специально не разрешено, всегда запрещено".
Модуль проверки FireWall-1
Модуль проверки FireWall-1 динамически загружается в ядро операционной системы, между уровнем Data Link – каналом передачи данных и сетью (уровни 2 и 3). Когда приходит первый пакет нового соединения, модуль проверки FireWall-1 проверяет базу правил для определения должно ли быть разрешено это соединение. Как только соединение установлено, FireWall-1 добавляет его во внутреннюю таблицу соединений. Из соображений эффективности, последующие пакеты соединения проверяются по таблице соединений, а не по базе правил. Пакету разрешается быть переданным только, если соединение имеется в таблице соединений.
В таком соединении как здесь, соединение полностью ведется модулем проверки FireWall-1 (рис. 9).

Рис.12 Соединение управляется модулем проверки FireWall-1
Примеры
UDP
Из информации в заголовке TCP/UDP, FireWall-1, используя свои уникальные способности, моделирует состояние коммуникационного протокола, на основе чего отслеживает и управляет соединениями UDP.
FTP
Для отслеживания обратного соединения FTP-data, FireWall-1 извлекает информацию из области приложения в пакете. Такая уникальная способность использования информации из всех уровней позволяет FireWall-1 моделировать состояние протокола, на основе чего обратное соединение может быть установлено ("Исходящие соединения FTP").
RPC
FireWall-1 использует все описанные выше возможности, включая информацию о состоянии, полученную из приложения для отслеживания динамического переназначения номеров программ и портов этого сложного протокола ("RPC (Remote Procedure Call)").
Аутентификация на сервере безопасности и безопасность содержания
FireWall-1 позволяет администратору определять политику безопасности для каждого пользователя, где не только источник соединения, назначения и сервис проверяются, но и каждый пользователь должен быть аутентифицирован. Более того, соединения могут быть разрешены или запрещены исходя из их содержания. К примеру, почта для или от определенных адресов может быть запрещена или перенаправлена, доступ может быть запрещен к заданным URL , и включена анти-вирусная проверка над передаваемыми файлами.
Аутентификация и проверка содержимого обеспечиваются набором серверов безопасности FireWall-1, работающих на уровне приложения (Рис. 10).

Рис. 13 Соеднение через сервер безопасности FireWall-1

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

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

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

Для защиты информационного обмена на сеансовом уровне широкое распространение получил протокол SSL (Secure Sockets Layer). Для выполнения на сеансовом уровне функций посредничества между взаимодействующими сторонами организацией IETF (Internet Engineering Task Force) в качестве стандарта принят протокол SOCKS.

Протоколы SSL/TLS

Протокол SSL применяется в качестве протокола защищенного канала, работающего на сеансовом уровне модели OSI. Этот протокол использует криптографические методы защиты информации для обеспечения безопасности информационного обмена. Протокол SSL выполняет все функции по созданию защищенного канала между двумя абонентами сети, включая их взаимную аутентификацию, обеспечение конфиденциальности, целостности и аутентичности передаваемых данных. Ядром протокола SSL является технология комплексного использования асимметричных и симметричных криптосистем.

Взаимная аутентификация обеих сторон в SSL выполняется путем обмена цифровыми сертификатами открытых ключей пользователей (клиента и сервера), заверенными цифровой подписью специальных сертификационных центров. Протокол SSL поддерживает сертификаты, соответствующие общепринятому стандарту Х.509, а также стандарты инфраструктуры открытых ключей PKI (Public Key Infrastructure), с помощью которой организуется выдача и проверка подлинности сертификатов.

В качестве алгоритмов асимметричного шифрования используются алгоритм RSA, а также алгоритм Диффи — Хеллмана. Допустимыми алгоритмами симметричного шифрования являются RC2, RC4, DES, 3DES и AES. Для вычисления хэш-функций могут применяться стандарты MD5 и SHA-1. В протоколе SSL версии 3.0 набор криптографических алгоритмов является расширяемым.

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

Рис. 11.6. Криптозащищенные туннели, сформированные на основе протокола SSL

Протокол SSL предусматривает следующие этапы взаимодействия клиента и сервера при формировании и поддержке защищаемого соединения:
• установление SSL-сессии;
• защищенное взаимодействие.

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

Процедура установления SSL-сессии, называемая также процедурой рукопожатия, отрабатывается перед непосредственной защитой информационного обмена и выполняется по протоколу начального приветствия (Handshake Protocol), входящему в состав протокола SSL.

Протокол SSL 3.0 поддерживает три режима аутентификации:
• взаимную аутентификацию сторон;
• одностороннюю аутентификацию сервера без аутентификации клиента;
• полную анонимность.

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

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

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

Протокол SSL прошел проверку временем, работая в популярных браузерах Netscape Navigator и Internet Explorer, а также Web-серверах ведущих производителей. В январе 1999 г. на смену версии SSL 3.0 пришел протокол TLS (Transport Layer Security), который базируется на протоколе SSL и в настоящее время является стандартом Интернета. Различия между протоколами SSL 3.0 и TLS 1.0 не слишком существенны. Протокол SSL стал промышленным протоколом, развиваемым и продвигаемым вне технических координирующих институтов Internet.

Протокол SSL поддерживается ПО серверов и клиентов, выпускаемых ведущими западными компаниями. Существенным недостатком протокола SSLявляется то, что практически все продукты, поддерживающие SSL, из-за экспортных ограничений доступны за пределами США лишь в усеченном варианте (с длиной сеансового ключа 40 бит для алгоритмов симметричного шифрования и 512 бит для алгоритма RSA, используемого на этапе установления SSL-сессии).

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

Протокол SOCKS

Протокол SOCKS организует процедуру взаимодействия клиент-серверных приложений на сеансовом уровне модели OSI через сервер-посредник, илиproxy-сервер.

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

Согласно спецификации протокола SOCKS различают SOCKS-cepeep, который целесообразно устанавливать на шлюз (МЭ) сети, и SOCKS-клиент, который устанавливают на каждый пользовательский компьютер. SOCKS-сервер обеспечивает взаимодействие с любым прикладным сервером от имени соответствующего этому серверу прикладного клиента. SOCKS-клиент предназначен для перехвата всех запросов к прикладному серверу со стороны клиента и передачи их SOCKS-серверу. Следует отметить, что SOCKS-клиенты, выполняющие перехват запросов клиентских приложений и взаимодействие с SOCKS-сервером, могут быть встроены в универсальные клиентские программы. SOCKS-серверу известно о трафике на уровне сеанса (сокета), поэтому он может осуществлять тщательный контроль и, в частности, блокировать работу конкретных приложений пользователей, если они не имеют необходимых полномочий на информационный обмен.

Протокол SOCKS v5 одобрен организацией IETF (Internet Engineering Task Force) в качестве стандарта Internet и включен в RFC 1928.

Общая схема установления соединения по протоколу SOCKS v5 может быть описана следующим образом:
• запрос прикладного клиента, желающего установить соединение с каким-либо прикладным сервером в сети, перехватывает установленный на этом же компьютере SOCKS-клиент;
• соединившись с SOCKS-сервером, SOCKS-клиент сообщает ему идентификаторы всех методов аутентификации, которые он поддерживает;
• SOCKS-сервер решает, каким методом аутентификации воспользоваться (если SOCKS-сервер не поддерживает ни один из методов аутентификации, предложенных SOCKS-клиентом, соединение разрывается);
• при поддержке каких-либо предложенных методов аутентификации SOCKS-сервер в соответствии с выбранным методом аутентифицирует пользователя, от имени которого выступает SOCKS-клиент; в случае безуспешной аутентификации SOCKS-сервер разрывает соединение;
• после успешной аутентификации SOCKS-клиент передает SOCKS-серверу DNS-имя или IP-адрес запрашиваемого прикладного сервера в сети и далееSOCKS-сервер на основе имеющихся правил разграничения доступа принимает решение об установлении соединения с этим прикладным сервером;
• в случае установления соединения прикладной клиент и прикладной сервер взаимодействуют друг с другом по цепочке соединений, в которой SOCKS-сервер ретранслирует данные, а также может выполнять функции посредничества по защите сетевого взаимодействия; например, если в ходе аутентификации SOCKS-клиент и SOCKS-сервер обменялись сеансовым ключом, то весь трафик между ними может шифроваться.

Протокол SOCKS осуществляет встроенную поддержку популярных Web-навигаторов Netscape Navigator и Netscape Communicator компании Netscape, а также Internet Explorer компании Microsoft.

Специальные программы, называемые соксификаторами, дополняют клиентские приложения поддержкой протокола SOCKS. К таким программам относится, например, NEC SocksCap и др. При установке соксификатор внедряется между пользовательскими приложениями и стеком коммуникационных протоколов. Далее в процессе работы он перехватывает коммуникационные вызовы, формируемые приложениями, и перенаправляет их в случае надобности на SOCKS-сервер. При отсутствии нарушений установленных правил безопасности работа SOCKS-клиента совершенно прозрачна для клиентских приложений и пользователей.

Таким образом, для формирования защищенных виртуальных сетей по протоколу SOCKS в точке сопряжения каждой локальной сети с Интернетом на компьютере-шлюзе устанавливается SOCKS-сервер, а на рабочих станциях в локальных сетях и на компьютерах удаленных пользователей устанавливаютсяSOCKS-клиенты. По существу, SOCKS-сервер можно рассматривать как МЭ, поддерживающий протокол SOCKS (рис. 11.7).

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

Помимо защиты локальной сети от НСД, на SOCKS-сервер может возлагаться контроль доступа пользователей этой локальной сети к открытым ресурсам Интернета (Telnet, WWW, SMTP, POP и др.). Доступ является полностью авторизованным, так как идентифицируются и аутентифицируются конкретные пользователи, а не компьютеры, с которых они входят в сеть. Правила доступа могут запрещать или разрешать соединения с конкретными ресурсами Интернета в зависимости от полномочий конкретного сотрудника. Действие правил доступа может зависеть и от других параметров, например от метода аутентификации или времени суток.

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

Эта статья была опубликована Понедельник, 22 февраля, 2010 at 01:15 в рубрике Защита на канальном и сеаносвом уровнях. Вы можете следить за ответами через RSS 2.0 feed.

Свидетельство и скидка на обучение каждому участнику

Лекция 10. Защита информации на сетевом уровне - протокол IPSec

Архитектура протокола IPSec

Протоколы АН и ESP

Механизмы трансляции IPSec и NAT

Межсетевые экраны

Архитектура протокола IPSec

Зачем нужен IPSec. Протокол IP не имеет стандартного механизма безопасности, и IP-пакеты легко перехватывать. Без защиты и открытые, и частные сети подвержены несанкционированному доступу. Внутренние атаки - это обычно результат слабой или вообще отсутствующей защиты интрасети.

Поэтому сообщество Internet Engineering Task Force (IETF) разработало IPSec - протокол сетевого уровня для проверки подлинности, целостности, конфиденциальности данных и защиту от повторов. Поддержка IPSec встроена в Windows 2000/XP.

Развертывание протокола IPSec в Windows 2000/XP позволяет обеспечить высокий уровень безопасности всей сети, при этом приложения на серверах и клиентах, поддерживающих IPSec, защищаются автоматически.

Для предупреждения нападений в IPSec служат криптографические механизмы. Они защищают информацию путем хеширования и шифрования.

Уровень безопасности для данного сеанса в IPSec определяется политикой. Она назначается в распределенных системах через контроллеры домена с Windows 2000 или создается и хранится локально в реестре компьютера с Windows XP Professional.

IPSec – это набор протоколов, разработан IETF как базовый протокол обеспечения безопасности на уровне IP -соединения. Является дополнением к использующемуся протоколу IP ver .4 и составной частью IP ver .6.

Возможности, предоставляемые IPSec :

- контроль целостности данных;

- защита от повторений;

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

Уровень безопасности (высокий или низкий) определяется политиками IP-безопасности обменивающихся компьютеров. Скажем, для связи между компьютером с Windows XP и ПК, не поддерживающим IPSec, создание защищенного канала не требуется. С другой стороны, в сессии обмена между Windows 2000-сервером, содержащим конфиденциальные данные, и компьютером в интрасети обычно нужна высокая степень безопасности.

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

Операционные системы семейства Windows 2000 и выше имеют встроенную поддержку протокола IPSec . С точки зрения многоуровневой модели защиты, этот протокол является средством защиты уровня сети.

Рис.1. Туннель безопасности.

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

- указание на протоколы безопасности, используемые при передаче данных;

- ключи, необходимые для шифрования и формирования имитовставки;

- указание на метод форматирования, определяющий, каким образом создаются заголовки;

- индекс параметров защиты (Security Parameter Index, сокр . SPI ) – идентификатор, позволяющий найти нужный SA .

Обычно, контекст защиты является однонаправленным, а для передачи данных по туннелю в обе стороны задействуются два SA . Каждый хост имеет свою базу SA , из которой выбирается нужный элемент либо на основании SPI , либо по IP -адресу получателя.

IPSec состоит из 2 протоколов:

1) протокол аутентифицирующего заголовка – AH (от англ. Authentication Header ), обеспечивающий проверку целостности и аутентификацию передаваемых данных; последняя версия протокола описана в RFC 4302 (предыдущие – RFC 1826, 2402);

2) протокол инкапсулирующей защиты данных – ESP (от англ. Encapsulating Security Payload ) – обеспечивает конфиденциальность и, дополнительно, может обеспечивать проверку целостности и аутентификацию, описан в RFC 4303 (предыдущие – RFC 1827, 2406).

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

Транспортный режим ориентирован на соединение хост-хост. При использовании ESP в транспортном режиме защищаются только данные IP -пакета, заголовок не затрагивается. При использовании AH защита распространяется на данные и часть полей заголовка. Более подробно режимы работы описаны ниже.

2. Протокол AH

В
IP ver .4 аутентифицирующий заголовок располагается после IP -заголовка. Представим исходный IP -пакет как совокупность IP -заголовка, заголовка протокола следующего уровня (как правило, это TCP или UDP , на рис. 2 он обозначен как ULP – от англ. Upper - Level Protocol ) и данных.

Рис. 2. а) исходный IP-пакет, b) IP-пакет при использовании AH в транспортном режиме, с ) IP-пакет при использовании AH в туннельном режиме.

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

Р
ис.3. Структура заголовка протокола AH

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

Рассмотрим формат заголовка AH (рис.44). Первые 8 бит заголовка (поле Next Header ) содержат номер, соответствующий протоколу следующего уровня. Номер для каждого протокола назначает организация IANA ( Internet Assigned Numbers Authority ). Например, номер TCP – 6, ESP – 50, AH – 51 и т.д.

Поле Payload Len указывает длину заголовка AH в 32-битных словах. Далее 16 бит зарезервировано.

Поле SPI содержит значение индекса параметров защиты, по которому получатель сможет найти нужный SA . Нулевое значение SPI показывает, что для данного пакета SPI не существует.

Поле Sequence Number было введено в RFC 2402. Значение счетчика, содержащееся в этом поле, может использоваться для защиты от атак путем повторных посылок перехваченных пакетов. Если функция защиты от повторов активирована (а это указывается в SA ), отправитель последовательно наращивает значение поля для каждого пакета, передаваемого в рамках данной ассоциации (соединения, использующего единый SA ).

Поле Authentication Data , как уже указывалось ранее, хранит значение ICV .

Протокол ESP

Если AH обеспечивает защиту от угроз целостности передаваемых данных, то ESP также может обеспечивать и конфиденциальность.

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

- для формирования имитовставки HMAC-MD5-96 (используется по умолчанию) и HMAC-SHA-1-96;

- для шифрования - DES (в режиме CBC, используется по умолчанию) и NULL (отсутствие шифрования).

Рассмотрим формат заголовка ESP (рис. 5). Он начинается с двух 32-разрядных значений – SPI и SN . Роль их такая же, как в протоколе AH – SPI идентифицирует SA , использующийся для создания данного туннеля; SN – позволяет защититься от повторов пакетов. SN и SPI не шифруются.

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

Р
ис.4. а) исходный IP-пакет, b) ESP в транспортном режиме, c) ESP в туннельном режиме

Р
ис. 5. Структура заголовка ESP.

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

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

При совместном использовании протоколов AH и ESP , после IP заголовка идет AH , после него – ESP . В этом случае, ESP решает задачи обеспечения конфиденциальности, AH – обеспечения целостности и аутентификации источника соединения.

Рассмотрим ряд дополнительных вопросов, связанных с использованием IPSec . Начнем с того, откуда берется информация о параметрах соединения – SA . Создание базы SA может производиться различными путями. В частности, она может создаваться администратором безопасности вручную, или формироваться с использованием специальных протоколов – SKIP , ISAKMP ( Internet Security Association and Key Management Protocol ) и IKE ( Internet Key Exchange ).

Механизмы трансляции IPSec и NAT

Р
ис. 7. Пример использования NAT.

Внутренний локальный ip адрес : порт

Внешний ip адрес: порт

195.201.82.146: 2 16 1

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

Получив представление о механизме работы NAT , разберемся, какие сложности могут возникнуть, в случае использования IPSec . Предположим, с хоста с адресом 192.168.0.2 пытаются установить защищенное соединение с внешним хостом 195.242.2.2, используя протокол аутентифицирующего заголовка ( AH ). При прохождении маршрутизатора, ip -адрес отправителя меняется, как было описано выше. Протокол AH определяет, что значение имитовставки рассчитывается, включая неизменяемые поля IP -заголовка, в частности – адрес отправителя. Сторона-получатель, обнаружит неверное (из-за трансляции адресов) значение имитовставки и отбросит пакет.

Таким образом, NAT и AH несовместимы. В то же время, протокол ESP , который не контролирует целостность ip -заголовка, может использоваться совместно с NAT .

Кроме того, RFC 2709 определяет расширение NAT - IPC - NAT ( IPSec policy Controlled NAT – NAT управляемый правилами IPSec ), которое позволяет решить указанную проблему путем создания IP - IP туннеля, одной из конечных точек которого является узел NAT . В этом случае, вместо модификации IP -адреса отправителя в заголовке исходного пакета, NAT -устройство помещает без изменений весь исходный пакет (который аутентифицирован AH ), в новый IP -пакет, в заголовке которого в качестве адреса отправителя ставится адрес NAT -устройства. На стороне получателя из полученного пакета изымают исходный пакет и далее обрабатывают его как обычно.

Отдельно необходимо решать вопрос с распределением ключей. Если для этой цели используется протокол IKE (а он использует UDP , порт 500), потребуется специально организовать пересылку соответствующих данных во внутреннюю сеть. В том, случае, если задействовать UDP -порт 500 не представляется возможным, можно использовать описываемый в RFC 3947, 3948 механизм NAT - T (от англ. NAT traversal ) , определяющий инкапсуляцию IKE и IPSec трафика в пакеты UDP . При этом задействуется порт 4500.

4. Межсетевые экраны

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

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

Фильтрацию можно производить на разных уровнях эталонной модели сетевого взаимодействия OSI . По этому признаку МЭ делятся на следующие классы:

- экранирующий транспорт (шлюз сеансового уровня);

- экранирующий шлюз (шлюз прикладного уровня).

Экранирующий маршрутизатор (или пакетный фильтр) функционирует на сетевом уровне модели OSI , но для выполнения проверок может использовать информацию и из заголовков протоколов транспортного уровня. Соответственно, фильтрация может производиться по ip -адресам отправителя и получателя и по ТСР и UDP портам. Такие МЭ отличает высокая производительность и относительная простота – функциональностью пакетных фильтров обладают сейчас даже наиболее простые и недорогие аппаратные маршрутизаторы. В то же время, они не защищают от многих атак, например, связанных с подменой участников соединений.

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

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

В подобных случаях иногда перед МЭ создается открытый сегмент сети предприятия (рис. 8 b ), а МЭ защищает остальную внутреннюю сеть.

Рис. 8b.подключение межсетевого экрана с двумя сетевыми интерфейсами при выделении открытого сегмента внутренней сети

Недостаток данной схемы заключается в том, что подключения к узлам открытого сегмента МЭ не контролирует.

Более предпочтительным в данном случае является использование МЭ с тремя сетевыми интерфейсами (рис.8 c ).

Рис. 8c. подключение межсетевого экрана с тремя сетевыми интерфейсами для защиты внутренней сети и ее открытого сегмента

Еще более надежной считается схема, в которой для защиты сети с DMZ задействуются два независимо конфигурируемых МЭ (рис.8 d ).

Рис. 8 d . подключение двух межсетевых экранов для защиты внутренней сети и ее открытого

В этом случае, M Э 2 реализует более жесткий набор правил фильтрации по сравнению с МЭ1. И даже успешная атака на первый МЭ не сделает внутреннюю сеть беззащитной.

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

Протокол безопасности сетевого уровня

Information technology. Cryptographic data security. Network layer security protocol

Дата введения 2021-04-01

Предисловие

1 РАЗРАБОТАНЫ Акционерным обществом "Информационные технологии и коммуникационные системы" (АО "ИнфоТеКС")

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 26 "Криптографическая защита информации"

4 ВВЕДЕНЫ ВПЕРВЫЕ

Введение

Настоящие рекомендации содержат описание протокола безопасности сетевого уровня IPIir.

Необходимость разработки настоящих рекомендаций вызвана потребностью в обеспечении конфиденциальности и имитостойкости данных при их передаче в сетях общего пользования и корпоративных сетях с помощью стека протоколов TCP/IP с использованием российских национальных криптографических стандартов.

Примечание - Настоящие рекомендации дополнены приложением А.

1 Область применения

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

Протокол IPIir может применяться для создания виртуальных частных сетей (Virtual Private Network) на 3-м (сетевом) уровне базовой эталонной модели ISO OSI. Защита данных осуществляется при передаче IP-пакетов между любой парой узлов, поддерживающих протокол IPIir, включая варианты взаимодействия двух оконечных узлов, оконечного узла и шлюза безопасности и двух шлюзов безопасности. Все механизмы защиты реализуются в режиме без установления соединения (в сетевом смысле) между двумя взаимодействующими узлами.

2 Нормативные ссылки

В настоящих рекомендациях использованы нормативные ссылки на следующие документы:

ГОСТ 34.12-2018 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ 34.13-2018 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров

Р 1323565.1.005-2017 Информационная технология. Криптографическая защита информации. Допустимые объемы материала для обработки на одном ключе при использовании некоторых вариантов режимов работы блочных шифров в соответствии с ГОСТ Р 34.13-2015

Р 1323565.1.012-2017 Информационная технология. Криптографическая защита информации. Принципы разработки и модернизации шифровальных (криптографических) средств защиты информации

Р 1323565.1.026-2019 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров, реализующие аутентифицированное шифрование

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

3 Термины, определения и обозначения

3.1 Термины и определения

В настоящих рекомендациях применены следующие термины с соответствующими определениями:

3.1.1 AEAD (Authenticated Encryption with Associated Data): Шифрование с имитозащитой и ассоциированными данными.

3.1.2 IP-пакет (сетевой пакет): Логически неделимый блок данных на сетевом уровне базовой эталонной модели ISO OSI, относящийся к протоколу IP.

3.1.3 IPIir-пакет: IP-пакет, защищенный с использованием IPIir-протокола.

3.1.5 гаммирование: Процесс наложения по определенному закону гаммы шифра на открытые данные.

3.1.7 исходный IP-пакет: IP-пакет до его защиты протоколом IPIir.

3.1.8 ключ: Изменяемый параметр в виде последовательности символов, определяющий криптографическое преобразование.

3.1.9 ключ обмена: Ключ, известный только заданной паре узлов, используемый для выработки производных ключей.

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

3.1.11 криптографический набор (криптонабор): Совокупность криптографических алгоритмов и параметров, используемых в IPIir-протоколе.

3.1.12 контекст сетевого узла: Информация, необходимая для обработки/создания IPIir-пакетов от/для сетевого узла, логически связанного с данным.

3.1.13 маршрутизация IPIir-пакетов: Функция пересылки IPIir-пакетов, выполняемая сетевым узлом при приеме IPIir-пакетов, которые адресованы данному сетевому узлу с точки зрения IP-протокола, но для которых он не является узлом-получателем.

3.1.14 политика приема IPIir-пакетов: Совокупность правил обработки входящих IPIir-пакетов.

3.1.15 политика безопасности: Совокупность правил обработки IP-трафика сетевым узлом.

3.1.16 производный ключ: Ключ, выработанный из исходного ключа и открытых случайных и/или фиксированных данных.

3.1.17 режим работы протокола IPIir: Один из трех режимов работы протокола IPIir: транспортный, "легкий туннель" и туннель.

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

3.1.19 синхропосылка: Комбинация знаков, передаваемая по каналу связи и предназначенная для инициализации криптографических алгоритмов.

3.1.20 сквозная имитозащита: Имитозащита, осуществляемая между узлом-отправителем и узлом-получателем.

3.1.21 транзитная имитозащита: Имитозащита, осуществляемая между парами соседних узлов в цепочке передачи пакета.

3.1.22 транзитный узел: Узел, выполняющий функцию маршрутизации IPIir-пакетов.

3.1.23 узел (сетевой узел): Сетевое устройство, имеющее уникальный идентификатор и поддерживающее протокол IPIir.

3.1.24 узел-отправитель: Узел, создающий IPIir-пакет из исходного IP-пакета.

3.1.25 узел-получатель: Узел, восстанавливающий исходный IP-пакет из IPIir-пакета.

3.2 Обозначения

В настоящих рекомендациях использованы следующие обозначения:

- множество всех двоичных строк конечной длины, включая пустую строку;

- длина (число компонент) строки *;

- множество всех двоичных строк длины , где - целое неотрицательное число; нумерация подстрок и компонент строки осуществляется справа налево, начиная с нуля;

- конкатенация двоичных строк и из *, т.е. строка из , в которой левая подстрока из совпадает со строкой , а правая подстрока из совпадает со строкой ;

- двоичная строка, состоящая из нулей;

- усечение двоичной строки длины , , до двоичной строки длины , выполняющееся по правилу: , , =0,1, . ;

- представление элемента кольца в виде двоичной строки длины : для , где , =0, 1, . , выполнено равенство ;

- представление символа в виде двоичной строки длины 8, выполняющееся по следующему правилу: , где - ASCII-представление символа ;

- представление символьной строки , состоящей из символов, в виде двоичной строки длины , , выполняющееся по правилу:

- ключ шифрования пакета. Длина значения определяется использованным криптографическим набором;

- ключ сквозной имитозащиты пакета. Длина значения определяется использованным криптографическим набором;

- ключ шифрования и сквозной имитозащиты пакета. Длина значения определяется использованным криптографическим набором;

- ключ транзитной имитозащиты пакета. Длина значения определяется использованным криптографическим набором;

- версия IPIir-заголовка. Текущий документ описывает IPIir-заголовок, для которого Version=1. Длина поля равна 8 бит;

- идентификатор криптографического набора, определяющий состав криптографических механизмов и их параметров, используемых при создании IPIir-пакета. Длина поля равна 8 бит;

- флаг наличия полей для транзитной имитозащиты. Если T = 1, то в IPIir-заголовке присутствуют поля Transitldentifier, TransitlntegrityCheckValue и TransitlnitValue, иначе поля отсутствуют. При вычислении и проверке сквозной имитовставки (ICV) в поле T необходимо подставить 0. Длина поля равна 1 бит;

- флаг наличия поля DestinationIdentifer. Если D = 1, то в заголовке присутствует поле DestinationIdentifer, иначе поле отсутствует. Идентификатор узла-получателя необходим при маршрутизации IPIir-пакетов. Длина поля равна 1 бит;

- флаг расширенных идентификаторов сетевых узлов. Если ExtID = 0, то все идентификаторы сетевых узлов (поле Sourceldentifier и, при наличии, поля Destinationldentifier и Transitldentifier) имеют длину 32 бита. Если ExtID = 1, то все идентификаторы сетевых узлов имеют длину 64 бита. Длина поля равна 1 бит;

- флаг расширенного порядкового номера пакета. Если ExtSN=0, то поле порядкового номера пакета SequenceNumber имеет длину 32 бита. Если ExtSN = 1, то поле SequenceNumber имеет длину 64 бита. Длина поля равна 1 бит;

- флаг отключения механизма предотвращения повторов. Использование флага регулируется политиками безопасности. Длина поля равна 1 бит;

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

- номер ключа обмена, используемого для шифрования и вычисления сквозной имитовставки, но не для вычисления транзитной имитовставки. Длина поля равна 4 бита;

- номер ключа обмена, который использовался для вычисления транзитной имитовставки. Если транзитная имитозащита не используется, т.е. T = 0, то поле должно иметь значение 0. При вычислении и проверке сквозной имитовставки (ICV) вместо конкретного значения в поле TKN необходимо подставить 0. Длина поля равна 4 бита;

- время отправки пакета. Поле содержит значение времени отправки по астрономическим часам узла-отправителя в POSIX-формате времени, уменьшенное на 0x40000000 с. Время переполнения поля оценивается 2140 годом. Длина поля равна 32 бита;

- идентификатор сетевого узла-отправителя, с помощью которого узел-получатель определяет отправителя IPIir-пакета и связанный с ним контекст узла-отправителя для обработки пакета. Длина поля равна 32 бита при ExtID = 0 или 64 бита при ExtID = 1;

- идентификатор сетевого узла-получателя, необходимый при маршрутизации IPIir-пакетов. Поле присутствует, если D = 1. Длина поля равна 32 бита при ExtID = 0 или 64 бита при ExtID = 1;

- порядковый номер пакета; беззнаковое целое. Длина поля равна 32 бита при ExtSN = 0 или 64 бита при ExtSN = 1;

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

Type, Length, Value

- кортежи полей (тип, длина, значение), позволяющие передавать дополнительную информацию в составе IPIir-пакета. Туре - тип значения, содержащегося в поле Value. Длина поля равна 8 бит. Length - байтовая длина поля Value. Длина поля равна 8 бит. Value - произвольные данные типа Туре;

- поле переменной длины, содержащее исходный IP-пакет или его часть, в зависимости от режима работы IPIir-протокола;

- число байт сетевого дополнения Staffing. Поле присутствует, если S = 1. Длина поля равна 8 бит;

- режим, в котором сформирован IPIir-пакет. Длина поля равна 2 бита;

- флаг наличия полей Type, Length и Value. Если TLV = 1, то IPIir-тело начинается с кортежей (Type, Length, Value), в противном случае кортежи отсутствуют. Длина поля равна 1 бит;

- флаг наличия поля SL. Если S = 1, то в IPIir-теле присутствует поле SL, иначе поле отсутствует. Длина поля равна 1 бит;

- номер протокола исходного IP-пакета. Длина поля равна 8 бит;

- идентификатор транзитного узла, последним маршрутизировавшего данный IPIir-пакет. Каждый транзитный узел обновляет значение этого поля, записывая в него свой идентификатор. Поле присутствует, если T = 1. Длина поля равна 32 бита при ExtID = 0 или 64 бита при ExtID = 1;

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

Читайте также: