Шифрування

Повідомлення L2TP шифрується з використанням стандарту DES (Data Encryption Standard – стандарт шифрування даних), 3DES за допомогою ключів шифрування, створених в процесі узгодження IKE (Internet Key Exchange – обмін ключами в Інтернеті) або інших стандартизованих алгоритмів шифрування.

Протокол L2TP і метод IPSec повинні підтримуватися як на VPN – клієнті, так і на VPN -сервері. Клієнтська підтримка L2TP вбудована в клієнт видаленого доступу Windows XP, а підтримка L2TP VPN – серверами – в операційні системи сімейства Windows Server 2003.

L2TP через UDP/IP

L2TP використовує зареєстрований UDP -порт 1701 (RFC1700). Увесь L2TP -пакет, включаючи поле даних і L2TP – заголовок, пересилається усередині UDP – дейтограми. Творець L2TP – тунелю вибирає доступний UDP – порт (який може бути або не бути 1701), і посилає пакет за потрібною адресою місця призначення з номером порту 1701. Одержувач вибирає вільний номер порту у своїй системі (який може бути або не бути 1701), і посилає відгук ініціаторові за його номером порту і адреси. Раз номера портів відправника і одержувача визначені, вони повинні залишатися незмінними впродовж усього життя тунелю.

Може відбуватися IP -фрагментація, оскільки L2TP – пакет подорожує через інтернет. Протокол L2TP не робить якихось спеціальних зусиль, щоб оптимізувати цей процес.

За замовчуванням для будь-яких реалізацій L2TP має бути активізоване контрольне підсумовування UDP як для керівних, так і інформаційних повідомлень. Реалізація L2TP може надати опцію, здатну блокувати контрольне підсумовування UDP – дейтограм для інформаційних повідомлень. Рекомендується, щоб контрольні суми UDP були завжди активовані для повідомлень, що управляють.

Порт 1701 використовується як пакетами L2F (RFC2341), так і L2TP. Поле версія в кожному із заголовків може використовуватися, щоб відрізнити пакети цих двох типів (L2F використовує значення 1, а версія L2TP, описана в цьому документі, використовує 2). Реалізація L2TP, працююча в системі, яка не підтримує L2F, повинна відкидати усі L2F - пакети.

Для PPP - клієнтів, що використовують тунель L2TP -поверх-UDP/IP, PPP – з’єднання має можливість міняти порядок або відкидати пакети. У першому випадку можуть порушуватися протоколи, відмінні від IP і PPP, що використовують для транспортування. У другому - можуть порушуватися протоколи, в яких передбачається по пакетний контроль помилок, такий як TCP із стискуванням заголовків. Контроль порядка можна здійснити, використовуючи номери інформаційних L2TP - повідомлень, якщо якийсь протокол, що транспортується через PPP -тунель, не здатний впоратися зі зміною порядка пакетів.

Мовчазне відкидання пакетів може виявитися проблематичним для деяких протоколів. Якщо в PPP дозволена надійна доставка (RFC1663), ніякий вище розташований протокол не може зіткнутися із втратою пакетів. Якщо в L2TP дозволена нумерація пакетів, L2TP може контролювати втрату пакетів. У разі LNS, PPP і L2TP стеки є присутніми в LNS, і втрата пакета може реєструватися, начебто пакет отриманий з невірною CRC. Коли клієнти LAC і PPP фізично різні, можлива аналогова сигналізація, що реалізовується шляхом посилки PPP - клієнту пакета з невірною контрольною сумою. Це сильно ускладнить відладку канальних програм клієнта, оскільки статистика клієнта не зможе відрізнити істинні помилки транспортного середовища від помилок, ініційованих LAC. Ця техніка не реалізовується на апаратному рівні.

Якщо використовується компресія заголовка Van Jacobson, і не дозволена ні надійна доставка в PPP, ні нумерація пакетів, кожен втрачений пакет призводитиме до вірогідності 2^-16 того, що сегмент TCP буде переадресований з невірним вмістом (RFC1144). Там де вірогідність втрати велика, не слід використовувати стискування заголовків TCP - сегментів.

Протокол L2TP стикається при своїй роботі з декількома проблемами безпеки. Нижче розглянуті деякі підходи для вирішення цих проблем.

Безпека на віддаленій стороні тунелю

Сторони тунелю можуть опціонально виконувати процедуру автентифікації один одного при встановленні тунелю. Ця автентифікація має ті ж атрибути безпеки, що і CHAP, і має розумний захист проти атак відтворення і спотворення в процесі встановлення тунелю. Цей механізм не реалізує автентифікації при формуванні тунелю; оскільки досить просто для зловмисного користувача, який спостерігає обмін в тунелі, ввести свої пакети, коли автентифікація повністю завершена.

Для реалізації автентифікації LAC (L2TP Access Concentrator) і LNS (L2TP Network Server) повинні використовувати загальний секретний ключ. Кожна із сторін використовує один і той же ключ, коли виконує роль автентифікатора і автентифікованного. Оскільки використовується тільки один ключ, AVP (Attribute Value Pair) автентифікації тунелю несуть в собі різні значення полів в CHAP ID для обчислення дайджеста кожного повідомлення, щоб протистояти атакам відтворення.

Assigned Tunnel ID і Assigned Session ID мають бути вибрані непередбачуваним чином. Така методика перешкоджає діяльності хакерів, які не мають доступу до пакетів, якими обмінюються LAC і LNS.

Безпека пакетного рівня.

Забезпечення безпеки L2TP вимагає, щоб транспортне середовище могло забезпечити шифрування даних, цілісність повідомлень і автентифікацію послуг для усього L2TP - трафіка. Цей безпечний транспорт працює з пакетом L2TP в цілому і функціонально незалежний від PPP і протоколу, вкладеного в PPP. Як такий, L2TP відповідальний за конфіденційність, цілісність і автентифікацію L2TP - пакетів усередині тунелю (LAC і LNS).

Захищаючи потік L2TP - пакетів, оскільки це робить безпечний транспорт, ми захищаємо дані, що передаються PPP - тунелем від LAC до LNS. Такий захист не повинен розглядатися як заміна для безпеки точка-точка при передачі даних між ЕОМ або додатками.

L2TP і IPSec

При роботі поверх IP, IPSec (безпечний IP) надає безпеку на пакетному рівні за рахунок інкапсуляції зашифрованих даних ESP (Encapsulating Security Payload) або автентифікації заголовка AH (authentication header). Усі керівники і інформаційні пакети L2TP в конкретному тунелі виглядають для системи Ipsec, як звичайні інформаційні UDP/IP - пакети.

Окрім транспортної безпеки IP, IPSec визначає режим роботи, який дозволяє тунелювати IP - пакети. Шифрування і автентифікація на пакетному рівні, виконувані режимом тунелю IPSec і засоби L2TP, підтримані IPSec надають еквівалентні рівні безпеки.

IPSec визначає також засоби контролю доступу, які потрібні для додатків, підтримувальних IPSec. Ці засоби дозволяють фільтрувати пакети, на основі характеристик мережного та транспортного рівнів, таких як IP -адреса, порт, і так далі. У моделі L2TP - тунелю, аналогічна фільтрація виконується на PPP - уровні або мережевому рівні поверх L2TP. Ці засоби управління доступом на мережевому рівні можуть бути реалізовані в LNS за рахунок механізму авторизації, специфікованого виробником, або на мережевому рівні, використовуючи транспортний режим IPSec точка-точка між взаємодіючими ЕОМ.

2. Хід роботи