Просмотр кода страницы IPsec

'''IPsec''' (сокращение от '''IP Security''') — набор [[сетевой протокол|протоколов]] для обеспечения защиты данных, передаваемых по межсетевому протоколу [[IP]]. Позволяет осуществлять подтверждение подлинности ([[Аутентификация|аутентификацию]]), проверку целостности и/или [[шифрование]] IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена [[Ключ (криптография)|ключами]] в сети [[Интернет]]. В основном применяется для организации [[VPN]]-соединений.

== История ==

Первоначально сеть [[Интернет]] была создана как безопасная среда передачи данных между военными. Так как с ней работал только определённый круг лиц, людей образованных и имеющих представления о политике безопасности, то явной нужды построения защищённых протоколов не было. Безопасность организовывалась на уровне физической изоляции объектов от посторонних лиц, и это было оправдано, когда к сети имело доступ ограниченное число машин. Однако, когда Интернет стал публичным и начал активно развиваться и разрастаться, такая потребность появилась<ref name="hist">''Станислав Коротыгин'', [http://www.ixbt.com/comm/ipsecure.shtml#Toc509471942 IPSec — протокол защиты сетевого трафика на IP-уровне] {{Wayback|url=http://www.ixbt.com/comm/ipsecure.shtml#Toc509471942 |date=20120128023609 }}.</ref>.

И в 1994 году [[Совет по архитектуре Интернета]] (IAB) выпустил отчёт «Безопасность архитектуры Интернета». Он посвящался в основном способам защиты от несанкционированного мониторинга, подмены пакетов и управлению потоками данных. Требовалась разработка некоторого стандарта или концепции, способной решить эту проблему. В результате появились стандарты защищённых протоколов, в числе которых и IPsec. Первоначально он включал в себя три базовые спецификации, описанные в документах (RFC1825, 1826 и 1827), однако впоследствии рабочая группа [[Инженерный совет Интернета|IP Security Protocol IETF]] пересмотрела их и предложила новые стандарты (RFC2401 — RFC2412), используемые и в настоящее время.

== Стандарты ==
* RFC 4301 (ранее RFC 2401) (Security Architecture for the Internet Protocol) — архитектура защиты для протокола IP.
* RFC 4302 (ранее RFC 2402 )(IP Authentication header) — аутентификационный заголовок IP.
* RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) — использование алгоритма хеширования MD-5 для создания аутентификационного заголовка.
* RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) — использование алгоритма хеширования SHA-1 для создания аутентификационного заголовка.
* RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) — использование алгоритма шифрования DES.
* RFC 4303 (ранее RFC 2406) (IP Encapsulating Security Payload [ESP]) — шифрование данных.
* RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) — область применения протокола управления ключами.
* RFC 2408 (Internet Security Association and Key Management Protocol [ISAKMP]) — управление ключами и аутентификаторами защищённых соединений.
* RFC 4109 (ранее RFC 2409) (Algorithms for Internet Key Exchange version 1 (IKEv1)) — обмен ключами IKEv1.
*RFC 4306 (The Internet Key Exchange (IKEv2) protocol) — протокол обмена ключами  IKEv2.
*RFC 8247 (Algorithm Implementation Requirements and Usage Guidance  the Internet Key Exchange Protocol Version 2 (IKEv2) - правила реализации и использования криптоалгоритмов в IKEv2.
* RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) — нулевой алгоритм шифрования и его использование.
* RFC 2411 (IP Security Document Roadmap) — дальнейшее развитие стандарта.
* RFC 2412 (The OAKLEY Key Determination Protocol) — проверка соответствия ключа.

== Архитектура IPsec ==
Построение защищённого канала связи может быть реализовано на разных уровнях модели [[Сетевая модель OSI|OSI]]. IPsec реализован на [[Протоколы сетевого уровня|сетевом уровне]].
В вопросе выбора уровня реализации защищённого канала несколько противоречивых аргументов: с одной стороны, за выбор верхних уровней говорит их независимость от вида транспортировки (выбора протокола сетевого и канального уровней), с другой стороны, для каждого приложения необходима отдельная настройка и конфигурация. Плюсом в выборе нижних уровней является их универсальность и наглядность для приложений, минусом — зависимость от выбора конкретного протокола (например, [[PPP (сетевой протокол)|PPP]] или [[Ethernet]]).
То, что IPsec располагается на сетевом уровне, является компромиссом в выборе уровня OSI. IPsec использует самый распространённый протокол сетевого уровня — [[IP]], что делает применение IPsec гибким — он может использоваться для защиты любых протоколов, базирующихся на IP ([[TCP]], [[UDP]] и другие). В то же время он прозрачен для большинства приложений{{sfn|Олифер|2010|с=890}}.

IPsec является набором стандартов Интернета и своего рода «надстройкой» над IP-протоколом. Его ядро составляют три протокола{{sfn|Олифер|2010|с=891}}:
* [[IPsec#Authentication Header|Authentication Header (АН)]] обеспечивает целостность передаваемых данных, [[Аутентификация|аутентификацию]] источника информации и функцию по предотвращению [[Атака повторного воспроизведения|повторной передачи пакетов]]
* [[IPsec#Encapsulating Security Payload|Encapsulating Security Payload (ESP)]] обеспечивает конфиденциальность ([[шифрование]]) передаваемой информации, ограничение потока конфиденциального трафика. Кроме этого, он может исполнять функции AH: обеспечить целостность передаваемых данных, аутентификацию источника информации и функцию по предотвращению повторной передачи пакетов. При применении ESP в обязательном порядке должен указываться набор услуг по обеспечению безопасности: каждая из его функций может включаться опционально.
* [[ISAKMP|Internet Security Association and Key Management Protocol (ISAKMP)]] — протокол, используемый для первичной настройки соединения, взаимной аутентификации конечными узлами друг друга и обмена [[Ключ (криптография)|секретными ключами]]. Протокол предусматривает использование различных механизмов обмена ключами, включая задание фиксированных ключей, использование таких протоколов, как [[IKE|Internet Key Exchange]], [[Kerberized Internet Negotiation of Keys]] (RFC 4430) или записей [[DNS]] типа IPSECKEY (RFC 4025).

Также одним из ключевых понятий является [[IPsec#Security Association|Security Association (SA)]]. По сути, SA является набором параметров, характеризующим соединение. Например, используемые алгоритм шифрования и [[Хеширование|хеш-функция]], секретные ключи, номер пакета и др.

=== Туннельный и транспортный режимы ===
IPsec может функционировать в двух режимах: транспортном и туннельном.

В транспортном режиме шифруются или подписываются только данные IP-пакета, исходный заголовок сохраняется. Транспортный режим, как правило, используется для установления соединения между хостами. Он может также использоваться между шлюзами для защиты [[Туннелирование (компьютерные сети)|туннелей]], организованных каким-нибудь другим способом (см., например, [[L2TP]]).

В туннельном режиме шифруется весь исходный IP-пакет: данные, заголовок, маршрутная информация, а затем он вставляется в поле данных нового пакета, то есть происходит [[Инкапсуляция (компьютерные сети)|инкапсуляция]]<ref name="mode">[http://www.onlamp.com/pub/a/bsd/2002/10/31/FreeBSD_Basics.html Cryptographic Terminology 101] {{Wayback|url=http://www.onlamp.com/pub/a/bsd/2002/10/31/FreeBSD_Basics.html |date=20130313085539 }}, Dru Lavigne, 2002.</ref>. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей [[VPN|виртуальной частной сети]].

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

== Security Association ==
Для начала обмена данными между двумя сторонами необходимо установить соединение, которое носит название SA (Security Association). Концепция SA фундаментальна для IPsec, собственно, является его сутью. Она описывает, как стороны будут использовать сервисы для обеспечения защищённого общения. Соединение SA является [[Симплексная связь|симплексным]] (однонаправленным), поэтому для взаимодействия сторон необходимо установить два соединения. Стоит также отметить, что стандарты IPsec позволяют конечным точкам защищённого канала использовать как одно SA для передачи трафика всех взаимодействующих через этот канал [[хост]]ов, так и создавать для этой цели произвольное число безопасных ассоциаций,
например, по одной на каждое TCP-соединение. Это дает возможность выбирать нужную степень детализации защиты. {{sfn|Олифер|2010|с=890}} Установка соединения начинается со взаимной аутентификации сторон. Далее происходит выбор параметров (будет ли осуществляться аутентификация, шифрование, проверка целостности данных) и необходимого протокола (AH или ESP) передачи данных. После этого выбираются конкретные алгоритмы (например, шифрования, хеш-функция) из нескольких возможных схем, некоторые из которых определены стандартом (для шифрования — [[DES]], для хеш-функций — [[MD5]] либо [[SHA-1]]), другие добавляются производителями продуктов, использующих IPsec (например [[Triple DES]], [[Blowfish]], [[CAST]]){{sfn|Олифер|2010|с=892}}.

=== Security Associations Database ===
Все SA хранятся в базе данных SAD (Security Associations Database) IPsec-модуля. Каждое SA имеет уникальный маркер, состоящий из трёх элементов{{sfn|Олифер|2010|с=898}}:
* индекса параметров безопасности (Security Parameters Index, SPI)
* IP-адреса назначения
* идентификатора протокола безопасности (ESP или AH)

IPsec-модуль, имея эти три параметра, может отыскать в SAD запись о конкретном SA. В список компонентов SA входят{{sfn|Andrew Mason, IPSec Overview|2002|loc=Part Five: Security Associations}}:
; ''Последовательный номер'': 32-битовое значение, которое используется для формирования поля ''Sequence Number'' в заголовках АН и ESP.
; ''Переполнение счетчика порядкового номера'': Флаг, который сигнализирует о переполнении счетчика последовательного номера.
; ''Окно для подавления атак воспроизведения'': Используется для определения повторной передачи пакетов. Если значение в поле ''Sequence Number'' не попадает в заданный диапазон, то пакет уничтожается.
; ''Информация AH'': используемый алгоритм аутентификации, необходимые ключи, время жизни ключей и другие параметры.
; ''Информация ESP'': алгоритмы шифрования и аутентификации, необходимые ключи, параметры инициализации (например, IV), время жизни ключей и другие параметры
; ''Режим работы IPsec'': туннельный или транспортный
; ''Время жизни SA'': Задано в секундах или байтах информации, проходящих через туннель. Определяет длительность существования SA, при достижении этого значения текущее SA должно завершиться, при необходимости продолжить соединение устанавливается новое SA.
; ''[[Maximum transmission unit|MTU]]'': Максимальный размер пакета, который можно передать по виртуальному каналу без фрагментации.

Каждый протокол (ESP/AH) должен иметь свой собственный SA для каждого направления, таким образом, связка AH+ESP требует для [[Дуплекс (телекоммуникации)|дуплексного]] канала наличия четырёх SA. Все эти данные располагаются в SAD.

В SAD содержатся:
* AH: алгоритм аутентификации.
* AH: секретный ключ для аутентификации
* ESP: алгоритм шифрования.
* ESP: секретный ключ шифрования.
* ESP: использование аутентификации (да/нет).
* Параметры для обмена ключами
* Ограничения маршрутизации
* Политика IP-фильтрации

=== Security Policy Database ===
Помимо базы данных SAD, реализации IPsec поддерживают базу данных SPD (Security Policy Database — база данных политики безопасности). SPD служит для соотнесения приходящих IP-пакетов с правилами обработки для них. Записи в SPD состоят из двух полей.{{sfn|Олифер|2010|с=896}} В первом хранятся характерные признаки пакетов, по которым можно выделить тот или иной поток информации. Эти поля называются селекторами. Примеры селекторов, которые содержатся в SPD{{sfn|Олифер|2010|с=898}}:

* IP-адрес места назначения
* IP-адрес отправителя
* Имя пользователя в формате [[DNS]] или [[X.500]]
* Порты отправителя и получателя

Второе поле в SPD содержит политику защиты, соответствующую данному потоку пакетов. Селекторы используются для фильтрации исходящих пакетов с целью поставить каждый пакет в соответствие с определенным SA. Когда поступает пакет, сравниваются значения соответствующих полей в пакете (селекторные поля) с теми, которые содержатся в SPD. При нахождении совпадения в поле политики защиты содержится информация о том, как поступать с данным пакетом: передать без изменений, отбросить или обработать. В случае обработки, в этом же поле содержится ссылка на соответствующую запись в SAD. Затем определяется SA для пакета и сопряжённый с ней индекс параметров безопасности (SPI), после чего выполняются операции IPsec (операции протокола AH или ESP).
Если пакет входящий, то в нём сразу содержится SPI — проводится соответствующая обработка.

== Authentication Header ==

{| class="wikitable" style="text-align: center"
|+''Authentication Header'' format
|-
! style="border-bottom:none; border-right:none;"| ''Offsets''
! style="border-left:none;"| Octet<sub>16</sub>
! colspan="8" | 0
! colspan="8" | 1
! colspan="8" | 2
! colspan="8" | 3
|-
! style="border-top: none" | Octet<sub>16</sub>
! Bit<sub>10</sub>
! style="width:2.6%;"| 0
! style="width:2.6%;"| 1
! style="width:2.6%;"| 2
! style="width:2.6%;"| 3
! style="width:2.6%;"| 4
! style="width:2.6%;"| 5
! style="width:2.6%;"| 6
! style="width:2.6%;"| 7
! style="width:2.6%;"| 8
! style="width:2.6%;"| 9
! style="width:2.6%;"| 10
! style="width:2.6%;"| 11
! style="width:2.6%;"| 12
! style="width:2.6%;"| 13
! style="width:2.6%;"| 14
! style="width:2.6%;"| 15
! style="width:2.6%;"| 16
! style="width:2.6%;"| 17
! style="width:2.6%;"| 18
! style="width:2.6%;"| 19
! style="width:2.6%;"| 20
! style="width:2.6%;"| 21
! style="width:2.6%;"| 22
! style="width:2.6%;"| 23
! style="width:2.6%;"| 24
! style="width:2.6%;"| 25
! style="width:2.6%;"| 26
! style="width:2.6%;"| 27
! style="width:2.6%;"| 28
! style="width:2.6%;"| 29
! style="width:2.6%;"| 30
! style="width:2.6%;"| 31
|-
! 0
! 0
| colspan="8"|''Next Header''
| colspan="8"|''Payload Len''
| colspan="16"|''Reserved''
|-
! 4
! 32
| colspan="32"|''Security Parameters Index (SPI)''
|-
! 8
! 64
| colspan="32"|''Sequence Number''
|-
! C
! 96
| colspan="32" rowspan="2"|''Integrity Check Value (ICV)''<br />…
|-
! …
! …
|}

; ''Тип следующего заголовка'' (8 bits): Тип заголовка протокола, идущего после заголовка AH. По этому полю приёмный IP-sec модуль узнает о защищаемом протоколе верхнего уровня. Значения этого поля для разных протоколов можно посмотреть в RFC 1700.
; ''Длина содержимого'' (8 bits): Это поле определяет общий размер АН-заголовка в 32-битовых словах, минус 2. Несмотря на это, при использовании IPv6 длина заголовка должна быть кратна 8 байтам.
; ''Зарезервировано'' (16 bits): Зарезервировано. Заполняется нулями.
; ''Индекс параметров системы безопасности'' (32 bits): Индекс параметров безопасности. Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (АН-протокол), однозначно определяет защищённое виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1…255 зарезервирован [[IANA]].
; ''Порядковый номер'' (32 bits): Последовательный номер. Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может отказаться от услуги по защите от повторной передачи пакетов, оно является обязательным и всегда присутствует в AH-заголовке. Передающий IPsec-модуль всегда использует это поле, но получатель может его и не обрабатывать.
; ''Данные аутентификации'': Цифровая подпись. Служит для аутентификации и проверки целостности пакета. Должна быть дополнена до размера, кратного 8 байтам для IPv6, и 4 байтам — для IPv4.

Протокол AH используется для аутентификации, то есть для подтверждения того, что мы связываемся именно с тем, с кем предполагаем, и что данные, которые мы получаем, не искажены при передаче<ref name="RFC 2402">RFC 2402.</ref>.

=== Обработка выходных IP-пакетов  ===
Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает AH-обработку, то он начинает обработку. В зависимости от режима (транспортный или режим туннелирования) он по-разному вставляет AH-заголовок в IP-пакет. В транспортном режиме AH-заголовок располагается после заголовка протокола IP и перед заголовками протоколов верхнего уровня (Обычно, [[TCP]] или [[UDP]]). В режиме туннелирования весь исходный IP-пакет обрамляется сначала заголовком AH, затем — заголовком IP-протокола. Такой заголовок называется внешним, а заголовок исходного IP-пакета — внутренним. После этого передающий IPsec-модуль должен сгенерировать последовательный номер и записать его в поле ''Sequence Number''. При установлении SA последовательный номер устанавливается в 0, и перед отправкой каждого IPsec-пакета увеличивается на единицу. Кроме того, происходит проверка — не зациклился ли счетчик. Если он достиг своего максимального значения, то он снова устанавливается в 0. Если используется услуга по предотвращению повторной передачи, то при достижении счетчиком своего максимального значения передающий IPsec-модуль переустанавливает SA. Таким образом обеспечивается защита от [[Атака повторного воспроизведения|повторной посылки пакета]] — приёмный IPsec-модуль будет проверять поле ''Sequence Number'' и игнорировать повторно приходящие пакеты. Далее происходит вычисление контрольной суммы ICV. Надо заметить, что здесь контрольная сумма вычисляется с применением секретного ключа, без которого злоумышленник сможет заново вычислить хеш, но, не зная ключа, не сможет сформировать правильную контрольную сумму. Конкретные алгоритмы, использующиеся для вычисления ICV, можно узнать из RFC 4305. В настоящее время могут применяться, например, алгоритмы HMAC-SHA1-96 или AES-XCBC-MAC-96. Протокол АН вычисляет контрольную сумму (ICV) по следующим полям IPsec-пакета{{sfn|Олифер|2010|с=895}}:
* поля IP-заголовка, которые не были подвержены изменениям в процессе транслирования или определены как наиболее важные
* АН-заголовок (Поля: «Next Header», «Payload Len», «Reserved», «SPI», «Sequence Number», «Integrity Check Value». Поле «Integrity Check Value» устанавливается в 0 при вычислении ICV
* данные протокола верхнего уровня. Если поле может изменяться в процессе транспортировки, то его значение устанавливается в 0 перед вычислением ICV. Исключения составляют поля, которые могут изменяться, но значение которых можно предугадать при приёме. При вычислении ICV они не заполняются нулями. Примером изменяемого поля может служить поле контрольной суммы, примером изменяемого, но предопределенного может являться IP-адрес получателя. Более подробное описание того, какие поля как учитываются при вычислении ICV, можно найти в стандарте RFC 2402.
=== Обработка входных IP-пакетов ===

После получения пакета, содержащего сообщение АН-протокола, приёмный IPsec-модуль ищет соответствующее защищённое виртуальное соединение (SA) SAD (Security Associations Database), используя IP-адрес получателя, протокол безопасности (АН) и индекс SPI. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищённое виртуальное соединение (SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, то есть на необходимость проверки поля ''Sequence Number''. Если услуга используется, то поле проверяется. При этом используется метод скользящего окна для ограничения буферной памяти, требуемый для работы протоколу. Приёмный IPsec-модуль формирует окно с шириной W (обычно W выбирается равным 32 или 64 пакетам). Левый край окна соответствует минимальному последовательному номеру (''Sequence Number'') N правильно принятого пакета. Пакет с полем ''Sequence Number'', в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна — он уничтожается. Затем приёмный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле «Integrity Check Value». Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным и принимается для дальнейшей IP-обработки. Если проверка дала отрицательный результат, то принятый пакет уничтожается{{sfn|Олифер|2010|с=895}}.

== Encapsulating Security Payload==

{| class="wikitable" style="text-align: center"
|+''Encapsulating Security Payload'' format
|-
! style="border-bottom:none; border-right:none;"| ''Offsets''
! style="border-left:none;"| Octet<sub>16</sub>
! colspan="8" | 0
! colspan="8" | 1
! colspan="8" | 2
! colspan="8" | 3
|-
! style="border-top: none" | Octet<sub>16</sub>
! Bit<sub>10</sub>
! style="width:2.6%;"| 0
! style="width:2.6%;"| 1
! style="width:2.6%;"| 2
! style="width:2.6%;"| 3
! style="width:2.6%;"| 4
! style="width:2.6%;"| 5
! style="width:2.6%;"| 6
! style="width:2.6%;"| 7
! style="width:2.6%;"| 8
! style="width:2.6%;"| 9
! style="width:2.6%;"| 10
! style="width:2.6%;"| 11
! style="width:2.6%;"| 12
! style="width:2.6%;"| 13
! style="width:2.6%;"| 14
! style="width:2.6%;"| 15
! style="width:2.6%;"| 16
! style="width:2.6%;"| 17
! style="width:2.6%;"| 18
! style="width:2.6%;"| 19
! style="width:2.6%;"| 20
! style="width:2.6%;"| 21
! style="width:2.6%;"| 22
! style="width:2.6%;"| 23
! style="width:2.6%;"| 24
! style="width:2.6%;"| 25
! style="width:2.6%;"| 26
! style="width:2.6%;"| 27
! style="width:2.6%;"| 28
! style="width:2.6%;"| 29
! style="width:2.6%;"| 30
! style="width:2.6%;"| 31
|-
! 0
! 0
| colspan="32"|''Security Parameters Index (SPI)''
|-
! 4
! 32
| colspan="32"|''Sequence Number''
|-
! 8
! 64
|colspan=32 rowspan=2|''Payload data''
|-
! …
! …
|-
! …
! …
| colspan=8 style="border-top-style: hidden;" |  
| colspan=24 style="border-bottom-style: hidden;" |  
|-
! …
! …
| colspan=8 style="border-right-style: hidden;" |  
| colspan=16 | ''Padding (0-255 octets)''
| colspan=8 style="border-left-style: hidden;" |  
|-
! …
! …
| colspan=16 style="border-top-style: hidden;" |  
| colspan=8 | ''Pad Length''
| colspan=8 | ''Next Header''
|-
! …
! …
| colspan="32" rowspan="2"|''Integrity Check Value (ICV)''<br />…
|-
! …
! …
|}
; ''Security Parameters Index'' (32 bits): Индекс параметров безопасности (аналогичен соответствующему полю AH). Значение этого поля вместе с IP-адресом получателя и протоколом безопасности (ESP-протокол), однозначно определяет защищённое виртуальное соединение (SA) для данного пакета. Диапазон значений SPI 1…255 зарезервирован [[IANA]] для последующего использования.
; ''Sequence Number'' (32 bits): Последовательный номер (аналогичен соответствующему полю AH). Служит для защиты от повторной передачи. Поле содержит монотонно возрастающее значение параметра. Несмотря на то, что получатель может и отказаться от услуги по защите от повторной передачи пакетов, оно всегда присутствует в ESP-заголовке. Отправитель (передающий IPsec-модуль) должен всегда использовать это поле, но получатель может и не нуждаться в его обработке.
; ''Payload data'' (variable): Это поле содержит данные (в зависимости от выбора режима — туннельного или транспортного, здесь может находиться либо весь исходный [[Инкапсуляция (компьютерные сети)|инкапсулированный]] пакет, либо лишь его данные) в соответствии с полем «Next Header». Это поле является обязательным и состоит из целого числа байтов. Если алгоритм, который используется для шифрования этого поля, требует данных для синхронизации криптопроцессов (например, вектор инициализации — [[:en:Initialization vector|«Initialization Vector»]]), то это поле может содержать эти данные в явном виде.
; ''Padding'' (0-255 octets): Дополнение. Необходимо, например, для алгоритмов, которые требуют, чтобы открытый текст был кратен некоторому числу байтов), например, размеру блока для блочного шифра.
; ''Pad Length'' (8 bits): Размер дополнения (в байтах).
; ''Next Header'' (8 bits): Это поле определяет тип данных, содержащихся в поле «Payload data».
; ''Integrity Check Value'': Контрольная сумма. Служит для аутентификации и проверки целостности пакета. Должна быть кратна 8 байтам для IPv6 и 4 байтам — для IPv4<ref name="RFC 2406">RFC 2406.</ref>.

=== Обработка выходных IPsec-пакетов ===

Если передающий IPsec-модуль определяет, что пакет связан с SA, которое предполагает ESP-обработку, то он начинает обработку. В зависимости от режима (транспортный или режим туннелирования) исходный IP-пакет обрабатывается по-разному. В транспортном режиме передающий IPsec-модуль осуществляет процедуру обрамления протокола верхнего уровня (например, TCP или UDP), используя для этого ESP-заголовок (поля Security Parameters Index и Sequence Number заголовка) и ESP-концевик (остальные поля заголовка, следующие за полем данных — Payload data), не затрагивая при этом заголовок исходного IP-пакета. В режиме туннелирования IP-пакет обрамляется ESP-заголовком и ESP-концевиком ([[Инкапсуляция (компьютерные сети)|инкапсуляция]]), после чего обрамляется внешним IP-заголовком (который может не совпадать с исходным — например, если IPsec модуль установлен на [[Сетевой шлюз|шлюзе]]){{sfn|Олифер|2010|с=896}}. 
Далее производится шифрование — в транспортном режиме шифруется только сообщение протокола вышележащего уровня (то есть все, что находилось после IP-заголовка в исходном пакете), в режиме туннелирования — весь исходный IP-пакет. Передающий IPsec-модуль из записи о SA определяет алгоритм шифрования и [[Ключ (криптография)|секретный ключ]]. Стандарты IPsec разрешают использование алгоритмов шифрования [[Triple DES]], [[Advanced Encryption Standard|AES]] и [[Blowfish]], если их поддерживают обе стороны. Иначе используется DES, прописанный в RFC 2405. Так как размер открытого текста должен быть кратен определенному числу байт, например, размеру блока для [[Блочный шифр|блочных алгоритмов]], перед шифрованием производится ещё и необходимое дополнение шифруемого сообщения. Зашифрованное сообщение помещается в поле ''Payload Data''. В поле ''Pad Length'' помещается длина дополнения. Затем, как и в AH, вычисляется ''Sequence Number,'' после чего считается контрольная сумма (ICV). Контрольная сумма, в отличие от протокола AH, где при её вычислении учитываются также и некоторые поля IP-заголовка, в ESP вычисляется только по полям ESP-пакета за вычетом поля ICV. Перед вычислением контрольной суммы оно заполняется нулями. Алгоритм вычисления ICV, как и в протоколе AH, передающий IPsec-модуль узнает из записи об SA, с которым связан обрабатываемый пакет.

=== Обработка входных IPsec-пакетов ===

После получения пакета, содержащего сообщение ESP-протокола, приёмный IPsec-модуль ищет соответствующее защищённое виртуальное соединение (SA) в SAD, используя IP-адрес получателя, протокол безопасности (ESP) и индекс SPI{{sfn|Олифер|2010|с=896}}. Если соответствующее SA не найдено, пакет уничтожается. Найденное защищённое виртуальное соединение (SA) указывает на то, используется ли услуга по предотвращению повторной передачи пакетов, то есть на необходимость проверки поля Sequence Number. Если услуга используется, то поле проверяется. Для этого, так же как и в AH, используется метод скользящего окна. Приёмный IPsec-модуль формирует окно с шириной W. Левый край окна соответствует минимальному последовательному номеру (Sequence Number) N правильно принятого пакета. Пакет с полем Sequence Number, в котором содержится значение, начиная от N+1 и заканчивая N+W, принимается корректно. Если полученный пакет оказывается по левую границу окна- он уничтожается. Затем, если используется услуга аутентификации, приёмный IPsec-модуль вычисляет ICV по соответствующим полям принятого пакета, используя алгоритм аутентификации, который он узнает из записи об SA, и сравнивает полученный результат со значением ICV, расположенным в поле «Integrity Check Value». Если вычисленное значение ICV совпало с принятым, то пришедший пакет считается действительным. Если проверка дала отрицательный результат, то приёмный пакет уничтожается. Далее производится расшифрование пакета. Приёмный IPsec-модуль узнает из записи об SA, какой алгоритм шифрования используется и секретный ключ. Надо заметить, что проверка контрольной суммы и процедура расшифрования могут проводиться не только последовательно, но и параллельно. В последнем случае процедура проверки контрольной суммы должна закончиться раньше процедуры расшифрования, и если проверка ICV провалилась, процедура расшифрования так же должна прекратиться. Это позволяет быстрее выявлять испорченные пакеты, что, в свою очередь, повышает уровень защиты от атак типа «отказ в обслуживании» ([[DoS-атака|DOS-атаки]]). Далее расшифрованное сообщение в соответствии с полем ''Next Header'' передается для дальнейшей обработки.

== IKE ==
{{main|IKE}}

IKE (произносится ''айк'', [[аббревиатура|аббр.]] от Internet Key Exchange) — протокол, связывающий все компоненты IPsec в работающее целое. В частности, IKE обеспечивает первоначальную аутентификацию сторон, а также их обмен [[Ключ (криптография)#Классификация ключей|общими секретными ключами]].

Существует возможность вручную установить ключ для сессии (не путать с pre-shared key [PSK] для аутентификации). В этом случае IKE не используется. Однако этот вариант не рекомендуется и используется редко. Традиционно IKE работает через порт 500 [[UDP]].

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

=== Первая фаза ===

IKE создает безопасный канал между двумя узлами, называемый IKE security association (IKE SA). Также в этой фазе два узла согласуют [[Ключ (криптография)#Классификация ключей|сессионный ключ]] по алгоритму [[Алгоритм Диффи — Хеллмана|Диффи-Хеллмана]]. Первая фаза IKE может проходить в одном из двух режимов{{sfn|Andrew Mason, IPSec Overview|2002|loc=Part Four: Internet Key Exchange (IKE)}}:
* Основной режим
*: Состоит из трёх двусторонних обменов между отправителем и получателем:
*:# Во время первого обмена согласуются алгоритмы и [[Хеширование#Виды хеш-функций|хеш-функции]], которые будут использоваться для защиты IKE соединения, посредством сопоставления IKE SA каждого узла.
*:# Используя алгоритм Диффи-Хеллмана, стороны вырабатывают общий секретный ключ для защиты данных во второй фазе. Также узлы проверяют [[Идентификация (информационные системы)|идентификацию]] друг друга путём передачи и подтверждения последовательности псевдослучайных чисел.
*:# По зашифрованному IP-адресу проверяется идентичность противоположной стороны. В результате выполнения основного режима создается безопасный канал для последующего [[ISAKMP]]-обмена (этот протокол определяет порядок действий для аутентификации соединения узлов, создания и управления SA, генерации ключей, а также уменьшения угроз, таких как [[DoS-атака]] или [[атака повторного воспроизведения]]).
* Агрессивный режим
*: Этот режим обходится меньшим числом обменов и, соответственно, числом пакетов. В первом сообщении помещается практически вся нужная для установления IKE SA информация: открытый ключ Диффи-Хеллмана для синхронизации пакетов, подтверждаемое другим участником, идентификатор пакета. Получатель посылает в ответ все, что надо для завершения обмена. Первому узлу требуется только подтвердить соединение.

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

=== Вторая фаза ===

В фазе два IKE существует только один, быстрый, режим. Быстрый режим выполняется только после создания безопасного канала в ходе первой фазы. Он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Использование последовательных номеров обеспечивает защиту от атак повторной передачи.
Также быстрый режим используется для пересмотра текущей IPsec SA и выбора новой, когда время жизни SA истекает. Стандартно быстрый режим проводит обновление общих секретных ключей, используя алгоритм Диффи-Хеллмана из первой фазы.

== Как работает IPsec ==

В работе протоколов IPsec можно выделить пять этапов{{sfn|Andrew Mason, IPSec Overview|2002|loc=How IPSec works}}:
# Первый этап начинается с создания на каждом узле, поддерживающем стандарт IPsec, политики безопасности. На этом этапе определяется, какой трафик подлежит шифрованию, какие функции и алгоритмы могут быть использованы.
# Второй этап является по сути первой фазой IKE. Её цель — организовать безопасный канал между сторонами для второй фазы IKE. На втором этапе выполняются:
#* Аутентификация и защита идентификационной информации узлов
#* Проверка соответствий политик IKE SA узлов для безопасного обмена ключами
#* [[Протокол Диффи — Хеллмана|Обмен Диффи-Хеллмана]], в результате которого у каждого узла будет общий секретный ключ
#* Создание безопасного канала для второй фазы IKE
# Третий этап является второй фазой IKE. Его задачей является создание IPsec-туннеля. На третьем этапе выполняются следующие функции:
#* Согласуются параметры IPsec SA по защищаемому IKE SA каналу, созданному в первой фазе IKE
#* Устанавливается IPsec SA
#* Периодически осуществляется пересмотр IPsec SA, чтобы убедиться в её безопасности
#* (Опционально) выполняется дополнительный обмен Диффи-Хеллмана
# Рабочий этап. После создания IPsec SA начинается обмен информацией между узлами через IPsec-туннель, используются протоколы и параметры, установленные в SA.
# Прекращают действовать текущие IPsec SA. Это происходит при их удалении или при истечении времени жизни (определенное в SA в байтах информации, передаваемой через канал, или в секундах), значение которого содержится в SAD на каждом узле. Если требуется продолжить передачу, запускается фаза два IKE (если требуется, то и первая фаза) и далее создаются новые IPsec SA. Процесс создания новых SA может происходить и до завершения действия текущих, если требуется непрерывная передача данных.

== Использование ==
Протокол IPsec используется, в основном, для организации [[VPN|VPN-туннелей]]. В этом случае протоколы ESP и AH работают в режиме туннелирования. Кроме того, настраивая политики безопасности определенным образом, протокол можно использовать для создания [[Межсетевой экран|межсетевого экрана]]. Смысл межсетевого экрана заключается в том, что он контролирует и фильтрует проходящие через него пакеты в соответствии с заданными правилами. Устанавливается набор правил, и экран просматривает все проходящие через него пакеты. Если передаваемые пакеты попадают под действие этих правил, межсетевой экран обрабатывает их соответствующим образом<ref name="VPN+IPSec">[http://www.onlamp.com/pub/a/bsd/2002/12/12/FreeBSD_Basics.html?page=1 VPNs and IPSec Demystified] {{Wayback|url=http://www.onlamp.com/pub/a/bsd/2002/12/12/FreeBSD_Basics.html?page=1 |date=20110105174506 }}, Dru Lavigne, 2002.</ref>. Например, он может отклонять определенные пакеты, тем самым прерывая небезопасные соединения. Настроив политику безопасности соответствующим образом, можно, например, запретить веб-трафик. Для этого достаточно запретить отсылку пакетов, в которые вкладываются сообщения протоколов [[HTTP]] и [[HTTPS]]. IPsec можно применять и для защиты серверов — для этого отбрасываются все пакеты, кроме пакетов, необходимых для корректного выполнения функций сервера. Например, для Web-сервера можно блокировать весь трафик, за исключением соединений через 80-й порт протокола TCP или через порт TCP 443 в случаях, когда применяется [[HTTPS]]. 
[[Файл:1 IPSec VPN.jpg|thumb|IPsec_VPN|457x457пкс]]Пример<ref name="VPN+IPSec,_ru">[http://www.opennet.ru/docs/RUS/vpn_ipsec/ VPN и IPSec на пальцах] {{Wayback|url=http://www.opennet.ru/docs/RUS/vpn_ipsec/ |date=20130712023003 }}, opennet.ru</ref>:
С помощью IPsec здесь обеспечивается безопасный доступ пользователей к серверу. При использовании протокола ESP все обращения к серверу и его ответы шифруются. Однако за VPN-шлюзом (в домене шифрования) передаются открытые сообщения.

Другие примеры использования IPsec<ref name="examples">''Роман Луковников'', [http://www.xakep.ru/magazine/xs/072/010/1.asp Практическое применение IPSec] {{Wayback|url=http://www.xakep.ru/magazine/xs/072/010/1.asp |date=20130308051803 }}, журнал "Хакер"</ref>:
* шифрование трафика между файловым сервером и компьютерами в локальной сети, используя IPsec в транспортном режиме.
* соединение двух офисов с использованием IPsec в туннельном режиме.

== См. также ==

* [[IKE|Internet Key Exchange (IKE)]]

== Ссылки ==
* [http://www.ixbt.com/comm/ipsecure.shtml IPSec — протокол защиты сетевого трафика на IP-уровне.] iXBT.com
* [http://www.xakep.ru/magazine/xs/072/010/1.asp Практическое применение IPSec]
* [http://www.opennet.ru/docs/RUS/vpn_ipsec/ VPN и IPSec на пальцах]
* [http://www.osp.ru/win2000/2002/06/175580/ Защита частных портов с помощью IPSec]
* [http://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-2/security/configuration/guide/sc_c32/sc32ipsc.pdf Описание конфигурирования IPSec (cisco.com)]
* [http://www.windowsfaq.ru/content/view/661/90 Примеры использования технологии IPSec]
* [http://unixwiz.net/techtips/iguide-ipsec.html An Illustrated Guide to IPsec]{{ref|en}}

== Примечания ==
{{примечания}}

== Литература ==
* {{книга
 |автор         = {{nobr|Олифер В. Г.}},{{nobr|Олифер Н. П.}} 
 |часть         = Глава 24. Сетевая безопасность
 |ссылка часть  = 
 |заглавие      = Компьютерные сети. Принципы, технологии, протоколы
 |оригинал      = 
 |ссылка        = 
 |викитека      = 
 |ответственный = 
 |издание       = 4-е
 |место         = СПб
 |издательство  = Питер
 |год           = 2010
 |том           = 
 |страницы      = 887-902
 |страниц       = 944
 |серия         = 
 |isbn          = 978-5-49807-389-7, ББК 32.973.202я7
 |тираж         = 
 |ref           = Олифер
}}
* {{статья

 |автор        = Andrew Mason.
 |заглавие     = [http://www.ciscopress.com/articles/article.asp?p=25470 IPSec Overview]
 |издательство = Cisco Press
 |год          = 2002
 |ref          = Andrew Mason, IPSec Overview
}}
{{VPN}}
{{IPstack}}

[[Категория:Сетевые протоколы]]
[[Категория:VPN]]
[[Категория:Интернет-протоколы]]
[[Категория:Протоколы туннелирования]]