Все, що ви хотіли знати про протокол SIP
частина 3
Проблема обходу NAT
Втім, проблема обходу NAT медіатрафіком - це лише одна сторона медалі. Спочатку ми розглянемо, які перешкоди створює NAT для сигнальних повідомлень і які розширення SIP були розроблені для їх подолання.
Обхід NAT SIP-сигналізацією
Друга проблема полягає в необхідності коректної маршрутизації вхідних SIP-запитів. SIP не забезпечує механізму, який би дозволяв відправляти нові запити по тому з'єднанню транспортного рівня, яке було утворено при реєстрації користувача. Записи в таблиці трансляції NAT мають обмежений час життя (щоб таблиці не рясніла в тому числі) і, щоб входять SIP-запити могли досягти UA за NAT, записи в таблиці трансляції NAT треба періодично оновлювати. Це стосується як протоколів без встановлення з'єднання, так і протоколів з встановленням з'єднання.
Малюнок 1. Маршрутизація вхідних запитів
Але запис в таблиці трансляції NAT видаляється після закінчення певного проміжку часу (найчастіше - кілька хвилин). Проблема актуальна не тільки в період після реєстрації користувача: під час SIP-діалогів нові повідомлення також можуть не надходити протягом тривалого проміжку часу, чого достатньо для того, щоб запис з таблиці трансляції була видалена. Наявні SIP-стеки вирішують цю проблему шляхом періодичної посилки SIP-запитів re-INVITE, OPTIONS, INFO, NOTIFY або (при використанні UDP) дейтаграм, що не містять корисної навантаження.
Більш повна і досконала техніка описана в проекті Managing Client Initiated Connections in SIP Інженерної проблемної групи Інтернет (IETF) [2]. Зупинимося на ній докладніше.
При реєстрації користувача реєстратор зберігає дані про транспортне сполучення, через яке було отримано запит. Два спеціальних параметра instance-id і reg-id заголовка Contact дозволяють знайти в базі даних сервера реєстрації дані про з'єднання і направити вхідний запит до UA по тому з'єднанню транспортного рівня, через яке було отримано запит реєстрації. Також в чернетці описані механізми для постійного оновлення записів таблиці трансляції NAT.
Підсумуємо сказане невеликим прикладом реєстрації користувача, що знаходиться за NAT і використовує UDP (див. Рис. 2).
Малюнок 2. Обхід NAT SIP-сигналізацією
Запит REGISTER містить параметр заголовка Via rport, інформує UAS про підтримку RFC 3581, а також параметри reg-id і + sip.instance в заголовку Contact:
REGISTER sip: proxy.example.com SIP / 2.0
WWW-Authenticate: [не показаний]
Обхід NAT медіатрафіком
Малюнок 3. Обхід NAT медіатрафіком
Simple Traversal of UDP through NAT (STUN)
Нарешті, ми підійшли до головного. STUN не вирішує проблему обходу NAT в SIP в загальному випадку. Так, він працює в сценаріях Port Restricted Cone NAT, а іноді - і в Restricted Cone NAT, але найбільш поширеним типом NAT був і залишається симетричний, і тут STUN марний. До того ж не всі UA навіть в разі більш дружніх типів NAT добре «дружать» з STUN, а в більш старих пристроях підтримка STUN була широко поширена.
Ще одна «ложка дьогтю» - в існуючих реалізаціях STUN не працює з SIP поверх TCP, оскільки не відстежує належним чином стан відкритих TCP-сесій.
Traversal Using Relay NAT (TURN)
Малюнок 5. Обхід NAT SIP-сигналізацією
Недолік даного методу очевидний: внаслідок проксінг всього трафіку збільшується одностороння затримка і підвищується ймовірність втрати пакетів. З цієї причини TURN рекомендується використовувати лише в тих випадках, коли менш «дорогі» методи обходу NAT безсилі. Зауважимо, що з недавнього часу TURN більше не вважається самостійним протоколом: зараз він описаний як розширення до STUN в [5].
Interactive Connectivity Establishment (ICE)
TURN-сервер проксірует весь RTP-трафік навіть тоді, коли простого STUN було б достатньо для обходу NAT. З метою вибору найменш «дорогого» методу обходу NAT шляхом проведення узгодження можливих опцій між кінцевими точками асоціація IETF запропонувала інфраструктуру ICE (Interactive Connectivity Establishment). Це не протокол в звичному сенсі цього слова; ICE називають інфраструктурою (framework), і базується він на існуючих протоколах STUN і TURN і розширеннях SIP.
У списку маршрутів-кандидатів найвищий пріоритет отримують маршрути без задіяння STUN, нижчий - маршрути з залученням STUN, і найбільш низький - маршрути з проксінг медіатрафіка через TURN-сервер. Виклад тут навмисно ускладнено: насправді гнучка система пріоритетів дозволяє враховувати топологію мережі, дані про затримку і варіації затримки, вимоги до безпеки і т. Д. В результаті кожен маршрут отримує унікальне значення пріоритету. Потім перевіряється їх працездатність (досяжність протилежного боку). З маршрутів, які пройшли перевірку, вибирається один з найвищим пріоритетом.
Словом, специфікація ICE виглядає вельми багатообіцяюче, і це рішення знаходить підтримку VoIP-індустрії. Опис ICE дано в [6].
Для функціонування цього механізму принципово важливим є властивість симетричності призначеного для користувача агента: використання для передачі і прийому одного і того ж порту (UA повинен відправляти медіа-потік з того порту, який він анонсував в SDP). Але такий підхід ідеальний в сенсі точності даних: не потрібно нічого, крім власне пакета, і оскільки пакет приходить на той порт, з якого буде надсилатися зустрічний потік - вирішуються проблеми з усіма видами NAT. В такому проксі-сервер можна реалізувати будь-яку додаткову функціональність, пов'язану з модифікацією SDP-частини. У той же час це вносить додаткову затримку в сеанс, підвищує навантаження на проксі-сервер і витрати сервіс-провайдера.
Розширення Cisco COMEDIA
o = client 28908445312 28908445312 IN IP4 10.1.2.23
a = direction: passive IN IP4
При реалізації COMEDIA Cisco керувалася сильно застарілим на сьогоднішній день проектом IETF [8] четвертої версії.
Нерідко в якості рішення пропонується застосовувати шлюзи рівня додатків (Application Layer Gateway, ALG), обробні як заголовки пакету IP, так і його інформаційне наповнення. Функції ALG можуть виконувати прикордонні контролери сполук (Session Border Controller, SBC) або маршрутизатори, які транслюють керуючі повідомлення SIP. На жаль, обробка кожного пакета вимагає високої продуктивності і підвищує вартість рішення. До того ж нові модифікації протоколу вимагають, щоб ПО SIP ALG постійно оновлювалося, а його виробник стежив за всіма змінами, реалізованими постачальниками пристроїв SIP. «Нечесний» SIP ALG може вплинути на нормальне функціонування знаходяться за ним пристроїв. Технологія UPnP (Universal Plug and Play) частіше застосовується в сегменті SOHO і малих інсталяціях. Втім, вона не є специфічною для VoIP і до того ж і так непогано висвітлена в Мережі. Наостанок, цінних зведеним документом по описаним тут рішенням проблеми NAT є [9].
Члени робочої групи IETF SIP Working Group розробили вичерпний набір базисних елементів захисту, що запобігають прослуховування, перехоплення сесій і активні атаки SIP-систем, а також дозволяють переконатися в достовірності співрозмовника. Частина, що залишилася статті присвячена розгляду цих елементів.
У SIP передбачено дві схеми аутентифікації: дайджест-аутентифікація в стилі HTTP (RFC 2617 [10]), і аутентифікація з використанням сертифікатів (для SIP поверх TLS).
При використанні дайджест-аутентифікації в стилі HTTP проксі-сервер відповідає на INVITE відповіддю 407 Proxy Authorization Required, в якому присутній поле заголовка Proxy-Authenticate, з даними для обчислення відгуку аутентифікації. Після відправки повідомлення ACK на 407 Proxy Authorization Required призначений для користувача агент може переслати INVITE, але на цей раз - з заголовком Proxy-Authorization, що містить посвідчення користувача (див. Рис. 6).
Малюнок 6. Дайджест-аутентифікація
Дайджест повідомлення - це унікальна символьний рядок фіксованого розміру, вона є результатом обробки даних (зашифрованих імені користувача і пароля) за допомогою односторонньої хеш-функції MD5. Сервер SIP порівнює дані заголовка Authorization з результатом застосування такої самої хеш-функції до даних, що зберігаються в базі.
Transport Layer Security (TLS)
На шляху від призначеного для користувача агента до проксі-сервера застосовується TLS, а сигналізація між серверами може бути захищена за допомогою TLS або IPSec (який вважається опціональним, але більш стійким). Після успішної аутентифікації проксі-сервери SIP дешифрують кожне повідомлення (на кожній ділянці шляху застосовується окремий ключ), що дає їм можливість «бачити» все заголовки і коректно виконувати маршрутизацію повідомлень. Однак кінцеві абоненти повинні беззастережно «довіряти» проксі-серверів.
Серед слабких місць протоколу TLS традиційно згадують схильність атакам «людина посередині» (Man-in-the-Middle). Є і специфічні для SIP проблеми: хоча TLS-з'єднання служить свідоцтвом автентичності обох сторін, цього мало для того, щоб бути впевненим в автентичності (або забезпечити неможливість зречення) від довільного SIP-повідомлення, переданого по цьому каналу.
TLS здатний забезпечити ці цілі в рамках протоколу HTTPS, де поява іконки із зображенням замку в браузері автоматично означає наявність безпечного каналу між браузером і веб-сервером. SIP ж набагато складніший. Уявіть, наприклад, TLS-з'єднання між двома проксі-серверами: через нього може передаватися трафік, що належить різним транзакціях або діалогів. Отже, зловмисник з одного домену може провести атаку з інжекцією трафіку в інший домен, і це не буде виявлено або попереджено TLS-з'єднанням. Корінь проблеми в тому, що кінцеві точки TLS-з'єднання не "знайомі" зі структурою переданих через них повідомлень протоколу SIP настільки, щоб застосувати досить жорстку політику безпеки.
Нарешті, формування довірчих відносин в рамках TLS і навіть установка TCP-з'єднань може стати справжньою проблемою для сервіс-провайдера, який обслуговує вже кілька сотень тисяч абонентських пристроїв. Не потрібно володіти багатою фантазією, щоб уявити, на що буде схожий потік SYN-пакетів під час формування TLS-з'єднань.
Ті, хто цікавиться перспективними розробками можуть звернутися до RFC 4347 [12], що описує протокол DTLS, що працює поверх UDP. А поточна версія протоколу TLS описана в RFC 4346 [13].
Secure MIME (S / MIME)
Давайте подивимося, що може стати відомим зловмисникові, перехопивши SIP-повідомлення, які стосуються етапу установки сесії:
Наскрізне (на відміну від протоколу TLS, що діє від вузла до вузла) забезпечення цілісності, конфіденційності та аутентифікації SIP-повідомлень можна за допомогою технології S / MIME (RFC 3851 [14]). Зауважу, що в попередніх редакціях SIP RFC як методу забезпечення аутентифікації і секретності пропонувався PGP, але зараз його використання визнано застарілим. 23-тя глава RFC 3261 описує застосування схеми S / MIME. Розглянемо, як вона інтегрується в модель використання SIP.
Розглянемо приклад повідомлення з тілом S / MIME (див. Рис. 8).
Малюнок 8. S / MIME
На рис. 8 показана методика захисту тіла SIP-повідомлення за допомогою S / MIME. Для захисту SIP-заголовків повідомлення може бути вміщено в MIME-тіло з типом «message / sip», і інкапсульоване в нове SIP-повідомлення з дубльованими з оригінального повідомлення заголовками з маршрутною інформацією. У свою чергу, до повідомлення-контейнера може застосовуватися S / MIME-підпис. Нарешті, може виконуватися і шифрування SIP-заголовків: в такому випадку в повідомлення-контейнер инкапсулируется шифрований об'єкт S / MIME. Такі повідомлення не сприймаються як новий діалог або транзакція, але користуються усіма перевагами наскрізного шифрування і аутентифікації. Заголовки Request-URI, Via, Record-Route, Route, Max-Forwards, і Proxy-Authorization не повинні враховуватися при підрахунку контрольних сум, оскільки вони можуть (або повинні) змінюватися при проходженні через проміжні проксі-сервери.
Розширення SIP для забезпечення приватності імені і номера абонента
Набір розширень RFC 3323 [15] і RFC 3325 [16] забезпечує підтримку функцій приватності абонента: приховування та верифікації мережею Імен і номера бере участь в діалозі абонента (мережа посвідчує особу абонента, той він, за кого він себе видає).
Підтримка приватності в мережі SIP є складним завданням хоча б тому, що протокол має текстову природу, і учасники діалогу можуть обмінюватися повідомленнями без залучення будь-якого сервіс-провайдера. У той же час від SIP UA потрібно як мінімум функції приховування Імен і номера абонента, що стали звичними в ТМЗК.
Найбільш прямолінійний підхід - надання обмеженої інформації в заголовку From - може викликати проблеми при термінації дзвінка в мережу іншого оператора або ТфОП або зробити неможливим надання низки послуг. В RFC 3325 описує функції забезпечення приватності особистих даних абонента зі збереженням можливості його ідентифікації.
Такий механізм ідентифікації працює в рамках одного домена. Для його реалізації були представлені нові заголовки P-Preferred-Identity і P-Asserted-Identity. Тема P-Preferred-Identity використовується UA в транзакціях з довіреною проксі-сервером. Клієнт конструює запит INVITE, який не містить даних про особу абонента в поле From, але з реальним SIP URI і (опціонально) відображуваним ім'ям в поле P-Preferred-Identity. Також додається заголовок Privacy, що приймає одне з наступного значень:
- «None» - приватність не потрібно; проксі-сервер зобов'язаний не видаляти заголовок P-Asserted-Identity;
- «User» - приватність потрібно; проксі-сервер зобов'язаний видалити заголовок P-Asserted-Identity;
- «Id» - приватність потрібно тільки в рамках даного домену.
Проксі-сервер зобов'язаний виконати дайджест-аутентифікацію для вузла, з яким не встановлені довірчі відносини. Після цього проксі-сервер повинен додати заголовок P-Asserted-Identity з ідентифікатором особистості абонента, який був аутентифікований. Якщо проксі-сервер отримує запит від вузла, з яким довірчі відносини вже встановлені, використовується вже наявний там заголовок P-Asserted-Identity.
Процедура відправки повідомлення наступна. Якщо абонент розташований в домені довіри (див. Рис. 9), проксі-сервер передає запит для абонента без видалення заголовка P-Asserted-Identity.
Малюнок 9. Механізм забезпечення приватності в рамках одного домена
Якщо ж абонент знаходиться за межами домену довіри (див. Рис. 10), при виході повідомлення за межі домену довіри проксі-сервер виконує видалення або зміна всіх заголовків з інформацією про особу відправника (From, Contact, Reply-To, Call-ID, Call-Info, Via, User-Agent, Organization, Server, Subject, In-Reply-To, Record-Route і Warning). P-Asserted-Identity обробляється відповідно до значення заголовка Privacy, а сам заголовок Privacy повинен бути видалений.
Малюнок 10. Механізм забезпечення приватності поза домену довіри
Зрозуміло, картина захисту буде неповною без забезпечення цілісності та конфіденційності даних в рамках одного домена довіри на мережевому рівні. Вузли домену повинні бути взаємно автентифіковано, а транзакції між вузлами (і між UA і вузлами домену) повинні бути захищені за допомогою TLS або IPSec.
Є й альтернативні методи, які засвідчують особу викликає або абонента: так, RFC 4474 [17] наказує використання спеціальних заголовків Identity і Identity-Info для наскрізної аутентифікації особистості ініціатора запиту, а RFC 4916 [18] - кошти аутентифікації одержувача діалогообразующего запиту за допомогою додаткового запиту UPDATE в зворотному напрямку.
Беручи до уваги все розмаїття протоколів, які піклуються про збереження своїх секретів, користувачам слід приділяти особливу увагу вибору клієнтського ПЗ або пристроїв.
Cводка основних SIP RFC
Номер і назва специфікації
Що вона визначає