о ESP, так як аутентифікація і шифрування в цьому варіанті не охоплює IP заголовок, модифікується NAT. Незважаючи на це, NAT створює певні проблеми і для ESP. Протокол NAT транслює IP адреси на прольоті - Але він повинен відслідковувати те, з яким з'єднанням відбувається робота, щоб коректно пов'язувати відгуки з джерелом пакетів. При використанні TCP або UDP, це зазвичай робиться із залученням номерів порту, але IPsec не залишає такої можливості. На перший погляд можна припустити, що для вирішення проблеми можна використовувати ідентифікатор SPI, але так як SPI відрізняються для різних напрямків обміну, для влаштування NAT немає способу зв'язати повертаний пакет з конкретним з'єднанням. Протокол ESP є протоколом захисту, що забезпечує конфіденційність (тобто шифрування), аутентифікацію джерела і цілісність даних, а також (як опція) сервіс захисту від відтворення і обмежену конфіденційність трафіку шляхом протидії спробам аналізу потоку даних.
Протокол ESP забезпечує конфіденційність за допомогою шифрування на рівні пакетів IP. При цьому підтримується безліч алгоритмів симетричною схеми шифрування, наприклад DES, triple-DES, AES і Blowfish для шифрування поля даних. Алгоритм, використовуваний для конкретного з'єднання, специфицируется асоціацією безпеки SA, SA включає в себе не тільки алгоритм, але і використовуваний ключ.
На відміну від протоколу AH, який вводить невеликої заголовок перед полем даних, ESP" оточує защищаемое поле даних. Поля індекс параметрів безпеки (Security Parameters Index) і номер по порядку служать для тих же цілей, що і у разі AH, але в ESP є також поля заповнювача, наступного заголовка, і опційно аутентифікаційних даних в кінці, в хвостовику ESP. Формат ESP-пакета розглянуто на малюнку 2.7
Малюнок 2.7 - Формат ESP-пакети без аутентифікації
Можливе використання ESP без якого-небудь шифрування (щоб застосувати NULL алгоритм). Цей режим не забезпечує конфіденційності, і його має сенс використовувати в поєднанні з аутентифікацією ESP. Неефективно використовувати ESP без шифрування або аутентифікації (якщо тільки це не робиться для тестування протоколу).
Крім шифрування, ESP може опціонально надавати можливість аутентифікації, з залучення алгоритму HMAC. На відміну від AH, однак, ця аутентифікація проводиться тільки для ESP заголовка і зашифрованого поля даних. При цьому не перекривається весь IP пакет. Це не суттєво послаблює безпеку аутентифікації, але дає деякі важливі переваги.
Коли сторонній розглядає IP пакет, що містить дані ESP, принципово неможливо визначити IP адреси відправника і одержувача, порушник, звичайно, дізнається, що це ESP дані (це видно із заголовка пакета), але тип поля даних і самі дані зашифровані.
Дивлячись на сам пакет, неможливо навіть визначити, чи присутні чи ні аутентифіковані дані (це можна зробити лише, використовуючи індекс параметрів безпеки).
Як і у випадку AH, транспортний режим передбачає інкапсуляцію поля даних дейтограмм, і протокол орієнтований на обмін машина-машина. Вихідний IP заголовок залишений на місці (за винятком заміненого поля протокол), і це означає, що адреси відправника і одержувача також залишаються незміненими [9] .в тунельному режимі проводить інкапсуляцію всій IP-дейтограмми всередину зашифрованою оболонки.
Реалізація шифрованого з'єднання в тунельному режимі дуже близька до традиційних VPN.
На відміну від AH, де спостерігач може легко сказати, відбувався обмін в тунельному або транспортному режимі, тут ця інформація недоступна. Це відбувається через те, що вказівка ??на те, що наступний заголовок є IP, знаходиться в зашифрованому поле даних і, тому не видно для учасника, нездатного дешифрувати пакет [10] .опірается на ряд технологічних рішень і методів шифрування яке можна представити в вигляді наступних головних кроків:
Крок 1. Початок процесу IPSec. Трафік, якому потрібно шифрування у відповідності з політикою захисту IPSec, узгодженої сторонами IPSec, починає IКЕ-процес.
Крок 2. Перша фаза IKE. IKE-процес виконує аутентифікацію сторін IPSec і веде переговори про параметри асоціацій захисту IKE, в результаті чого створюється захищений канал для ведення переговорів про параметри асоціацій захисту IPSec в ході другої фази IKE.
Крок 3. Друга фаза IKE. IKE-процес веде переговори про параметри асоціації захисту IPSec і встановлює відповідні асоціації захисту IPSec для пристроїв сполучених сторін.
Крок 4. Передача даних. Відбувається обмін даними між сполученими сторонами IPSec, який грунтується на параметрах IPSec і ключах, що зберігаються в базі даних асоціацій захисту.
Крок 5. Завершення роботи тунелю IPSec. А...
