рці ICV одержувачем. Так як обчислення ICV вимагає знання секретного ключа, який невідомий проміжним вузлам, маршрутизатор NAT не зможе заново обчислити ICV.
Аналогічна проблема виникає при використанні протоколу PAT (Port Address Translation), який встановлює відповідність кількох приватних IP адрес одному зовнішньому IP. У цьому випадку змінюються не тільки IP-адреси. Але й коди портів в UDP і TCP пакетах (а іноді і в полі даних). Це вимагає багато більшою адаптивності з боку пристрою NAT, і більш серйозних модифікацій всій IP дейтограмми. З цієї причини, протокол AH в тунельному або транспортному режимі повністю несумісний з NAT. Зауважимо, що ця трудність не відноситься до 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. Пе...
