Підключення декількох паралельних каналів (mp)
Формат MP-пакета представлено на рис. 5.
Поле PID - ідентифікатор протоколу. Субполя B (Beginning) - біт фрагмента = 1 для першого фрагмента PPP і = 0 для всіх наступних фрагментів. Субполя E (Ending) - біт фрагмента = 1 для останнього фрагмента PPP і = 0 для всіх інших фрагментів. Поле „номер по порядку” має довжину 24 біта. Існує модифікація пакета з укороченим кодом (12 біт) номера по порядку. При цьому до цього поля відходів 4 нульові біти після BE00. Вибір довжини цього поля здійснюється протоколом LCP. Значення поля збільшується на 1 при посиланні чергового фрагмента. Для вищерозташованих рівнів сукупність спільно використовуваних каналів виглядає, як один віртуальний канал.
Рис. 5 – Формат MP-пакета
При передаванні пакетів по каналу Multilink інкапсуляція проводиться згідно з такими правилами, які задаються вручну:
• Ніякого асинхронного управління кодуванням символів.
• Заборона використання магічних чисел.
• Заборонено моніторити якість каналу.
• Стиснення полів адреси, протоколу та управління.
• Ніяких складових кадрів.
• Заборона заповнення з самоописом (Self-Describing-Padding).
Для попередньо фрагментованих пакетів заборонено доповнення нулями або використання будь-яких інших наповнювачів. Розглянемо приклад Multilink-з'єднання, наведений на рис. 6. Канал 1 між двома системами узгоджується мережевими рівнями NL1, NL2 і MP. Потім ці дві системи узгодять з MP канал 2. Кадри, отримані каналом 1, демультіплекуються на канальному рівні згідно мережевому протокольного ідентифікатору PPP і можуть бути надіслані NL1, NL2 або MP. Канал 2 прийме кадри з усіма мережевими протокольними ідентифікаторами, з якими приймає їх канал 1. Кадри, отримані MP, пізніше демультіплексіруются на мережевому рівні згідно протокольного ідентифікатору PPP і посилаються NL1 або NL2. Будь-які кадри, отримані MP для інших протоколів мережевого рівня, відкидаються з допомогою стандартного протокольного механізму (Reject).
Рисунок 6 – Приклад Multilink-конфігурації
Так як міжмережеві зв'язку часто використовують послідовні канали (виділені лінії, радіомодеми тощо), протокол PPP розповсюджений досить широко. Протокол PPP служить і для створення міжмережевих тунелів (протокол PPTP - Point to Point Tunneling Protocol). Протокол PPTP використовує MTU = 1532, номер порту 5678 і номер версії 0x0100, пакети даних тут транспортуються з використанням протоколу інкапсуляції GRE V2.
Автентифікація сторін
Для автентифікації сторін використовуються протоколи PAP та CHAP.
Протокол CHAP
Протокол аутентифікації запит-відповідь Challenge-Handshake Authentication Protocol (CHAP) використовується для реалізації функцій безпеки при встановленні РРР-з'єднання. У протоколі CHAP застосовується триразова перевірка справжності при реєстрації клієнта на хості. В RFC 1994 описаний алгоритм, реалізований в протоколі CHAP. Формат пакета про-токола CHAP представлений на рис. 7.
Рис. 7 – Формат пакета протокола CHAP
Поле Код має довжину в один октет і ідентифікує тип пакета CHAP. У табл. 4 наведено можливі значення поля Код.
Таблиця 4 – Значення поля Код протоколу CHAP
Код |
Опис |
1 |
Виклик |
2 |
Відповідь |
3 |
Успішна аутентифікація |
4 |
Відмова |
Поле Ідентифікатор має довжину в один октет. За допомогою цього поля відбувається ідентифікація пакета CHAP. Потім клієнт і хост по цьому ідентифікатору можуть погоджувати свої запити та відповіді на них.
Поле Довжина становить два октету і використовується для завдання довжини пакета CHAP. Довжина пакета вважається з урахуванням полів Код, Ідентифікатор, Довжина і Дані.
Поле Дані може бути нульової довжини або декілька октетів у довжину. До нього включаються дані, які задані в поле Код пакета CHAP.
На рис.8 показано протокол, що підтверджує встановлення з'єднання, який застосовується в CHAP для перевірки дійсності клієнта. Підтвердження встановлення з'єднання в CHAP відбувається у три фази.
• Хост надсилає пакет запиту CHAP-клієнту з випадковим значенням.
• Клієнт відповідає пакетом відповіді CHAP, в який включено значення, обчислене за допомогою накладення на значення виклику секретного ключа. Ключ виводиться з допо-могою односторонньої функції хешування.
• Далі хост звіряє значення у відповіді клієнта, з отриманим ним самим таким же способом (накладення значення виклику на ключ). Якщо вони збігаються, то хост надсилає пакет "Success" (Успішна аутентифікація), і сеанс РРР триває. В іншому випадку хост надсилає клієнтові пакет "Failure" (Відмова), сеанс РРР припиняється і формується LCP-пакет типу Terminate-Request.
Рис. 8 - Фази підтвердження встановлення з'єднання в протоколі CHAP
У протоколі CHAP передбачена ще одна можливість. Вона полягає в тому, що хост РРР може в будь-який момент під час сеансу РРР попросити клієнта про аутентифікацію. Така можливість дозволяє запобігти несанкціонований доступ з боку інших пристроїв.