IPsec (IP security)- Набір протоколів для безпечної передачі трафіку через IP мережу. Мабуть, найскладніший і найрозгалуженіший стек протоколів із підтримуваних системою VPNKI.

Включає три основні протоколи:

• AH (Authentication Header) - управління цілісністю переданих даних та аутентифікацію

• ESP (Encapsulating Security Payload) – шифрування даних

• ISAKMP (Internet Security Association and Key Management Protocol) - управління установкою з'єднання, взаємну аутентифікацію кінцевими вузлами один одного та обмін секретними ключами

Основні порти та номери протоколів

• Протокол UDP, port 500 (IKE, керування ключами)
• Протокол UDP, port 4500 (IPSEC NAT-Traversal mode)
• Протокол ESP, значення 50 (for IPSEC)
• Протокол AH, значення 51 (for IPSEC)

Взагалі, набір протоколів IPsec непростий з погляду можливостей його використання, які дуже багатогранні. Однак, базовою особливістю всієї взаємодії цього протоколу є поняття SA (Security Association) - це набір параметрів про те як сторони будуть надалі використовувати ті чи інші властивості протоколів зі складу IPsec.

Варто ще згадати про два основні режими роботи IPsec – тунельний та транспортний. Грубо кажучи, в транспортному режимі шифруються лише корисні дані IP пакета, а в тунельному режимі шифрується всі дані, включаючи заголовки IP.

Аутентифікація

Взаємодія двох вузлів починається із встановлення SA. Точніше з двох асоціацій - для протоколу AH та ESP причому в одну та в іншу сторони. SA починається з аутентифікації, а потім сторони узгоджують майбутні параметри сесії:

• для протоколу AH - алгоритм автентифікації, що використовується, ключі, час життя ключів та інші параметри,
• для протоколу ESP – алгоритми шифрування та аутентифікації, ключі, параметри ініціалізації, час життя ключів та інші параметри.

Тут же сторони домовляються про тунельний або транспортний режим роботи IPsec.

До завершення процесу ви повинні встановити кілька SA, але... трохи докладніше як це насправді.

Фаза 1 та Фаза 2

В IPsec все відбувається за Фазами.

На фазі 1 відбувається встановлення першої SA фази. У першій фазі сторони домовляються про метод ідентифікації, алгоритм шифрування, алгоритм хеширування та групу Diffie Hellman. Ця фаза може пройти шляхом обміну трьома нешифрованими пакетами (агресивний режим) або шістьма нешифрованими пакетами – стандартний режим. Якщо все пройшло успішно, створюється SA фази 1 під назвою IKE SA і здійснюється перехід до другої фази.

На фазі 2 сторони домовляються про політику та створюються самі ключі. Ця фаза, на відміну першої повністю шифрується і вона настає лише разі успішного закінчення першої фази. У зв'язку з тим, що трафік цієї фази повністю шифрований стає складно здійснювати пошук неполадок, проте якщо все пройшло успішно, то створюється фази SA 2 під назвою IPSec SA. У цей момент можна сказати, що тунель встановлено.

Компресія даних

У складі IPsec немає власного механізму компресії дані, проте можна використовувати механізм IPcomp, який компресує вміст IP пакета до його передачі в процес IPsec. Деякі демони IPsec підтримують увімкнення цього механізму з файлів налаштувань ipsec.conf (наприклад, пакет Strongswan)

Автоматична перевірка працездатності VPN з'єднання

Усередині IPsec немає штатного засобу перевірки працездатності з'єднання (типу ping), тому роботу тунелю можна перевіряти зовнішніми засобами.

Розрив VPN з'єднання та зміна ключів

Узгоджені на двох фазах ключі мають працювати обумовлений політикою час. Це означає, що сторони можуть пережити процедуру зміни ключів (rekeying), а інакше узгоджені SA розпадуться. Як було сказано вище, сторони мають ключі в рамках процесу фази 1 (IKE) і фази 2 (IPsec). Процедури їхньої зміни різні, як і таймери, які за це відповідають. Для того, щоб не було перерви зв'язку в процесі зміни ключів сторони, спочатку узгоджують параметри нової SA і лише після цієї успішної процедури знищують стару SA.

У IPsec на кожній із фаз є кілька способів зміни ключів - з автентифікацією або без неї, але ми не будемо сильно загострювати на цьому свою увагу. Просто для цієї процедури занадто багато нюансів, які залежать від версій ПЗ і співвідношення таймерів - для IKE і IPsec.

0 У цій статті пропонується огляд засобів IPSEC (IP Security – система захисту на рівні IP) та відповідних протоколів IPSec, доступних у продуктах Cisco та використовуваних для створення віртуальних приватних мереж (VPN). У цій статті ми визначимо, що таке IPSEC, а також які протоколи та алгоритми захисту лежать в основі IPSEC.

Вступ

IP Security - це комплект протоколів, що стосуються питань шифрування, автентифікації та забезпечення захисту під час транспортування IP-пакетів; до його складу зараз входять майже 20 пропозицій щодо стандартів та 18 RFC.

Продукти Cisco для підтримки VPN використовують набір протоколів IPSec, що на сьогодні є промисловим стандартом забезпечення широких можливостей VPN. IPSec пропонує механізм захищеної передачі в IP-мережах, забезпечуючи конфіденційність, цілісність і достовірність даних, переданих через незахищені мережі типу Internet. IPSec забезпечує такі можливості VPN у мережах Cisco:

• Конфіденційність даних. Відправник даних IPSec може шифрувати пакети перед тим, як передавати їх по мережі.
• Цілісність даних. Отримувач даних IPSec має можливість аутентифікувати сполучені з ним сторони (пристрої або програмне забезпечення, в яких починаються і закінчуються тунелі IPSec) і пакети IPSec, що надсилаються цими сторонами, щоб бути впевненим у тому, що дані не були змінені в дорозі.
• Аутентифікація джерела даних. Отримувач даних IPSec має можливість аутентифікувати джерело одержуваних пакетів IPSec. Цей сервіс залежить від сервісу цілісності даних.
• Захист від відтворення. Одержувач даних IPSec може виявляти та відкидати відтворені пакети, не допускаючи їх фальсифікації та проведення атак впровадження посередника.

IPSec є заснований на стандартах набір протоколів і алгоритмів захисту. Технологія IPSec та пов'язані з нею протоколи захисту відповідають відкритим стандартам, які підтримуються групою IETF (Internet Engineering Task Force – проблемна група проектування Internet) та описані у специфікаціях RFC та проектах IETF. IPSec діє на мережному рівні, забезпечуючи захист та автентифікацію пакетів IP, що пересилаються між пристроями (сторонами) IPSec - такими як маршрутизатори Cisco, брандмауери PIX Firewall, клієнти та концентратори Cisco VPN, а також багато інших продуктів, що підтримують IPSec. Засоби підтримки IPSec допускають масштабування від найменших до великих мереж.

Асоціації захисту (Security Association, SA)

IPSec пропонує стандартний спосіб аутентифікації та шифрування з'єднань між сторонами, що повідомляються. Щоб забезпечити захист зв'язків, засоби IPSec використовують стандартні алгоритми (тобто математичні формули) шифрування та аутентифікації, які називаються перетвореннями. В IPSec використовуються відкриті стандарти узгодження ключів шифрування та керування з'єднаннями, що забезпечує можливість взаємодії між сторонами. Технологія IPSec пропонує методи, що дозволяють сторонам IPSec домовитися про узгоджене використання сервісів. Щоб вказати узгоджені параметри, IPSec використовується асоціації захисту.

Асоціація захисту(Security Association - SA) являє собою узгоджену політику або спосіб обробки даних, обмін якими передбачається між двома пристроями сполучених сторін. Однією із складових такої політики може бути алгоритм, який використовується для шифрування даних. Обидві сторони можуть використовувати один і той самий алгоритм як для шифрування, так і для дешифрування. Параметри SA, що діють, зберігаються в базі даних асоціацій захисту (Security Association Database - SAD) обох сторін.

Два комп'ютери на кожній стороні SA зберігають режим, протокол, алгоритми та ключі, що використовуються SA. Кожен SA використовується лише в одному напрямку. Для двонаправленого зв'язку потрібно два SA. Кожен SA реалізує один режим та протокол; таким чином, якщо для одного пакета необхідно використовувати два протоколи (наприклад AH і ESP), то потрібно два SA.

Протокол IKE (Internet Key Exchange – обмін Internet-ключами) є гібридним протоколом, який забезпечує спеціальний сервіс для IPSec, а саме автентифікацію сторін IPSec, узгодження параметрів асоціацій захисту IKE та IPSec, а також вибір ключів для алгоритмів шифрування, що використовуються в рамках IPSec. Протокол IKE спирається на протоколи ISAKMP (Internet Security Association and Key Management Protocol – протокол управління асоціаціями та ключами захисту в мережі Internet) та Oakley, які застосовуються для управління процесом створення та обробки ключів шифрування, що використовуються у перетвореннях IPSec. Протокол IKE застосовується також формування асоціацій захисту між потенційними сторонами IPSec.
Як IKE, так і IPSec використовують асоціації захисту, щоб вказати параметри зв'язку.
IKE підтримує набір різних примітивних функцій для використання у протоколах. Серед них можна виділити хеш-функцію та псевдовипадкову функцію (PRF).

Хеш-функція- Це функція, стійка до колізій. Під стійкістю до колізій розуміється той факт, що неможливо знайти два різні повідомлення m1 і m2, такі, що

H(m1)=H(m2), де H – хеш функція.

Що стосується псеводвипадкових функцій, то зараз замість спеціальних PRF використовується хеш функція в конструкції HMAC (HMAC - механізм автентифікації повідомлень з використанням хеш функцій). Для визначення HMAC нам знадобиться криптографічна хеш функція (позначимо її як H) та секретний ключ K. Ми припускаємо, що H є хеш функцією, де дані хешуються за допомогою процедури стиснення, що послідовно застосовується до послідовності блоків даних. Ми позначимо за B довжину таких блоків у байтах, а довжину блоків, отриманих у результаті хешування - як L (L
ipad = байт 0x36, повторений B разів;
opad = байт 0x5C, повторений B разів.

Для обчислення HMAC від даних "text" необхідно виконати таку операцію:

H(K XOR ipad, H(K XOR ipad, text))

З опису випливає, що IKE використовує для автентифікації сторін величини HASH. Зазначимо, що під HASH в даному випадку мається на увазі виключно назва Payload в ISAKMP, і ця назва не має нічого спільного зі своїм вмістом

Інфраструктура IPSec

Мережі VPN на основі IPSec можуть бути побудовані за допомогою різних пристроїв Cisco - маршрутизаторів Cisco, брандмауерів CiscoSecure PIX Firewall, програмного забезпечення клієнта CiscoSecure VPN і концентраторів Cisco VPN серій 3000 і 5000. Маршрутизатори Cisco мають вбудовану підтримку VPN з відповідними багатими IOS, що зменшує складність мережевих рішень та знижує загальну вартість VPN при можливості побудови багаторівневого захисту сервісів, що надаються. Брандмауер PIX Firewall є високопродуктивним мережевим пристроєм, який може обслуговувати кінцеві точки тунелів, забезпечуючи їм високу пропускну здатність та чудові функціональні можливості брандмауера. Програмне забезпечення клієнта CiscoSecure VPN підтримує найсуворіші вимоги VPN віддаленого доступу для операцій електронної комерції, а також додатків мобільного доступу, пропонуючи закінчену реалізацію стандартів IPSec та забезпечуючи надійну взаємодію маршрутизаторів Cisco та брандмауерів PIX Firewall.

Як працює IPSec

IPSec спирається на ряд технологічних рішень та методів шифрування, але дію IPSec загалом можна представити у вигляді наступних основних кроків:

• Крок 1. Початок процесу IPSec.Трафік, який потребує шифрування відповідно до політики захисту IPSec, узгодженої сторонами IPSec, починає IКЕ-процес.
• Крок 2. Перша фаза IKE. IKE процес виконує аутентифікацію сторін IPSec і веде переговори про параметри асоціацій захисту IKE, в результаті чого створюється захищений канал для ведення переговорів про параметри асоціацій захисту IPSec в ході другої фази IKE.
• Крок 3. Друга фаза IKE. IKE-процес веде переговори про параметри асоціації захисту IPSec та встановлює відповідні асоціації захисту IPSec для пристроїв сполучених сторін.
• Крок 4. Передача даних. Відбувається обмін даними між сторонами, що повідомляються IPSec, який базується на параметрах IPSec і ключах, що зберігаються в базі даних асоціацій захисту.
• Крок 5. Завершення роботи тунелю IPSec. Асоціації захисту IPSec завершують свою роботу або в результаті їх видалення, або через перевищення граничного часу їх існування.

У наступних розділах ці кроки будуть описані докладніше.

(The Internet Key Exchange (IKE)) - Обмін ключами.

RFC 2410 (Null Encryption Algorithm and Its Use With IPsec) - Нульовий алгоритм шифрування та його використання.

RFC 2411 (IP Security Document Roadmap) - Подальший розвиток стандарту.

RFC 2412 (The OAKLEY Key Determination Protocol) - Перевірка відповідності ключа.

Архітектура IPsec

Протоколи IPsec, на відміну інших добре відомих протоколів SSL і TLS , працюють на мережному рівні (рівень 3 моделі OSI). Це робить IPsec більш гнучким, тому він може використовуватися для захисту будь-яких протоколів, що базуються на TCP і UDP . IPsec може використовуватися для забезпечення безпеки між двома IP-вузлами, між двома шлюзами безпеки або між IP-вузлом та шлюзом безпеки. Протокол є надбудовою над IP-протоколом, і обробляє сформовані IP-пакети описаним нижче способом. IPsec може забезпечувати цілісність та/або конфіденційність даних, що передаються по мережі.

IPsec використовує такі протоколи для виконання різних функцій:

• Authentication Header (АН) забезпечує цілісність віртуального з'єднання (переданих даних), аутентифікацію джерела інформації та додаткову функцію щодо запобігання повторній передачі пакетів
• Encapsulating Security Payload (ESP) може забезпечити конфіденційність (шифрування) інформації, що передається, обмеження потоку конфіденційного трафіку. Крім цього, він може забезпечити цілісність віртуального з'єднання (переданих даних), автентифікацію джерела інформації та додаткову функцію щодо запобігання повторній передачі пакетів (Кожного разу, коли застосовується ESP, в обов'язковому порядку повинен використовуватися той чи інший набір даних послуг із забезпечення безпеки)
• Security Association (SA) забезпечують зв'язок алгоритмів та даних, які надають параметри, необхідні для роботи AH та/або ESP. Internet Security Association and Key Management Protocol (ISAKMP) забезпечує основу для аутентифікації та обміну ключами, автентифікації ключів.

Security Association

Концепція "Захищеного віртуального з'єднання" (SA, "Security Association") є фундаментальною в архітектурі IPsec. SA являє собою симплексне з'єднання, яке формується для транспортування по ньому відповідного трафіку. При реалізації послуг безпеки формується SA з урахуванням використання протоколів AH чи ESP (або обох одночасно). SA визначено відповідно до концепції міжтермінального з'єднання (point-to-point) та може функціонувати у двох режимах: транспортний режим (РТР) та режим тунелювання (РТУ). Транспортний режим реалізується за умови SA між двома IP-вузлами. У режимі тунелювання SA формує IP-тунель.

Усі SA зберігаються у базі даних SADB (Security Associations Database) IPsec-модуля. Кожне SA має унікальний маркер, що складається із трьох елементів:

• індексу параметра безпеки (SPI)
• IP-адреси призначення
• ідентифікатора протоколу безпеки (ESP або AH)

IPsec-модуль, маючи ці три параметри, може знайти в SADB запис про конкретний SA. До списку компонентів SA входять:

Послідовний номер 32-бітове значення, яке використовується для формування поля Sequence Numberу заголовках АН та ESP. Переповнення лічильника порядкового номераПрапор, який сигналізує про переповнення лічильника номера послідовного. Вікно для придушення атак відтворенняВикористовується для визначення повторної передачі пакетів. Якщо значення у полі Sequence Numberне потрапляє в заданий діапазон, пакет знищується. Інформація AHвикористовується алгоритм аутентифікації, необхідні ключі, час життя ключів та інші параметри. Інформація ESPалгоритми шифрування та аутентифікації, необхідні ключі, параметри ініціалізації (наприклад, IV), час життя ключів та інші параметри Режим роботи IPsecтунельний або транспортний MTUМаксимальний розмір пакета, який можна передати віртуальним каналом без фрагментації.

Оскільки захищені віртуальні сполуки (SA) є симплексними , то організації дуплексного каналу, як мінімум, потрібні два SA. Крім цього, кожен протокол (ESP/AH) повинен мати свою власну SA для кожного напряму, тобто зв'язування AH+ESP вимагає наявності чотирьох SA. Всі ці дані розміщуються в SADB.

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

Крім бази даних SADB, реалізації IPsec підтримують базу даних SPD (Security Policy Database-База даних політик безпеки). Запис SPD складається з набору значень полів IP-заголовка і полів заголовка протоколу верхнього рівня. Ці поля називаються селекторами. Селектори використовуються для фільтрації вихідних пакетів, з метою поставити кожен пакет у відповідність до певного SA. Коли формується пакет, порівнюються значення відповідних полів у пакеті (селекторні поля) з тими, що містять SPD. Знаходяться відповідні SA. Потім визначається SA (у разі, якщо воно є) для пакета і пов'язаний з нею індекс параметрів безпеки (SPI). Після цього виконуються операції IPsec (операції протоколу AH чи ESP).

Приклади селекторів, які містяться у SPD:

• IP-адреса призначення
• IP-адреса відправника
• Протокол IPsec (AH, ESP або AH+ESP)
• Порти відправника та одержувача

Authentication Header

Authentication Header format

Offsets	Octet 16	0								1								2								3
Octet 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Next Header								Payload Len								Reserved
4	32
8	64	Sequence Number
C	96	Integrity Check Value (ICV) …
…	…

Next Header(8 bits) Тип заголовка протоколу, що йде після заголовка AH. За цим полем приймальний IP-sec модуль дізнається про протокол, що захищається верхнього рівня. Значення цього поля для різних протоколів можна переглянути в RFC 1700 . Payload Len(8 bits) Це поле визначає загальний розмір АН-заголовка в 32-бітових словах мінус 2. Незважаючи на це, при використанні IPv6 довжина заголовка повинна бути кратна 8 байтам. Reserved(16 bits) Зарезервовано. Заповнюється нулями. Security Parameters Index(32 bits) Індекс параметрів безпеки. Значення цього поля разом з IP-адресою одержувача та протоколом безпеки (АН-протокол) однозначно визначає захищене віртуальне з'єднання (SA) для цього пакета. Діапазон значень SPI 1…255 зарезервований IANA. Sequence Number(32 bits) Послідовний номер. Для захисту від повторної передачі. Поле містить монотонно зростаюче значення параметра. Незважаючи на те, що одержувач може відмовитися від послуги захисту від повторної передачі пакетів, воно є обов'язковим і завжди присутній в AH-заголовку. IPsec-модуль, що передає, завжди використовує це поле, але одержувач може його і не обробляти. Integrity Check Value

Протокол AH використовується для аутентифікації, тобто для підтвердження того, що ми зв'язуємося саме з тим, з ким припускаємо, і дані, які ми отримуємо, не спотворені при передачі.

Обробка вихідних 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-пакету:

• поля 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) SADB (Security Associations Database), використовуючи IP-адресу одержувача, протокол безпеки (АН) та індекс SPI. Якщо відповідний SA не знайдено, пакет знищується. Знайдене захищене віртуальне з'єднання (SA) вказує на те, чи використовується послуга запобігання повторній передачі пакетів, тобто. на необхідність перевірки поля Sequence Number. Якщо послуга використовується, поле перевіряється. Для цього використовується метод ковзного вікна. Приймальний IPsec-модуль формує вікно із шириною W. Лівий край вікна відповідає мінімальному послідовному номеру( Sequence Number) N правильно прийнятого пакета. Пакет із полем Sequence Number, В якому міститься значення, починаючи від N+1 і закінчуючи N+W, приймається коректно. Якщо отриманий пакет виявляється по ліву межу вікна, він знищується. Потім приймальний IPsec-модуль обчислює ICV по відповідним полям прийнятого пакета, використовуючи алгоритм аутентифікації, який він дізнається із запису про SA, і порівнює отриманий результат значення ICV, розташованим в полі "Integrity Check Value". Якщо обчислене значення ICV збіглося з прийнятим, то пакет вважається дійсним і приймається для подальшої IP-обробки. Якщо перевірка дала негативний результат, приймальний пакет знищується.

Encapsulating Security Payload format

Offsets	Octet 16	0								1								2								3
Octet 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Security Parameters Index (SPI)
4	32	Sequence Number
8	64	Payload data
…	…
…	…
…	…									Padding (0-255 octets)
…	…																	Pad Length								Next Header
…	…	Integrity Check Value (ICV) …
…	…

Security Parameters Index(32 bits) Індекс параметрів безпеки. Значення цього поля разом з IP-адресою одержувача та протоколом безпеки (АН-протокол) однозначно визначає захищене віртуальне з'єднання (SA) для цього пакета. Діапазон значень SPI 1...255 зарезервований IANA для подальшого використання. Sequence Number(32 bits) Послідовний номер. Для захисту від повторної передачі. Поле містить монотонно зростаюче значення параметра. Незважаючи на те, що одержувач може і відмовитися від послуги захисту від повторної передачі пакетів, воно завжди присутнє в AH-заголовку. Відправник (передаючий IPsec-модуль) повинен завжди використовувати це поле, але одержувач може і не потребувати його обробки. Payload data(variable) Це поле містить дані відповідно до поля "Next Header". Це поле обов'язкове і складається з цілого числа байтів. Якщо алгоритм, який використовується для шифрування цього поля, вимагає даних для синхронізації криптопроцесів (наприклад, вектор ініціалізації - "Initialization Vector"), це поле може містити ці дані в явному вигляді. Padding(0-255 octets) Доповнення. Необхідно, наприклад, для алгоритмів, які вимагають, щоб відкритий текст був крадений деякому числу байтів), наприклад, розмір блоку для блокового шифру. Pad Length(8 bits) Розмір доповнення (в байтах). Next Header(8 bits) Це поле визначає тип даних, які у полі " Payload data " . Integrity Check ValueКонтрольна сума. Повинна бути кратна 8-байтам для IPv6, і 4-байтам для IPv4.

Обробка вихідних IPsec-пакетів

Якщо передавальний IPsec-модуль визначає, що пакет пов'язаний з SA, яке передбачає ESP-обробку, він починає обробку. Залежно від режиму (транспортний або тунелювання) вихідний IP-пакет обробляється по-різному. У транспортному режимі передавальний IPsec-модуль здійснює процедуру обрамлення (інкапсуляції) протоколу верхнього рівня (наприклад, TCP або UDP), використовуючи для цього ESP-заголовок і ESP-кінцевик, не торкаючись при цьому заголовок вихідного IP-пакета. У режимі тунелювання IP-пакет обрамляється ESP-заголовком та ESP-кінцем, після чого обрамляється зовнішнім IP-заголовком. Далі проводиться шифрування - у транспортному режимі шифрується тільки повідомлення протоколу вище лежачого рівня (тобто все, що знаходилося після IP-заголовка у вихідному пакеті), в режимі тунелювання - весь вихідний IP-пакет. Передавальний IPsec-модуль із запису про SA визначає алгоритм шифрування та секретний ключ. Стандарти IPsec дозволяють використовувати алгоритми шифрування triple-DES, AES і Blowfish. Так як розмір відкритого тексту повинен бути кратний певному числу байт, наприклад, розмір блоку для блокових алгоритмів, перед шифруванням проводиться ще і необхідне доповнення повідомлення, що шифрується. Защифроване повідомлення розміщується в полі Payload Data. В полі Pad Lengthміститься довжина доповнення. Потім, як і в AH, обчислюється Sequence Number. Після цього вважається контрольна сума (ICV). Контрольна сума, на відміну від протоколу AH, де при її обчисленні враховуються також і деякі поля IP-заголовка, ESP обчислюється тільки по полях ESP-пакету за вирахуванням поля ICV. Перед обчисленням контрольної суми воно заповнюється нулями. Алгоритм обчислення ICV, як і в протоколі AH, передавальний IPsec-модуль дізнається із запису про SA, з яким пов'язаний пакет, що обробляється.

Обробка вхідних IPsec-пакетів

Після отримання пакета, що містить повідомлення ESP-протоколу, приймальний IPsec-модуль шукає відповідне захищене віртуальне з'єднання (SA) в SADB (Security Associations Database), використовуючи IP-адресу одержувача, протокол безпеки (ESP) та індекс SPI. Якщо відповідний 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-атаки). Далі розшифроване повідомлення відповідно до поля Next Headerпередається для подальшої обробки.

Використання

Протокол IPsec використовується в основному для організації VPN-тунелів. У цьому випадку протоколи ESP та AH працюють у режимі тунелювання. Крім того, налаштування політики безпеки певним чином протокол можна використовувати для створення міжмережевого екрану. Сенс міжмережевого екрану полягає в тому, що він контролює і фільтрує пакети, що проходять через нього, відповідно до заданих правил. Встановлюється набір правил, і екран переглядає всі пакети, що проходять через нього. Якщо пакети, що передаються, потрапляють під дію цих правил, міжмережевий екран обробляє їх відповідним чином. Наприклад, він може відхиляти певні пакети, тим самим припиняючи небезпечні з'єднання. Налаштувавши політику безпеки відповідно, можна, наприклад, заборонити інтернет-трафік. Для цього достатньо заборонити відсилання пакетів, в які вкладаються повідомлення HTTP і HTTPS. IPsec можна використовувати і захисту серверів - для цього відкидаються всі пакети, крім пакетів, необхідні коректного виконання функцій сервера. Наприклад, для Web-сервера можна блокувати весь трафік, за винятком з'єднань через 80-й порт протоколу TCP або через порт TCP 443 у випадках, коли застосовується HTTPS .

Див. також

Посилання

• Опис конфігурування IPSec (cisco.com) (англ.)

Віртуальні приватні мережі (VPN)
Програмне забезпечення	Chaply Check Point VPN-1 Cisco Systems VPN Client CloudVPN CryptoLink Gbridge Hamachi Jabpunch Microsoft Forefront Unified Access Gateway n2n NetworkManager OpenVPN Openswan pLan OpenVPN Edition (ZeroGC Gaming Client) rp-pppoe Social VPN strongSwan Tinc tcpcrypt Vyatta Wippien
Механізми
Керовані постачальником

Механізми безпеки в

IPsec являє собою не один протокол, а систему протоколів, призначену для захисту даних на мережевому рівні IP-мереж. У цій статті буде описано теорію застосування IPsec для створення VPN тунелю.

Вступ

VPN, заснований на технології IPsec, можна розділити на дві частини:

• Протокол Internet Key Exchange (IKE)
• Протоколи IPsec (AH/ESP/both)

Перша частина (IKE) є фазою узгодження, під час якої дві VPN-точки вибирають які методи будуть використовуватися для захисту IP трафіку, що посилається між ними. Крім цього, IKE також використовується для управління з'єднаннями, для цього вводиться поняття Security Associations (SA) для кожного з'єднання. SA спрямовані лише в одну сторону, тому типове IPsec з'єднання використовує два SA.

Друга частина – це ті IP дані, які необхідно зашифрувати та аутентифікувати перед передачею методами, узгодженими у першій частині (IKE). Існують різні протоколи IPsec, які можна використовувати: AH, ESP чи обидва.

Послідовність встановлення VPN через IPsec можна коротко описати як:

• IKE узгоджує захист рівня IKE
• IKE узгоджує захист рівня IPsec
• дані, що захищаються передаються через VPN IPsec

IKE, Internet Key Exchange

Для шифрування та аутентифікації даних потрібно вибрати спосіб шифрування/аутентифікації (алгоритм) та ключі, що використовуються в них. Завдання Internet Key Exchange protocol, IKE, у разі зводиться до поширення даних “ключів сесії” і узгодження алгоритмів, якими захищатимуться дані між VPN-точками.

Основні завдання IKE:

• Аутентифікація VPN-крапок один одного
• Організація нових IPsec з'єднань (через створення SA пар)
• Управління поточними з'єднаннями

IKE веде облік з'єднань шляхом призначення кожному з них Security Associations, SA. SA описує параметри конкретного з'єднання, включаючи протокол IPsec (AH/ESP або обидва), ключі сесії, які використовуються для шифрування/дешифрування та/або аутентифікації даних. SA є односпрямованою, тому використовується кілька SA на одне з'єднання. У більшості випадків, коли використовується тільки ESP або AH, створюються лише дві SA для кожного з підключень, одна для вхідного трафіку, а друга для вихідного. Коли ESP та AH використовуються разом, SA потрібно чотири.

Процес узгодження IKE відбувається через кілька етапів (фаз). Дані фази включають:

1. IKE першої фази (IKE Phase-1):
   - Узгоджується захист самого IKE (ISAKMP tunnel)
2. IKE другої фази (IKE Phase-2):
   — Узгоджується захист IPsec
   — Отримання даних із першої фази для формування ключів сесії

З'єднання IKE і IPsec обмежені за тривалістю (у секундах) і за кількістю переданих даних (у кілобайтах). Це зроблено підвищення захищеності.
Тривалість IPsec підключення, як правило, коротша за IKE. Тому коли закінчується термін IPsec з'єднання, нове IPsec з'єднання перетворюється через другу фазу узгодження. Перша фаза узгодження використовується лише при перестворенні IKE підключення.

Для узгодження IKE вводиться поняття IKE пропозиція (IKE Proposal) – це пропозиція, як захистити дані. VPN-точка ініціалізує IPsec підключення відправляє список (пропозиція), в якому вказані різні методи захисту підключення.
Переговори можуть вестись як про встановлення нового IPsec з'єднання, так і про встановлення нового IKE з'єднання. У випадку IPsec захищеними даними є той трафік, який відправлений через VPN-тунель, а у випадку IKE дані, що захищаються - дані самих погоджень IKE.
VPN-точка, що отримала список (пропозиція), вибирає з нього найбільш відповідне і вказує його у відповіді. Якщо жодна з пропозицій не може бути обрана, VPN шлюз відповідає відмовою.
Пропозиція містить всю необхідну інформацію для вибору алгоритму шифрування та автентифікації та ін.

IKE першої фази - узгодження захисту IKE (ISAKMP Tunnel)
На першій фазі узгодження VPN-точки аутентифікують один одного на основі загального ключа (Pre-Shared Key). Для аутентифікації використовують хеш алгоритм: MD5, SHA-1, SHA-2.
Однак перед тим як аутентифікувати один одного, щоб не передавати інформацію відкритим текстом, точки VPN виконують обмін списками пропозицій (Proposals), описаний раніше. Тільки після того, як пропозиція обрана, що влаштовує обох VPN-точок, відбувається автентифікація VPN-точка один одного.
Аутентифікацію можна здійснювати у різний спосіб: через загальні ключі (Pre-Shared Keys), сертифікати або . Загальні ключі є найпоширенішим способом автентифікації.
Узгодження IKE першої фази може відбуватися в одному з двох режимів: main (основний) та aggressive (агресивний). Основний режим більш тривалий, зате і захищений. У його процесії відбувається обмін шістьма повідомленнями. Агресивний режим відбувається швидше, обмежуючись трьома повідомленнями.
Основна робота першої фази IKE лежить в обміні ключами Діффі-Хеллмана. Він заснований на шифруванні з відкритим ключем, кожна сторона шифрує автентифікаційний параметр (Pre-Shared Key) відкритим ключем сусіда, який отримавши це повідомлення розшифровує його своїм закритим ключем. Інший спосіб аутентифікації сторін один одного - використання сертифікатів.

IKE другої фази – узгодження захисту IPsec
У другій фазі здійснюється вибір способу захисту IPsec підключення.
Для другої фази використовується матеріал (keying material) вилучений з обміну ключами Діффі-Хеллмана (Diffie-Hellman key exchange), що відбувся на першій фазі. На основі цього матеріалу створюються ключі сесії (session keys), що використовуються для захисту даних у VPN-тунелі.

Якщо використовується механізм Perfect Forwarding Secrecy (PFS)Для кожного узгодження другої фази буде використовуватися новий обмін ключами Діффі-Хеллмана. Дещо знижуючи швидкість роботи, дана процедура гарантує, що ключі сесії не залежні один від одного, що підвищує захист, оскільки навіть якщо відбудеться компромат одного з ключів, він не зможе бути використаний для підбору інших.

Режим роботи другої фази узгодження IKE лише один, він називається quick mode – швидкий режим. У процесі узгодження другої фази відбувається обмін трьома повідомленнями.

Після закінчення другої фази встановлюється VPN-підключення.

Параметри IKE.
Під час встановлення з'єднання використовуються кілька параметрів, без узгодження яких неможливо встановити підключення VPN.

• Ідентифікація кінцевих вузлів
  Як вузли аутентифікують один одного. Найчастіше використовується загальний ключ. Аутентифікація, заснована на загальному ключі, використовує алгоритм Діффі-Хеллмана.
• Локальна та віддалена мережа/хост
  Визначає трафік, який пускатиметься через VPN-тунель.
• Режим тунелю чи транспорту.
  IPsec може працювати у двох режимах: тунельному та транспортному. Вибір режиму залежить від об'єктів, що захищаються.
  Тунельний режимзастосовується захисту між віддаленими об'єктами, тобто. IP-пакет повністю інкапсулюється в новий і для спостерігача збоку буде видно лише з'єднання між двома VPN-точками. Реальні IP-адреси джерела та одержувача будуть видні лише після декапсуляції пакета при прийомі його на VPN-точці отримання. Таким чином, тунельний режим найчастіше використовується для VPN-підключень.
  Транспортний режимзахищає дані IP-пакету (TCP, UDP та протоколи верхніх рівнів), а сам заголовок оригінального IP-пакету буде збережено. Таким чином, для спостерігача буде видно оригінальне джерело і призначення, але не дані. Цей режим найчастіше використовується для захисту з'єднання в локальній мережі між хостами.
• Віддалений шлюз
  VPN-точка одержувач захищеного з'єднання, яка розшифровуватиме/аутентифікуватиме дані з іншого боку і відправлятиме їх до остаточного місця призначення.
• Режим роботи IKE
  IKE узгодження може працювати у двох режимах: Основнийі агресивному.
  Різниця між ними полягає в тому, що в агресивному режимі використовується менша кількість пакетом, що дозволяє досягти більш швидкого встановлення з'єднання. З іншого боку, агресивний режим не передає деякі параметри узгодження, такі як Діффі-Хеллман групи та PFS, що вимагає попереднього ідентичного настроювання їх на точках учасницях підключення.
• IPsec протоколи
  Існує два протоколи IPsec: Authentication Header (AH) та Encapsulating Security Payload (ESP), які виконують функції шифрування та аутентифікації.
  ESP дозволяє шифрувати, аутентифікувати окремо або одночасно.
  AH дозволяє лише аутентифікувати. Різниця з ESP автентифікацією в тому, що AH аутентифікує також зовнішній IP заголовок, дозволяючи підтвердити, що пакет прибув дійсно від джерела вказаного в ньому.
• IKE шифрування
  Вказує алгоритм шифрування IKE та його ключі. Підтримуються різні симетричні алгоритми шифрування, наприклад DES, 3DES, AES.
• IKE автентифікація
  Алгоритм аутентифікації використовуваний у IKE узгодженні. Можуть бути: SHA, MD5.
• IKE Діффі-Хеллмана (DH) групи
  Група DF для обміну ключами в IKE. Чим більше група, тим більше розмір ключів обміну.
• Тривалість життя IKE підключення
  Вказується як у часі (секундах), і за розміром переданих даних (кілобайтах). Як тільки один із лічильників досягне порогового значення, запускається нова перша фаза. Якщо з моменту створення IKE з'єднання не було передано жодних даних, жодних нових підключень не буде створено доти, доки одна зі сторін не захоче створити VPN з'єднання.
• PFS
  При відключеному PFS матеріал для створення ключів буде вилучено у першій фазі узгодження IKE у момент обміну ключів. У другій фазі узгодження IKE ключі сесії будуть створені ґрунтуючись на отриманому матеріалі. При увімкненому PFS під час створення нових ключів сесії матеріал для них буде використовуватися щоразу новий. Таким чином при компроматі ключа, на основі нього неможливо створити нові ключі.
  PFS може бути використаний у двох режимах: перший PFS на ключах (PFS on keys), запускатиме новий обмін ключами в першій фазі IKE щоразу, коли запускається узгодження
  другий фази. Другий режим PFS на ідентифікаторах (PFS on identities), видалятиме SA першої фази щоразу, після проходження узгодження другої фази, гарантуючи тим самим, що жодне узгодження другої фази не буде зашифроване ідентичним попереднім ключем.
• IPsec DH групи
  Дані DF групи аналогічні тим, що використовуються в IKE, тільки використовуються для PFS.
• IPsec шифрування
  Алгоритм, що використовується для шифрування даних. Використовується у разі використання ESP у режимі шифрування. Приклади алгоритмів: DES, 3DES, AES.
• IPsec автентифікація
  Алгоритм використовується для аутентифікації даних, що передаються. Використовується у випадку AH або ESP у режимі автентифікації. Приклади алгоритмів: SHA, MD5.
• Час життя IPsec
  Час життя VPN з'єднання вказується як у часі (секундах) і за розміром переданих даних (кілобайти). Лічильник першим, хто досяг ліміту, запустить перестворення ключів сесії. Якщо з моменту створення IKE з'єднання не було передано жодних даних, жодних нових підключень не буде створено доти, доки одна зі сторін не захоче створити VPN з'єднання.

Методи аутентифікації IKE

• Ручний режим
  Найпростіший із методів, при якому IKE не використовується, а ключі автентифікації та шифрування, а також деякі інші параметри задаються вручну на обох точках підключення VPN.
• Через загальні ключі (Pre-Shared Keys, PSK)
  Заздалегідь введений загальний ключ на обох точках з'єднання VPN. Відмінність від попереднього методу в тому, що використовується IKE, що дозволяє аутентифікувати кінцеві точки і використовувати ключі сесії, що змінюються, замість фіксованих ключів шифрування.
• Сертифікати
  Кожна точка VPN використовує свій приватний ключ, свій відкритий ключ, свій сертифікат, що включає свій відкритий ключ і підписаний довіреним центром сертифікації. На відміну від попереднього методу, дозволяє уникнути введення одного загального ключа на всіх точках VPN з'єднання, замінюючи його особистими сертифікатами, підписаними довіреним центром.

Протоколи IPsec

IPsec протоколи використовуються для захисту даних, що передаються. Вибір протоколу та її ключів відбувається за узгодженні IKE.

AH (Authentication Header)

AH надає можливо аутентифікувати дані, що передаються. Для цього використовується криптографічна хеш-функція по відношенню до даних, що містяться в IP-пакеті. Виведення цієї функції (хеш) передається разом з пакетом і дозволяє віддаленій VPN точці підтвердити цілісність оригінального IP-пакета, підтверджуючи, що він не був змінений на шляху. Крім даних IP-пакета, AH також аутентифікує частину його заголовка.

У режимі транспорту AH вбудовує свій заголовок після оригінального IP пакета.
У режимі тунелю AH вбудовує свій заголовок після зовнішнього (нового) IP-заголовка та перед внутрішнім (оригінальним) IP-заголовком.

ESP (Encapsulating Security Payload)

ESP протокол використовується для шифрування, для аутентифікації або і того, і іншого щодо IP пакета.

У режимі транспорту ESP протокол вставляє свій заголовок після оригінального IP заголовка.
У режимі тунелю ESP заголовок знаходиться після зовнішнього (нового) IP заголовка та перед внутрішнім (оригінальним).

Дві основні відмінності між ESP і AH:

• ESP крім аутентифікації надає можливість шифрування (AH цього не надає)
• ESP у режимі тунелю аутентифікує лише оригінальний IP-заголовок (AH аутентифікує також зовнішній).

Робота за NAT (NAT Traversal)
Для підтримки роботи за NAT було реалізовано окрему специфікацію. Якщо точка VPN підтримує цю специфікацію, IPsec підтримує роботу за NAT, однак існують певні вимоги.
Підтримка NAT складається із двох частин:

• На рівні IKE кінцеві пристрої обмінюються один з одним інформацією про підтримку, NAT Traversal і версією специфікації, що підтримується.
• На рівні ESP сформований пакет інкапсулюється в UDP.

NAT Traversal використовується лише у тому випадку, якщо обидві точки підтримують його.
Визначення NAT: обидві точки VPN посилають хеші своїх IP адрес разом з UDP портом джерела IKE узгодження. Ця інформація використовується одержувачем, щоб визначити, чи було змінено IP адресу та/або порт джерела. Якщо ці параметри були змінені, то трафік не проходить через NAT і механізм NAT Traversal не потрібен. Якщо адресу або порт змінено, то між пристроями знаходиться NAT.

Як тільки кінцеві точки визначать, що необхідний NAT Traversal, узгодження IKE переміщаються з порту UDP 500 на порт 4500. Це робиться тому, що деякі пристрої некоректно обробляють IKE сесію на порту 500 при використанні NAT.
Інша проблема виникає через те, що ESP протокол – протокол транспортного рівня та розташовується безпосередньо поверх IP. Через це до нього не застосовні поняття TCP/UDP порту, що унеможливлює підключення через NAT більше одного клієнта до одного шлюзу. Для вирішення цієї проблеми ESP запаковується в UDP дейтаграму і посилається на порт 4500, той самий, який використовує IKE при включеному NAT Traversal.
NAT Traversal вбудований у роботу протоколів, що його підтримують і працює без попереднього налаштування.

Ми вже обговорювали поняття IPSec, у цьому матеріалі ми розглянемо докладніше.

Отже, назва IPSec походить від IP Security.
IPSec – це сукупність протоколів та адлгоритмів, які використовуються для захисту IP пакетів на рівні Layer3.

IPSec дозволяє гарантувати:
- Confidentiality – за допомогою шифрування
- Data integrity - через Hashing та HMAC\
- Authentication – через використання Digital Signatures або Pre-shared key (PSK).

Перерахуємо основні протоколи IPsec:
■ ESP і AH: Два основні протоколи, що використовуються в IPsec.
Encapsulating Security Payload (ESP), може робити все, що потрібно для IPsec, а
Authentication Header (AH)може робити все, крім шифрування, encryption of the data, - тому найчастіше використовують ESP.
■ Обробка algoritms для confidentiality: DES, 3DES, AES.
■Hashing algorithms for integrity: MD5, SHA.
■ Authentication algorithms: Pre-shared keys (PSK), RSA digital signatures.
■ Key management: An example would be Diffie-Hellman (DH), які можуть бути використані
dynamically generate symmetrical keys to be used by symmetrical algorithms; PKI,
which supports the function of digital certificates issued by trusted CAs; and Internet
Key Exchange (IKE), які є безліч з них і менеджменту
IPsec to operate.

Навіщо потрібний IPSec

Розглянемо наступну просту топологію з'єднання двох офісів.

Нам необхідно забезпечити з'єднання двох офісів та виконати такі цілі:

• Confidentiality- Забезпечується через шифрування даних.
• Data integrity- забезпечується через hashing, або через Hashed Message Authentication Code (HMAC), - методи, що дозволяють гарантувати, що дані не були змінені.
• Authentication- забезпечується з використанням pre-shared keys (PSK), або digital signatures. А під час використання HMAC автентифікація відбувається постійно.
• Antireplay protection- всі пакети VPN нумеруються, що є захистом від їхнього повторення.

Протоколи та порти IPSec

IKEv1 Phase 1	UDP port 500	IKEv1 Phase 1 використовується UDP:500 для його неготіації.
NAT-T (NAT Traversal)	UDP port 4500	NAT Traversal використовується пристроями для подолання NAT. Якщо обидва пристрої підключаються один до одного через NAT: they want to put a fake UDP port 4500 header on each IPsec packet (before the ESP header) to survive a NAT device that otherwise may have a problem tracking an ESP session (Layer 4 protocol 50)
ESP	Layer 4 Protocol 50	Усі пакети IPSec являють собою Layer 4 protocol of ESP (IP Protocol # 50), в нього інкапсулюються всі дані. Зазвичай використовується саме ESP (а не AH). У разі використання NAT-T ESP header закривається другим UDP header.
AH	Layer 4 protocol 51	AH packets є Layer 4 protocol of AH (IP Protocol #51). AH не підтримує шифрування корисних даних, і тому він використовується рідко.

Робота IPSec

Для підняття безпечного з'єднання VPN, IPSec використовує протокол Internet Key Exchange (IKE).
IKE - це framework, що забезпечується Internet Security Association, а також Key Management Protocol (ISAKMP)

Отже у нашій конфігурації обидва роутери виступатимуть як VPN gatewayабо IPsec peers.

Припустимо користувач мережі 10.0.0.0 відправляє пакет у мережу 172.16.0.0.
Оскільки тунель ще не створений R1, почне initiate negotiations з другим роутером R2.

Step 1: Negotiate the IKEv1 Phase 1 Tunnel

Першим кроком між роутерами піднімається Internet Key Exchange (IKE) Phase 1 tunnel.
Такий тунель не призначений для передачі даних, але використовується в службових цілях, для захисту management traffic.

Підняття IKE Phase 1 tunnel може бути виконане у двох режимах:
- main mode
- Aggressive mode
Main mode вимагає обміну великою кількістю пакетів, але і вважається більш безпечним.

Для підняття IKE Phase 1 tunnel повинні бути куповані наступні елементи:

• Hash algoritm: Це може бути message digest 5 algorithm (MD5)або Secure Hash
  Algorithm (SHA).
• Encryption algorithm: Digital Encryption Standard (DES)(слабкий, не рекомендується), Triple DES (3DES)(трохи краще) or Advanced Encryption Standard (AES)(рекомендується) AES може використовувати ключі різної довжини: чим довше, тим безпечніше.
• Diffie-Hellman (DH) group to use: The DH “group” refers to the modulus size
  key) to use for the DH key exchange. Group 1 uses 768 bits, group 2 uses 1024, and
  group 5 uses 1536. More secure DH groups є part of the next-generation encryption
  (NGE):
  - Group 14 or 24: Provides 2048-bit DH
  - Groups 15 and 16: Support 3072-bit and 4096-bit DH
  - Group 19 or 20: Supports the 256-bit and 384-bit ECDH groups, respectively

  Завдання DH - згенерувати keying material (symmetric keys). Ці ключі будуть використовуватись для передачі даних.
  Сам DH є asymmetrical , але ключі він генерує symmetrical.

• Authentication метод: може бути у вигляді pre-shared key (PSK)або RSA signatures
• Lifetime: брешемо життя IKE Phase 1 tunnel. Єдиний параметр, який може збігатися. Чим коротше Lifetime, тим частіше мінятимуть ключі, і тим це безпечніше.

Step 2: Run the DH Key Exchange

Після того, як роутери домовилися про IKE Phase 1 policy, вони можуть розпочати процес DH key exchange. DH дозволяє двом пристроям, між якими поки що немає secure connection, безпечно обмінятися симетричними ключами, які будуть використовуватися симетричними алгоритмами, наприклад AES.

Step 3: Authenticate the Peer

Останнє, що буде зроблено в IKE Phase 1 - це взаємна автентифікація хостів, яка може бути зроблена двома методами (PSK або RSA digital signatures)
Якщо аутентифікація пройшла успішно, IKE Phase 1 tunnel вважається піднятим. Тунель є двонаправленим.

Step 4: IKE Phase 2

Після того, як піднявся IKE Phase 1 tunnel, роутери починають піднімати IKE Phase 1 tunnel.
Як уже згадувалося, IKE Phase 1 tunnel є чисто службовим, management tunnel і через нього проходить весь трафік negotiation для підняття тунелю IKE Phase 2.
IKE Phase 2 tunnel також використовує алгоритми hashing та encryption.
Підняття IKE Phase 2 tunnel може бути виконане в одному режимі:
- Quick mode

IKE Phase 2 tunnel насправді і двох односпрямованих тунелів, тобто. можна сказати що створюються:
Один тунель IKE Phase 1 tunnel, який є bidirectional, що використовується для службових функцій.
І два тунелі IKE Phase 2, які є unidirectional, і які використовуються для шифрування корисного трафіку.
Всі ці тунелі також називаються як security agreements between the 2 VPN peersабо security associations (SA).
Кожен SA має власний унікальний номер.

Тепер, після того як було піднято IKE Phase 2 tunnel, всі пакети, що виходять із зовнішніх інтерфейсів, будуть зашифровані.

Приклад налаштування

Розглянемо приклад налаштування IPsec з прикладу даної схеми.

1. Configure Interesting Traffic
   Для початку ми повинні визначити трафік, який ми шифруватимемо.
   Router R1

   ip access-list extended VPN-ACL permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

   Router R2

   ip access-list extended VPN-ACL permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

2. Configure Phase 1 (ISAKMP)
   Phase 1 піднімає тунель, що використовується для службових цілей: обмін shared secret keys, authenticate, negotiate IKE security policies і т.д.
   Може бути створено кілька isakmp policies з різними пріоритетами.

   Router R1

   crypto isakmp key secretkey address 200.200.200.1

   Router R2

   crypto isakmp policy 1 encryption 3des hash md5 authentication pre-share group 2

   crypto isakmp key secretkey address 100.100.100.1

   Тут key є PSK(Preshared Key), що використовується роутерами для аутентифікації IKE Phase 1.

3. Configure Phase 2 (IPSEc)
   Мета IKE Phase 2 Tunnel – передача корисного трафіку між хостами двох офісів.
   Параметри тунелю Phase 2 Tunnel групуються в sets, які називаються transform sets.
   Router R1

   crypto ipsec transform-set TRSET esp-3des esp-md5-hmac! crypto map VPNMAP 10 ipsec-isakmp set peer 200.200.200.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP

   Router R2

   crypto ipsec transform-set TRSET esp-3des esp-md5-hmac! crypto map VPNMAP 10 ipsec-isakmp set peer 100.100.100.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP

   На обох хостах використовувалася crypto ipsec transform-set TRSET esp-3des esp-md5-hmac.
   Це означає, що 3des буде використано для шифрування, а md5-hmac для автентифікації.

   crypto map еплаїться на інтерфейс. Криптокарта відстежує трафік, що відповідає заданим умовам. Наша криптокарта буде працювати з роутером з адресою 100.100.100.1, заданим ACL внутрішнім трафіком і застосовуватиме цей трафік transform-set TRSET.

Перевірка IPSec

Загалом список корисних команд наступний:
show crypto isakmp policy
show crypto map
show crypto isakmp sa detail
show crypto ipsec sa
show crypto engine connections active

На практиці найбільш корисним є наступне: