Подписание и проверка достоверности заголовков маршрутизации протокола инициирования сеанса

Подписание и проверка достоверности заголовков маршрутизации протокола инициирования сеанса

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящая заявка относится к способам и считываемым компьютером носителям для связи между устройствами по компьютерной сети, и, в частности, к способам и считываемым компьютером носителям для подписания и проверки достоверности заголовков маршрутизации протокола инициирования сеанса («SIP») для аутентификации команд маршрутизации, содержащихся в сообщении SIP.

Предпосылки создания изобретения

Протокол инициирования сеанса («SIP») представляет собой протокол сигнализации Интернета для установления, управления и завершения сеансов связи, включая мгновенный обмен сообщениями, телефонные вызовы по Интернету и видеоконференции по Интернету. SIP определен в запросе на комментарии и предложения 2543 и запросе на комментарии и предложения 3261 Целевой группы инженерной поддержки Интернета, каждый из которых включен в данную заявку посредством ссылки. Сеансы SIP включают в себя одного или нескольких участников или клиентов (обычно вызывающий абонент и вызываемый абонент). Сообщения SIP маршрутизируются между каждым оконечным узлом SIP (например, вызывающим абонентом и вызываемым абонентом) по сети узлов SIP, обычно различных серверов.

Существует, в основном, два типа сообщений SIP: запросы, которые посылаются от вызывающего абонента (например, оконечного узла SIP) вызываемому абоненту, и ответы, которые посылаются от вызываемого абонента вызывающему абоненту в ответ на запрос. В некоторых случаях вызываемый абонент также может посылать запрос вызывающему абоненту, после того как инициирован сеанс диалога. Каждое сообщение SIP, независимо от того, является ли оно ответом или запросом, включает в себя, в основном, три части: стартовую строку, заголовки и тело. Стартовая строка передает тип сообщения (например, запрос или ответ) и версию протокола, и тело сообщения включает в себя содержимое сообщения и может передавать информацию описания сеанса помимо сигнальной информации в стартовой строке. Поля заголовка SIP передают атрибуты сообщения и модифицируют смысл сообщения. Некоторые атрибуты сообщения, хранимые в полях заголовка, представляют собой инструкции в отношении того, как маршрутизировать сообщение, а также документировать фактический маршрут, проходимый сообщением. Например, каждый узел SIP, который управляет запросом на его маршруте, будет добавлять заголовок 'VIA' (через), содержащий информацию, идентифицирующую данный узел SIP, такой как полностью определенное доменное имя или адрес межсетевого протокола. Таким образом, могут быть обнаружены петли в маршрутах, и ответ использует заголовки VIA из запроса для определения маршрута прохождения для возврата к вызывающему абоненту. Однако конкретный путь сообщения не может быть фиксированным во времени, таким образом, узел SIP, такой как домашний сервер, может принимать первый запрос диалога, такой как телефонный вызов, но может не принимать последующие запросы в этом же диалоге. Чтобы оставаться «в цикле» данного диалога, узел SIP может вставить заголовок RECORD-ROUTE (записать маршрут), содержащий информацию, идентифицирующую его самого, такую как универсальный индикатор информационного ресурса («URI») или другой адрес, который позволяет другим серверам или конечным точкам достигать узла SIP. Части заполненного списка заголовков RECORD-ROUTE затем копируются принимающим конечным клиентом (вызываемым абонентом для запросов и вызывающим абонентом для ответов) в набор заголовков ROUTE (маршрут). Заголовки ROUTE SET (набор маршрутов) содержат данные, обеспечивающие инструкции узлам SIP в отношении того, как маршрутизировать любые будущие запросы в этом же сеансе диалога.

Сущность изобретения

Хотя поля заголовка SIP, описанные выше, способствуют маршрутизации сообщений на узлы SIP и от них, такие как серверы на маршруте сообщения, многие из этих заголовков не являются безопасными при использовании по стандартам SIP (RFC3261). Например, атаки типа «отказ в обслуживании» могут направляться на сервер с многочисленными ложными сообщениями SIP, включающими в себя поддельную информацию о маршруте в заголовке SIP. Истинный отправитель поддельного сообщения может маскироваться ложной информацией заголовка, возможно, производя впечатление, что атака типа «отказ в обслуживании» исходит от невиновного сервера. Кроме того, ложные заголовки маршрутизации могут создавать сообщения, циклически передаваемые между двумя серверами. Таким образом, каждый сервер на ложном «маршруте» поддельного сообщения может бесполезно расходовать ценные ресурсы для обработки и пересылки поддельных сообщений, таким образом отказывая в этих ресурсах законным пользователям.

Варианты выполнения изобретения относятся к способам и считываемым компьютером носителям для аутентификации заголовков маршрутизации, обнаруживаемых в сообщении SIP. В частности, узел SIP может принимать запрос SIP, который включает в себя заголовок сообщения. Подпись может быть сгенерирована на основе по меньшей мере части заголовка сообщения и вставлена в вводимые данные заголовка узла SIP. Как используется в данной заявке, узел SIP означает приложение SIP, выполняющееся на вычислительном устройстве, которое может работать в качестве клиента или сервера SIP.

Например, первая подпись может быть сгенерирована на основе по меньшей мере части заголовков VIA в принимаемом заголовке запроса и вставлена в заголовок VIA для узла SIP. Когда генерируется ответ на запрос SIP, заголовок VIA узла SIP отражается обратно в заголовок ответа согласно стандартной обработке SIP. Когда узел SIP принимает ответ, узел SIP может верифицировать первую подпись в заголовке VIA узла SIP ответа для аутентификации целостности фактического пути, пройденного ответом.

Дополнительно или альтернативно, вторая подпись может быть сгенерирована на основе по меньшей мере части заголовков RECORD-ROUTE и заголовка CONTACT (контакт) заголовка сообщения. Вторая подпись может быть вставлена в заголовок RECORD-ROUTE узла SIP. Части данного заголовка RECORD-ROUTE с присоединенной второй подписью затем могут быть сохранены системой вызываемого абонента для использования в качестве заголовка ROUTE для маршрутизации и верификации запросов, генерируемых системой вызываемого абонента, на систему вызывающего абонента, после того как был инициирован сеанс.

Дополнительно или альтернативно, третья подпись может быть сгенерирована на основе по меньшей мере части заголовков RECORD-ROUTE заголовка сообщения. Третья подпись может быть вставлена в заголовок RECORD-ROUTE узла SIP. Когда вызываемый абонент отвечает на запрос SIP, заголовок RECORD-ROUTE узла SIP отражается обратно в заголовок ответа. Чтобы верифицировать целостность инструкций в отношении того, как маршрутизировать будущие запросы, третья подпись может быть верифицирована узлом SIP, когда узел SIP принимает ответ. Например, узел SIP, принимающий ответ, может идентифицировать заголовок RECORD-ROUTE, содержащий данные, отраженные из заголовка запроса, и извлекать подпись из отраженного заголовка. Узел SIP может генерировать подпись верификации, используя тот же процесс, что и используемый для генерирования третьей подписи, например генерирования подписи, основанной на по меньшей мере части заголовков в заголовке ответа. Узел SIP может затем сравнивать подпись верификации с извлеченной подписью. Если подписи совпадают, тогда сообщение может обрабатываться нормальным образом.

Четвертая подпись может быть сгенерирована и вставлена в заголовок ответа SIP. Например, узел SIP, принимающий ответ, может генерировать четвертую подпись, основанную на по меньшей мере части заголовков RECORD-ROUTE заголовка ответа и заголовка CONTACT заголовка ответа. Четвертая подпись аналогична второй подписи, описанной выше, однако, так как четвертая подпись генерируется на основе заголовка CONTACT в ответе, CONTACT идентифицирует вызываемого абонента, а не вызывающего абонента, как в случае с запросом. Четвертая подпись затем может быть вставлена в заголовок RECORD-ROUTE для узла SIP. Система вызывающего абонента, когда она принимает ответ, затем может сохранить части заголовка RECORD-ROUTE с присоединенной подписью в качестве заголовка ROUTE SET для использования и верификации инструкций по маршрутизации в последующих запросах.

В некоторых случаях узел SIP, обрабатывающий сообщения SIP, может обеспечиваться пулом серверов, имеющим по меньшей мере первый сервер и второй сервер, которые могут использоваться попеременно для обработки сообщений в одном и том же диалоге. Однако, так как происходит обмен сообщениями, запрос в диалоге может содержать подпись, генерируемую первым сервером, но может посылаться на второй сервер для обработки. Это требует того, чтобы второй сервер имел сеансовый ключ, который будет использоваться для верификации подписи в запросе. Для безопасной пересылки сеансового ключа, используемого для генерирования подписи в запросе, первый сервер, генерирующий подпись, может присоединять зашифрованный и подписанный сеансовый ключ к заголовку сообщения. Например, сеансовый ключ может быть вставлен в этот же заголовок, который включает в себя подпись, генерируемую данным ключом. Чтобы защитить сеансовый ключ от других узлов SIP, первый сервер может шифровать сеансовый ключ при помощи открытого ключа, доступного для пула серверов. Первый сервер затем может подписывать зашифрованный ключ при помощи секретного ключа, доступного для пула серверов. Второй сервер, принимающий запрос, может верифицировать подпись на зашифрованном ключе и затем расшифровывать сеансовый ключ. Используя расшифрованный сеансовый ключ, второй сервер затем может верифицировать подпись, основанную на по меньшей мере части заголовка сообщения. Необходимо понять, что может использоваться любой подходящий процесс обеспечения безопасности для защиты сеансового ключа, включая, например, технологии асимметричного ключа, включающие пары открытых/секретных ключей.

Перечень чертежей

Вышеприведенные аспекты и многие сопутствующие преимущества настоящего изобретения будут легко оценены по достоинству, когда они станут более понятными в результате ссылки на нижеследующее подробное описание, рассматриваемое совместно с прилагаемыми чертежами, на которых:

фиг.1 - принципиальная схема маршрута запроса INVITE (приглашение) и ответа между двумя клиентами протокола инициирования сеанса («SIP») согласно одному варианту выполнения изобретения;

фиг.2 - примерный запрос INVITE по фиг.1;

фиг.3 - примерный набор заголовков VIA по фиг.1;

фиг.4 - примерный набор заголовков RECORD-ROUTE по фиг.1;

фиг.5 - примерный ответ на запрос INVITE по фиг.2;

фиг.6 - примерный запрос, генерируемый узлом SIP вызываемого абонента по фиг.1;

фиг.7 - примерный запрос, генерируемый узлом SIP вызывающего абонента по фиг.1;

фиг.8 - схема примерного сервера SIP согласно одному варианту выполнения изобретения;

фиг.9 - схема примерной таблицы из базы данных информации о ключах согласно одному варианту выполнения изобретения;

фиг.10 - блок-схема последовательности операций, описывающая, как подпись VIA может быть сгенерирована согласно одному варианту выполнения изобретения;

фиг.11 - блок-схема последовательности операций, описывающая, как верифицировать заголовок VIA согласно одному варианту выполнения изобретения;

фиг.12 - блок-схема последовательности операций, описывающая, как подпись ROUTE SET и подпись RECORD-ROUTE могут быть сгенерированы согласно одному варианту выполнения изобретения;

фиг.13 - блок-схема последовательности операций, описывающая, как верифицировать подпись RECORD-ROUTE согласно одному варианту выполнения изобретения; и

фиг.14 - блок-схема последовательности операций, описывающая, как сеансовый ключ может быть импортирован на сервер в пуле серверов согласно одному варианту выполнения изобретения.

Подробное описание предпочтительного варианта выполнения

Атаки типа «отказ в обслуживании» обычно представляют собой компьютеризованные нападения, запускаемые злоумышленниками для перегрузки или останова сетевых служб, таких как Web-серверы или файловые серверы. Например, атака может вызвать то, что сервер станет настолько загруженным, пытаясь ответить на поддельные сообщения, что он игнорирует законные запросы на соединения. Альтернативно маршрутизация законных сообщений может быть нарушена и может вызывать неправильную пересылку ответов узлами SIP. В некоторых случаях протокол связи, используемый для передачи сообщений по компьютерной сети, может быть важной точкой для атаки. Например, как отмечено выше, поддельные сообщения SIP могут посылаться с ложными заголовками VIA, заголовками ROUTE и/или заголовками RECORD-ROUTE, таким образом направляя сообщения на страдающие от нападения узлы SIP и/или маскируя идентификационные данные и источник злоумышленника. Чтобы сократить такие атаки типа «отказ в обслуживании», инструкции по маршрутизации и фактические пути маршрутизации, содержащиеся в заголовках SIP, могут проверяться на достоверность для обеспечения их целостности.

На фиг.1 изображена примерная операция инициирования сеанса, при которой пользователь 100 (например, Алиса) клиента 102 SIP хочет инициировать сеанс связи с другим пользователем 400 (Бобом) по сети связи, которая может включать в себя Интернет, интрасеть, глобальную сеть, локальную сеть, виртуальную частную сеть и т.п. С этой целью клиент 102 SIP постоянно находящийся на компьютерной системе 104, посылает сообщение 500 с запросом INVITE, которое идентифицирует Боба в качестве предполагаемого получателя. В контексте связи по стандарту SIP клиент 102 SIP, который посылает сообщение 500 INVITE для инициирования сеанса, упоминается как «вызывающий абонент», и клиент 402 SIP на компьютерной системе 404 Боба упоминается как «вызываемый абонент». Как определено в SIP, клиент 102 SIP также называется «клиентом агента пользователя» («КАП»), так как он создает новый запрос, и клиент 402 SIP также называется «сервером агента пользователя» («САП»), так как он генерирует ответ 600 на запрос 500 SIP.

Как показано на фиг.1, сообщение 500 INVITE от Алисы посылается на сервер 200 исходящей связи для домена клиента SIP вызывающего абонента. После этого сообщение INVITE может проходить через многочисленные узлы SIP, включенные в операцию передачи сигналов, до того как оно достигнет прокси-сервера (сервера-посредника) 300 SIP домена Боба. Для простоты на фиг.1 изображено только пять узлов SIP, однако необходимо понять, что каждая линия связи может включать в себя другие серверы, шлюзы, мосты и т.п. Прокси-сервер 300 SIP направляет сообщение INVITE клиенту 402 SIP (вызываемому абоненту) компьютера Боба. Компьютер Боба может автоматически, или по разрешению от Боба, посылать ответ 600 на INVITE, такой как сообщение «200 (Все в порядке)», указывающее успешную передачу.

Как отмечено выше, каждое сообщение SIP, в общем случае, включает в себя стартовую строку, заголовок, содержащий информацию, касающуюся атрибутов и маршрутизации сообщения, и тело сообщения. Например, на фиг.2 изображено представление запроса 500 INVITE, посылаемого клиентом 102 SIP Алисы и принимаемого узлом 200 SIP. Примерный INVITE 500 включает в себя стартовую строку 502, множество заголовков 504 и тело 506. Стартовая строка 502 идентифицирует тип сообщения (в данном случае INVITE), запрашивающий URI, который, в основном, представляет собой адрес SIP вызываемого абонента, и версию SIP. Заголовки 504 представляют собой общепринятые поля по стандарту SIP. Заголовок 508 VIA содержит информацию, указывающую на протокол и адрес предыдущего сетевого сегмента. Заголовок 510 FROM (от кого) содержит информацию, указывающую на пользователя, отправляющего запрос (вызывающего абонента), в данном случае Алису. Заголовок 512 ТО (кому) содержит информацию, указывающую вызываемого абонента, задаваемого вызывающим абонентом. Заголовок 514 Call-ID (идентификатор вызова) содержит информацию, указывающую глобально уникальный идентификатор инициируемого сеанса. Заголовок 516 CSeq содержит информацию, указывающую идентификатор, который различает многочисленные сообщения, посылаемые с идентичными заголовками FROM, TO и Call-ID, как часть одной и той же транзакции. Заголовок 518 CONTACT содержит информацию, указывающую получателя для последующих запросов, позволяющую маршрутизации будущих сообщений обходить узлы SIP, не перечисленные в заголовках RECORD-ROUTE (дополнительно описанных ниже). Каждый из заголовка VIA, заголовка ТО, заголовка FROM, заголовка CONTACT, заголовка RECORD-ROUTE и заголовка ROUTE содержит данные, указывающие соответствующие маршрутизации местоположения в сети, такие как URI, адрес межсетевого протокола и т.п. Например, заголовок RECORD-ROUTE, содержащий данные, указывающие соответствующие маршрутизации местоположения, может включать в себя соответствующую часть URI, заключенную в скобки «< >», за которой следуют параметры заголовка. Соответствующая URI часть внутри скобок «< >» может включать в себя URI и параметр URI. В общих чертах, по меньшей мере одна пустая строка отмечает окончание заголовков 504 и начало части 506 тела. Примерный ответ 600, показанный на фиг.5, аналогично запросу INVITE, включает в себя стартовую строку 602, часть 604 заголовков и тело 606.

По стандарту SIP каждый узел SIP, который управляет INVITE 500, когда он проходит по сети, добавляет заголовок VIA к заголовку 504 INVITE. Таким образом, накопленные заголовки VIA могут использоваться вызываемым абонентом для направления маршрутизации ответа в ответ на запрос обратно вызывающему абоненту. Если узел SIP захочет продолжить управление сообщениями для этого конкретного диалога между вызывающим абонентом и вызываемым абонентом, узел SIP может вставить заголовок RECORD-ROUTE в заголовок 504 INVITE. Таким образом, чтобы направить маршрутизацию будущих запросов, которые могут генерироваться вызываемым абонентом, накопленные части URI заголовков RECORD-ROUTE и заголовка CONTACT для инициирующего диалог запроса могут быть сохранены принимающим вызываемым абонентом в качестве ROUTE SET заголовков в том же порядке, в котором они перечислены. Аналогично, чтобы предоставить инструкции по маршрутизации для будущих запросов, генерируемых вызывающим абонентом, накопленные части URI заголовков RECORD-ROUTE и заголовка CONTACT в ответ на инициирующий диалог запрос могут быть сохранены вызывающим абонентом в порядке, обратном порядку заголовков ROUTE SET.

На фиг.1 изображен конкретный пример маршрутизации запроса INVITE и ответа, принимая во внимание добавление заголовков посредством обработки узлов SIP. Для простоты не были включены посторонние заголовки и другая информация сообщения. Необходимо понять, что функции и количество изображенных узлов SIP являются примерными и что маршрутизация сообщений и верификация могут быть модифицированы для конкретных целей и/или сетевых архитектур.

Как показано на фиг.1, узлом 200 SIP может быть домашний сервер и он может принимать запрос INVITE от клиента 102 SIP. Узел 200 SIP, принимающий сообщение, вставляет заголовок VIA в заголовок 504 запроса INVITE. Узлу 200 SIP, в качестве домашнего сервера, может потребоваться управление любыми сообщениями SIP от клиента 102 SIP и на него. Следовательно, узел 200 SIP может вставлять заголовок RECORD-ROUTE в сообщение INVITE перед тем, как оно будет направлено на следующий узел SIP. В изображенном варианте выполнения по фиг.1 следующим узлом 250 SIP является пограничный сервер для клиента 102 SIP вызывающего абонента. Узел 250 SIP направляет сообщение INVITE после вставления своего собственного заголовка VIA и заголовка RECORD-ROUTE в заголовок 504 сообщения. В конечном счете сообщение INVITE маршрутизируется на узел 300 SIP, которым в изображенном варианте выполнения по фиг.1 является пограничный прокси-сервер клиента 402 SIP вызываемого абонента. Пограничным прокси-сервером может быть прокси-сервер, который предназначен для работы на границе сети, например, отделяя локальную сеть от Интернета. Аналогично пограничному серверу 250 пограничный прокси-сервер 300 вставляет заголовок VIA и заголовок RECORD-ROUTE в заголовок 504 INVITE перед пересылкой сообщения клиенту 402 SIP. Примеры заголовка 530 VIA узла 200 SIP, заголовка 532 VIA узла 250 SIP и заголовка 534 VIA узла 300 SIP, вставленных в запрос 500 INVITE, изображены на фиг.3. Примеры заголовка 520 RECORD-ROUTE узла 200 SIP, заголовка 522 RECORD-ROUTE узла 250 SIP и заголовка 524 RECORD-ROUTE узла 300 SIP, вставленных в сообщение 500 INVITE, изображены на фиг.4.

Узел 402 SIP Боба может принимать INVITE и может посылать ответ 600 «Все в порядке» в ответ на запрос INVITE. На фиг.5 изображен примерный ответ 600 от узла 402 SIP на сервер 300. По стандарту SIP многие поля заголовка, или по меньшей мере части полей заголовка, ответа 600 копируются или отражаются из принимаемого запроса. Эти отражаемые заголовки могут включать в себя, например, как определено по стандарту SIP, каждый заголовок VIA, заголовок FROM, заголовок TO, каждый заголовок RECORD-ROUTE, заголовок Call-ID и заголовок CSeq. Таким образом, ответ 600, показанный на фиг.5, иллюстрирует отражаемые заголовки. Конкретно заголовки 608, 630, 632, 634 VIA в ответе 600 идентичны заголовкам 508, 530, 532, 534 VIA в INVITE 500, принимаемым узлом 402 SIP вызываемого абонента. Аналогично заголовки 620, 622, 624 RECORD-ROUTE идентичны заголовкам 520, 522, 524 RECORD-ROUTE, генерируемым узлами SIP и принимаемым узлом 402 SIP вызываемого абонента. Сообщение с ответом затем маршрутизируется по сети, направляемое заголовками 608, 630, 632, 634 VIA на узел 102 SIP вызывающего абонента.

Узлы SIP, например узлы 300, 250, 200 SIP, обрабатывающие ответ, могут подтвердить целостность фактического маршрута, проходимого ответом, посредством проверки достоверности инструкций по маршрутизации, содержащихся в заголовках VIA. В одном варианте выполнения узел SIP может хранить информацию о маршруте, такую как заголовки 508, 530, 532 VIA, в базе данных для последующего доступа и использования для верификации заголовков 608, 630, 632 VIA. Альтернативно, для уменьшения объема памяти и нагрузок доступа на узел SIP узел SIP может генерировать подпись, основанную на по меньшей мере части по меньшей мере одного заголовка, который содержит данные, указывающие соответствующее маршрутизации местоположение в сети на маршруте сообщения. Например, подпись может основываться на всех заголовках, содержащих соответствующее маршрутизации местоположение в сети, или может основываться только на части данного заголовка, такой как URI, параметр URI, одноранговое полностью определенное доменное имя («FQDN») и т.п. Подпись может основываться на другой информации в дополнение к по меньшей мере одному заголовку, включающей в себя идентификатор соединения для соединения, по которому сообщение будет посылаться на следующий сетевой сегмент, отражаемый заголовок, заголовок TO, заголовок FROM, заголовок CONTACT, заголовок CALL-ID, заголовок CSeq и Branch-ID (идентификатор ветви). Подпись, основанная на по меньшей мере части по меньшей мере одного заголовка запроса, затем может быть перенесена в ответ и проверена на достоверность, когда ответ обрабатывается узлом SIP. Должна ли часть заголовка быть включена в подпись или нет, может зависеть от того, будет ли часть заголовка изменяться до того, как она будет верифицирована при помощи прокси-сервера SIP. Например, части заголовка, содержащие информацию, которая может быть удалена или изменена перед тем, как к ним будет осуществлен доступ для верификации подписи, не должны включаться в подпись. Необходимо понять, что любой или все из узлов SIP на маршруте сообщения SIP могут генерировать и хранить подпись верификации любым подходящим образом, включая тот, который описан в данном изобретении. Также необходимо понять, что заголовки сообщения SIP могут проверяться на достоверность соответствующим образом согласно факторам обеспечения безопасности и стандартам сети и узлов SIP, включая сохранение списка доверенных линий связи, соответствующих глобальной политике в отношении подписи, и подпись/проверку достоверности сообщений на/от конкретного домена. Например, чтобы реализовать список доверенных линий связи, каждый сервер может сохранять список линий связи, которые он считает доверенными. Таким образом, любое сообщение, передаваемое на/поступающее от доверенной линии связи, может не подписываться/проверяться на достоверность. Следовательно, сервер может проверять список доверенных линий связи перед генерированием/проверкой на достоверность подписи, чтобы удостовериться в том, что линия связи является недоверенной, например, не перечисленной в списке доверенных линий связи.

В одном примере подпись может быть сгенерирована на основе по меньшей мере одного заголовка VIA сообщения с запросом с использованием доступного сеансового ключа. Чтобы проверить достоверность маршрута, проходимого сообщением, узел SIP может генерировать подпись VIA, основанную на всех заголовках VIA или по меньшей мере всех заголовках VIA, принимаемых узлом SIP. Например, для сообщения 500 INVITE, показанного на фиг.1 и 2, узел 200 SIP может обеспечивать подпись VIA, основанную на заголовке 508 VIA, содержащем информацию, обозначающую клиента 102 SIP (Алису), посредством использования сеансового ключа, доступного для узла 200 SIP. Сгенерированная подпись VIA может быть сохранена в сообщении, переносимом в сообщение с ответом и затем проверяемом на достоверность при обратном прохождении сообщения через узел 200 SIP. Аналогично, узел 300 SIP может генерировать подпись VIA, основанную на принимаемых заголовках VIA, для последующей проверки на достоверность ответа, когда он принимается на узле 300 SIP. Чтобы подписать заголовки VIA, узел 300 SIP может генерировать подпись VIA, основанную на заголовке 508 VIA Алисы, заголовке 530 VIA узла 200 SIP и заголовке 532 VIA узла 250 SIP, используя доступный сеансовый ключ.

Необходимо понять, что любая подходящая комбинация заголовков VIA и другая информация заголовков может быть подписана для аутентификации инструкций по маршрутизации в заголовке 604 ответа. Например, подпись VIA может быть основана на части заголовков VIA в дополнение к частям заголовка TO, заголовка FROM или любого другого заголовка, который может быть отражен из заголовка 504 запроса в заголовок 604 ответа. Кроме того, подпись 550 VIA, вставленная в заголовок 504 запроса, может представлять собой любые данные или сигнал, указывающий на сгенерированную цифровую подпись. Например, хранимая подпись 550 может представлять собой предопределенное количество старших битов блоба сгенерированной подписи или может представлять собой целую цифровую подпись.

Чтобы гарантировать, что подпись VIA, сгенерированная во время обработки запроса INVITE, присутствует для верификации в ответе на узле SIP, сгенерированная подпись VIA может быть вставлена в отражаемый заголовок запроса INVITE. Например, подпись может быть вставлена в качестве параметра URI или параметра заголовка после стандартной информации о соответствующем маршрутизации местоположении. Таким образом, когда узел 402 SIP клиента генерирует заголовки 604 ответа, основанные на отражаемых заголовках запроса SIP, сгенерированные подписи автоматически переносятся из запроса в ответ. Следовательно, узел SIP, принимающий ответ, может проверять достоверность подписи, переносимой в заголовок ответа. Необходимо понять, что любой отражаемый заголовок или специальный заголовок, который отражается узлом SIP клиента, основываясь на предшествующем соглашении, может быть пригодным для хранения подписи для проверки достоверности узлом SIP.

Как показано на фиг.3, подпись VIA может быть вставлена в заголовок VIA узла SIP, генерирующего подпись. Например, узел 300 SIP может генерировать подпись 550 VIA, основанную на заголовках 508, 530, 532 VIA, принимаемых в запросе 500. Узел 300 SIP может вставлять подпись 550 VIA в заголовок 534 VIA узла 300 SIP. Как отмечено выше, заголовки VIA в заголовке запроса отражаются обратно в заголовки 604 ответа. Таким образом, когда узел 402 SIP формирует ответ 600, он может копировать информацию, содержащуюся в заголовке 534 VIA, в заголовок 634 VIA узла 300 SIP (фиг.1). При стандартной обработке SIP, так как заголовок VIA отражается, копируется стандартная информация VIA, а также любая информация, присоединенная в качестве параметра заголовка, такая как подпись 550 VIA.

Чтобы проверить достоверность принимаемой подписи 650 VIA, узел 300 SIP (фиг.1) может отделить и сохранить принимаемую подпись 650 VIA, показанную на фиг.5. Узел 300 SIP может генерировать подпись VIA проверки достоверности, используя те же процедуры, что и используемые для генерирования подписи 550 VIA, вставленной в запрос. Согласно генерированию подписи 550 VIA, описанной выше, узел 300 SIP может идентифицировать заголовки VIA в принимаемом ответе 600 и генерировать подпись VIA проверки достоверности, основанную на всех заголовках VIA, перечисленных ниже заголовка 534 VIA узла 300 SIP. Таким образом, подпись VIA проверки достоверности может основываться на тех заголовках VIA, которые были известны узлу 300 SIP, когда он генерировал подпись 550 VIA в сообщении 500 с запросом. Следовательно, подпись VIA проверки достоверности для узла 300 SIP может основываться на заголовке 632 SIP для узла 250 SIP, заголовке 630 VIA для узла 200 SIP и заголовке 608 VIA для узла 102 SIP вызывающего абонента. Узел 300 SIP может сравнивать подпись VIA проверки достоверности с принимаемой подписью 650 VIA.

Если подписи действительно совпадают, узел 300 SIP может продолжать нормальную обработку по стандарту SIP и направить ответ следующему узлу SIP, указанному в заголовках VIA заголовков 604 ответа. Если подписи не совпадают, узел 300 SIP может выбросить ответ 600 из своего стека обработки и/или послать сообщение об ошибке службе контроля узлов SIP (не показана) или любому соответствующему агенту контроля, если это поддерживается протоколом. Чтобы оценить выполнение обработки сообщений для совпадения подписей и/или обнаружения атак, узел 300 SIP может инкрементировать счетчик неудачных выполнений сравнения подписей для каждого отброшенного сообщения. Счетчик неудачных выполнений сравнения подписей может представлять собой любые данные или сигнал, указывающий на неудачи узла SIP при верификации подписей заголовков. Например, счетчик неудачных выполнений сравнения подписей может подсчитывать количество неудачных проверок достоверности подписей в течение некоторого периода времени. Счетчик неудачных выполнений сравнения подписей затем может быть сравнен с предопределенным пороговым значением неудачных проверок достоверности подписей для этого периода времени, таких как примерно 6 неудачных проверок достоверности подписей, примерно 10 неудачных проверок достоверности подписей или примерно 25 неудачных проверок достоверности подписей примерно за 1 секунду времени обработки сообщений. Когда счетчик выполнений превысит порог, узел SIP может уведомлять или предупреждать системного администратора-человека (включая передачу сообщений по электронной почте и/или пейджеру) и/или основанного на компьютере системного администратора, который может инициировать предопределенные действия, основанные на счетчике выполнений, включая, например, сброс сетевых соединений, маршрутизирующих неудачные сообщения, блокирование сети и/или очистку очередей сообщений.

В некоторых случаях подпись может быть сгенерирована и/или проверена на достоверность на каждом этапе маршрута, например на каждом узле SIP, обрабатывающем запрос и/или ответ при обратном прохождении. Однако, чтобы снизить вычислительную нагрузку на серверы узлов SIP, может проверяться достоверность сообщения только тогда, когда это требуется.

Например, если запрос содержит только один заголовок VIA, например заголовок 508 VIA узла 102 SIP Алисы в запросе 500, подпись может не генерироваться в запросе на узле. Более конкретно, узлу 102 SIP Алисы может не потребоваться верификация каких-либо инструкций по маршрутизации в ответе 600, так как ответ будет использоваться узлом 102 SIP, например, он не будет пересылаться далее. Таким образом, подпись VIA может не генерироваться, когда запрос содержит только один заголовок VIA, и, соответственно, может не потребоваться верификация подписи VIA, когда принимаемый запрос содержит только 1 заголовок VIA, например заголовок VIA принимающего узла SIP.

В дополнительном примере атаки типа «отказ в обслуживании» могут быть более вероятными, если сообщение принимается по недоверенному соединению. Чтобы повысить безопасность сообщения, может проверяться достоверность сообщения, когда оно принимается по недоверенному соединению. Например, недоверенное соединение может включать в себя любое клиентское соединение для любого типа сервера, так как сообщения, принимаемые от других серверов, могут аутентифицироваться при помощи других способов. Недоверенное соединение также может включать в себя соединение с внешним сервером для пограничного прокси-сервера и, более конкретно, может включать в себя соединения со всеми внешними серверами.

Как показано на фиг.1, соединения 210, 212 между узлом 200 SIP и узлом 250 SIP могут быть доверенными соединениями, так как данные соединения могут считаться внутренними линиями связи между домашним сервером и пограничным сервером. Так как серверы могут иметь другие способы аутентификации трафика сообщений между серверами, линии 260, 262 связи между узлом 250 SIP и узлом 300 SIP могут представлять собой доверенные соединения; однако данные линии связи могут считаться недоверенными в некоторых случаях, особенно если другие способы аутентификации сервера считаются недостаточными. Линии 310, 312 связи между узлом 402 клиента и узлом 300 SIP могут представлять собой недоверенные соединения, так как сообщения SIP посылаются на/от узла SIP клиента. Следовательно, на узле SIP может проверяться достоверность любого трафика сообщений, принимаемого по недоверенному соединению, такому как линия 312 связи, для верификации целостности и/или аутентификации сообщения.

Если ответы, принимаемые по доверенным линиям связи, не будут проверяться на достоверность, тогда нет необходимости генерировать подпись VIA, когда запрос будет пересылаться на следующий узел SIP по доверенной линии связи. Например, узлы 200 и 250 SIP могут не принимать ответ 600 по недоверенному соединению, и поэтому эти узлы могут не генерировать или сохранять подпись VIA в заголовках 504 запроса INVITE, так как для них может отсутствовать необходимость проверять достоверность маршрута ответа. Следовательно, перед генерированием подписи VIA узел SIP может определить, требуется ли проверка достоверности соответствующего ответа. Если не требуется верификация ответа, например, следующая линия связи является доверенным соединением, тогда не требуется генерирование подписи VIA, и может продолжаться нормальная обработка запроса SIP. Однако, если соответствующий ответ будет приниматься на узле SIP по недоверенному соединению, тогда может быть сгенерирована подпись VIA, как описано выше. Аналогично, после приема ответа узел SIP может сначала определить, принимается ли ответ от недоверенного соединения. Если да, тогда может проверяться достоверность подписи VIA, если она присутствует. Например, узел 300 SIP может определить, принимается ли ответ 600 по недоверенному соединению. Как показано на фиг.1, линия 312 связи представляет собой недоверенное соединение. Как результат, узел 300 SIP может тогда идентифицировать заголовок 634 VIA узла 300 SIP в заголовке 604 ответа. Узел 300 SIP может определить, присутствует ли подпись в идентифицированном заголовке 634 VIA. Если подпись VIA не присутствует, узел 300 SIP может послать сообщение об ошибке, если это разрешено протоколом, может выбросить сообщение из своего стека обработки, может инкрементировать счетчик неудачных выполнений сравнения подписей и/или предпринять любое другое надлежащее действие. Если подпись 650 VIA присутствует, как показано на фиг.5, узел 300 SIP может верифицировать эту подпись, как описано выше.

Подписание заголовков VIA, как отмечено выше, может способствовать проверке целостности инструкций по маршрутизации в заголовке 604 ответа. Однако узел SIP может дополнительно или альтернативно потребовать проверку достоверности инструкций по маршрутизации для запроса, генерируемого вызываемым абонентом. Следовательно, узел SIP может генерировать подпись, основанную на по меньшей мере части по меньшей мере одного из заголовков RECORD-ROUTE инициирующего диалог запроса, и затем проверить достоверность данной подписи в последующем запросе от вызываемого абонента, чтобы гарантировать целостность инструкций по маршрутизации запроса в диалоге.

Чтобы гарантировать целостность маршрута, проходимого запросом вызываемого абонента, узел SIP может генерировать подпись ROUTE SET вызываемого абонента, основанную на соответствующих URI частях заголовков RECORD-ROUTE и заголовка CONTA