МЕХАНИЗМ АДРЕСАЦИИ И МАРШРУТИЗАЦИИ ДЛЯ КЛАСТЕРОВ ВЕБ-СЕРВЕРОВ Российский патент 2011 года по МПК H04L29/06 

ОБЛАСТЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ

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

ОПИСАНИЕ ПРЕДШЕСТВУЮЩЕГО УРОВНЯ ТЕХНИКИ

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

С революционными изменениями в передаче данных и в компьютерной промышленности в начале 1990-х небольшие устройства связи и компьютеры стали более широко доступны, а изобретение Всемирной паутины и все услуги, которые появились с этим, наконец сделали Интернет привлекательным для среднего человека. Комбинация увеличения использования сетей и мобильной передачи данных создала потребность в безопасном управлении подвижностью в Интернет.

Увеличивающееся количество участвующих сторон и денежные операции, которые необходимы для определенных услуг, также создали потребность в дополнительном обеспечении безопасности уровня приложений. В настоящее время наиболее широко используемые протоколы шифрования, например SSL/TLS (протокол защищенных сокетов/протокол защиты транспортного уровня), работают на верхних сетевых уровнях, например в TCP (протокол управления передачей).

Учитывая указанные выше проблемы управления подвижностью и обеспечения безопасности, были введены стандарт Mobile IP (C. Perkins, «IP Mobility Support for IPv4», RFC 3220, IETF, 2002) и стандарт Mobile IPv6 (D. Johnson, C. Perkins, J. Arkko, «Mobility Support in IPv6», RFC3775, IETF 2004). Вместе эти спецификации запланированы для обеспечения поддержки подвижности в Интернет следующего поколения. Механизм обеспечения безопасности развивается в форме стандарта Ipsec, и связанных действиях, таких как различные протоколы обмена ключами, с целью обеспечения безопасности на уровне IP (Интернет-протокола). Однако опыт показывает, что довольно трудно обеспечивать объединение обеспечения безопасности и подвижности, используя существующие стандарты.

IP-адрес описывает топологическое расположение узла в сети. IP-адрес используется для маршрутизации пакета от узла-источника к адресату. В то же самое время IP-адрес также используется для идентификации узла, обеспечивая две различных функции в одном объекте. Это похоже на то, когда человек отвечает своим домашним адресом, когда спрашивают, кто он. Когда также рассматривают подвижность, ситуация становится еще более сложной: так как IP-адреса действуют в качестве идентификаторов хостов в этой схеме, они не должны изменяться; однако, так как IP-адреса также описывают топологическое расположение, они должны обязательно изменяться, когда хост изменяет свое расположение в сети. Ясно, что невозможно одновременно обеспечивать и стабильность и динамическое изменение.

В случае стандарта Mobile IP решение состоит в использовании фиксированного расположения в пределах собственной сети, обеспечивая «домашний адрес» для узла. Домашний адрес идентифицирует узел и обеспечивает стабильное расположение для него, когда он находится в домашней сети. Информация о текущем расположении доступна в форме временного адреса, который используется для целей маршрутизации, когда узел находится вне домашней сети.

Другое решение проблемы состоит в отделении друг от друга функций идентификации и определения местоположения, и это является подходом, используемым в предложенном протоколе идентификации хоста (HIP) (R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, «Host Identity Protocol», Internet Draft, work in progress, draft-ietf-hip-base-05.txt, IETF, 2006). В HIP разделяют роли IP-адресов по определению местоположения и идентификации, вводя новое пространство имен, идентификаторов хостов (HI). В HIP идентификатором хоста является в основном открытый криптографический ключ пары открытого и секретного ключей. Открытый ключ идентифицирует сторону, которая хранит единственную копию секретного ключа. Хост, обладающий секретным ключом пары ключей, может непосредственно доказать, что ему «принадлежит» открытый ключ, который используется для его идентификации в сети. Такое разделение также обеспечивает средство для обработки подвижности и подключения к множеству сетей безопасным способом. В дополнение к отделению определения положения от идентификации в HIP обеспечивают согласование безопасного соединения (контекста безопасности) (SA) между узлами, которые поддерживают HIP.

Каждый HIP-хост может генерировать краткосрочные ключи, которые будут использоваться только в течение короткого времени. Они применяются, когда позднее не требуется идентифицировать узел с помощью того же самого идентификатора. Например, покупка книг в книжном магазине может быть долгосрочными взаимоотношениями, в то время как установление связи с сервером один раз для сбора профилей пользователей можно рассматривать как краткосрочное действие. В последнем случае может быть создан краткосрочный идентификатор, чтобы избежать более широкого распространения долгосрочного идентификатора. Идентификатор HIP-хоста (HI), который является открытым ключом, может быть весьма длинным и поэтому непрактичен во всех ситуациях. В HIP HI представлен имеющей длину 128-битов меткой идентификатора хоста (HIT), которую генерируют из HI с помощью его хеширования. Таким образом HIT идентифицирует HI. Так как HIT имеет длину 128 битов, она может непосредственно использоваться для приложений IPv6, поскольку она имеет точно ту же самую длину, как IPv6-адрес.

Другим представлением идентификатора хоста является идентификатор локальной области (LSI), который является 32-разрядным представлением идентификатора хоста. Целью LSI является обеспечение использования идентификаторов хоста в существующих протоколах и API (в интерфейсе прикладных программ). Например, так как LSI имеет ту же самую длину, как IPv4-адрес, его можно непосредственно использовать для приложений IPv4. Хотя большая часть остального описания будет основана на использовании более длинного HIT, следует признать, что те же самые или подобные рассмотрения относятся к альтернативному представлению LSI.

Фиг. 1 на сопроводительных чертежах показывает различные уровни в HIP, содержащие стандартные транспортный уровень 4, сетевой уровень 8 и канальный уровень 10, причем процесс 2 осуществляет связь с транспортным уровнем 4, расположенным ниже его. При использовании HIP новый уровень 6 идентификации хоста расположен между транспортным уровнем 4 и сетевым уровнем 8.

Локально каждый HI и связанный с ним HIT отображают на IP-адреса узлов. Когда пакеты покидают хост, выбирают правильный маршрут (с помощью любых средств), и соответствующие IP-адреса помещают в пакет в качестве адресов источника и получателя. Каждый пакет, приходящий от верхнего уровня, содержит HIT узла сети в качестве адреса получателя. Отображение между HIT и информацией расположения можно найти на уровне 6 HI. Следовательно, адрес получателя преобразуют в отображаемый IP-адрес, и HIT источника преобразуют в IP-адрес источника.

Отображение между HIT и IP-адресом узла сети может быть получено клиентом HIP несколькими способами, одним из которых является получение от сервера DNS (сервера доменных имен). Как правило, сервер DNS принимает запрос от клиента для разрешения доменного имени Интернет, например www.serviceprovider.com. Информацию о расположении, хранящуюся в сервере DNS, можно обновлять с помощью узла сети в любое время.

Протокол HIP определяет основной обмен сообщениями, содержащий четыре сообщения, четырехэтапное установление связи, и он используется для создания безопасного соединения (SA) между хостами, которые поддерживают HIP. Во время обмена сообщениями процедура Диффи-Хеллмана (Diffie-Hellman) используется для создания ключа сеанса и установки пары безопасных соединений (SA) протокола безопасного закрытия содержимого (ESP) IPsec между узлами. Фиг. 2 на сопроводительных чертежах показывает операцию четырехэтапного установления связи. Ведущие переговоры стороны упоминаются как «инициатор», который начинает соединение, и «отвечающий». Инициатор начинает переговоры, посылая пакет I1, который содержит HIT узлов, участвующих в переговорах. HIT адресата может также быть установлен в ноль, если HIT отвечающего не известен инициатору.

Когда отвечающий получает пакет I1, он отсылает обратно пакет R1, который содержит задачу, которую будет решать инициатор. Протокол разработан так, чтобы инициатор делал большую часть вычислений во время решения задачи. Это дает некоторую защиту против атак «отказ в обслуживании». R1 инициирует также процедуру Диффи-Хеллмана, содержащую открытый ключ отвечающего вместе с параметрами Диффи-Хеллмана.

Когда пакет R1 принимают, инициатор решает задачу и посылает ответный куки-файл в пакете I2 вместе со значением SPI IPsec и его зашифрованным открытым ключом отвечающему. Отвечающий проверяет, что задача решена, аутентифицирует инициатора и создает SA ESP IPsec. Окончательное сообщение R2 содержит значение SPI отвечающего.

SA между хостами связаны с идентификаторами хостов, представленными с помощью HIT. Однако пакеты, передаваемые по сети, не содержат фактическую информацию HI, но прибывающий пакет идентифицируют и отображают на правильное SA, используя значение индекса параметра безопасности (SPI) в заголовке IPsec. Когда исходящий пакет достигает уровня HI от расположенного выше уровня, HIT адресата проверяют в SADB IPsec. Если найдено SA, соответствующее HIT адресата, то пакет шифруют, используя ключ сеанса, связанный с SA. Фиг. 3 на сопроводительных чертежах показывает логическую и фактическую структуры пакета в сети.

Мобильный хост может изменять расположение в одной сети доступа, между различными технологиями доступа или даже между различными областями IP-адресов, например между сетями IPv4 и IPv6. В HIP приложение не обращает внимание на изменение версии IP-адреса. Уровень HI полностью скрывает эти изменения от верхних уровней. Конечно, узел сети должен иметь возможность обрабатывать обновление расположения, которое изменяет версию IP, и пакеты должны иметь возможность маршрутизации, используя некоторый совместимый адрес. Если узел не имеет возможности осуществления связи ни с помощью IPv4, ни с помощью IPv6, то он может использовать прокси-узел, который выполняет преобразование версии адреса и обеспечивает связь от имени узла.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Фиг. 1 показывает «веб-ферму», которая состоит из нескольких веб-серверов. Серверы расположены в частной сети за обратным прокси-сервером сети. Обратный прокси-сервер является единой контактной точкой для всех серверов, расположенных за ним. Он направляет соединение на различные веб-серверы. Выбор сервера может основываться, например, на балансировании загрузки или на других политиках. В существующей Интернет-архитектуре доменное имя Интернет веб-сайта отображают на IP-адрес обратного прокси-сервера сети. Например, www.serviceprovider.com отображают на IP-адрес обратного прокси-сервера, который может переадресовывать соединение к некоторому другому IP-адресу, расположенному за ним.

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

Одним из решений является отображение множества IP-адресов на один HI в сервере DNS. Однако это трудно сделать, поскольку когда один веб-сервер добавляют или удаляют из кластера, администратор должен обновлять отображение FQDN (полного доменного имени) на HIT в DNS. Другим решением является использование единого HI, сохраняя одинаковый секретный ключ во всех участвующих компьютерах. Однако это не является масштабируемым решением, а также это не очень хорошо с точки зрения обеспечения безопасности, поскольку секретный ключ должен храниться только в одном месте для минимизации риска раскрытия ключа.

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

обеспечивают обратный прокси-сервер материалом открытого ключа Диффи-Хеллмана второго хоста;

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

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

Как известно специалистам, обратный прокси-сервер является прокси-сервером, который действует в качестве шлюза к серверной ферме протокола http (протокола передачи гипертекстовых файлов) или к коллекции других хостов, действуя в качестве конечного IP-адреса для запросов, приходящих извне. С точки зрения внешнего клиента обратный прокси-сервер является сервером протокола http.

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

В определенных вариантах осуществления изобретения материал секретного ключа Диффи-Хеллмана, соответствующий указанному материалу открытого ключа Диффи-Хеллмана, сохраняют только с помощью второго хоста и не обеспечивают обратному прокси-серверу. Шифрование/дешифрование и/или аутентификацию пакетов данных не выполняют в обратном прокси-сервере.

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

Варианты осуществления изобретения приводят к отделению сервера (второго хоста), который создает материал D-H, от обратного прокси-сервера, который подписывает соответствующее сообщение R1, содержащее D-H TLV. Сервер связывает свои соединения с HI обратного прокси-сервера. Сервер не должен знать секретный ключ обратного прокси-сервера. В результате связь с сервером за прокси-сервером прозрачна для первого хоста. Один обратный прокси-сервер может представлять несколько серверов, принадлежащих тому же самому кластеру.

Все серверы в кластере можно идентифицировать, используя один идентификатор хоста (HI). Администратор может добавлять и удалять серверы из кластера, не беспокоясь об управлении HI или обновлениях DNS. С точки зрения хоста первый хост принимает только один HI от DNS, который связан, например, с определенным веб-сайтом. Хост не должен заботиться о множестве HI. Он может оставить, например, работу по балансированию загрузки обратному прокси-серверу, который отвечает за переадресацию трафика между различными серверами за обратным прокси-сервером.

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

средство для приема материала открытого ключа второго хоста и для сохранения указанного материала;

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

средство для направления пакетов, впоследствии принимаемых от первого хоста, на второй хост.

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг. 1 показывает схематически различные уровни в протоколе идентификации хоста;

фиг. 2 показывает операцию четырехэтапного установления связи в протоколе HIP;

фиг. 3 показывает логическую и фактическую структуры пакета в HIP;

фиг. 4 показывает схематично веб-ферму или кластер;

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТА ОСУЩЕСТВЛЕНИЯ

Далее представлены основные положения процедуры использования HIP в контексте веб-фермы, которая показана на фиг. 4.

Во время фазы инициализации, когда новый веб-сервер устанавливают в веб-ферме частной сети, новый сервер создает свои собственные открытый и секретный ключи. Таким образом он получает свой собственный идентификатор хоста. Ему нужен также материал ключа Диффи-Хеллмана, который будет использоваться позже для создания секретного ключа, который совместно используют с узлом сети во время основного обмена HIP. Новый сервер генерирует секретную часть (D-H-private) и открытую часть (D-H-public). Веб-сервер регистрируется в высоконадежном обратном прокси-сервере серверной фермы и посылает значение D-H-public в обратный прокси-сервер. Обратный прокси-сервер генерирует пакет R1, который содержит значение D-H-public сервера, и подписывает его с помощью своего собственного секретного ключа HI. Обратный прокси-сервер таким образом поддерживает множество пакетов R1, по меньшей мере, один для каждого из узлов-серверов в серверной ферме. Эта ситуация показана на фиг. 5.

Когда клиент за пределами частной сети получает FQDN-название веб-фермы (например, www.serviceprovider.com), он видит сайт как один сервер. DNS возвращает клиенту IP-адрес и HI обратного прокси-сервера. Клиент создает HIT из HI обратного прокси-сервера, и затем создает пакет I1, содержащий HIT, и посылает его в обратный прокси-сервер. Обратный прокси-сервер выбирает подходящий веб-сервер в пределах частной сети, основываясь на некоторой политике (например, на балансировании загрузки), и отвечает отправителю пакета I1 предварительно подписанным пакетом R1, соответствующим выбранному серверу. Клиент аутентифицирует подпись в пакете R1, используя HI обратного прокси-сервера. Он затем решает задачу в пакете R1, создает пакет I2, содержащий решение задачи, и посылает его в обратный прокси-сервер. Обратный прокси-сервер проверяет решение задачи и направляет сообщение I2 на расположенный за ним правильный сервер. Сервер проверяет пакет I2, создает материал ключа и устанавливает пару SA IPsec, чтобы использовать с клиентом.

Следует отметить, что веб-сервер не знает секретный ключ HIP обратного прокси-сервера. Однако сервер может связывать локальные соединения и SA IPsec с HIT обратного прокси-сервера. Другими словами, сервер не может подписывать сообщения HIP, идущие к клиенту, потому что он не знает секретный ключ HI прокси-сервера, но он может использовать HIT обратного прокси-сервера для связывания соединений. Обратный прокси-сервер подписывает сообщения R1 и R2 с помощью своего собственного секретного ключа. Таким образом клиент не знает, что он фактически осуществляет связь с сервером.

Сервер отвечает сообщением R2, включающим в себя значение SPI ESP сервера. Сервер использует свой собственный секретный ключ HI, чтобы подписать пакет R2. Когда обратный прокси-сервер принимает пакет R2, он проверяет подпись сервера. Обратный прокси-сервер сети заменяет подпись сервера в R2 своей собственной. Пакет R2, подписанный обратным прокси-сервером, посылают клиенту. Результатом является то, что клиент думает, что он осуществляет связь с обратным прокси-сервером, но сквозной материал ключа совместно используется и трафик IPsec протекает между клиентом и сервером.

Подробный поток обмена сообщениями для данного механизма показан на фиг. 6, где у клиента есть идентификатор «HI - клиент», у обратного прокси-сервера есть идентификатор «HI - обратный прокси-сервер» и у сервера есть идентификатор «HI - сервер». Этапы обмена сигналами следующие:

1. Веб-сервер генерирует пару ключей D-H. Пара ключей D-H состоит из открытого и секретного материала. Секретный материал сохраняют только в сервере, а открытый материал посылают в прокси-сервер в фазе регистрации (см. этап 3).

2. Администратор кластера определяет основной обратный прокси-сервер для сервера. Сервер заранее узнает HI (открытый ключ) обратного прокси-сервера.

3. Сервер регистрирует свой открытый материал D-H (D-H public) (в HIP его передают в параметре DIFFIE_HELLMAN, который называют D-H TLV) в обратном прокси-сервере. Сервер использует регистрационный обмен HIP [draft-koponen-hip-registration-01] для регистрации D-H TLV в обратном прокси-сервере. Значение D-H TLV должно подписываться в регистрационном сообщении с помощью сервера. Обратный прокси-сервер создает и сохраняет сообщение R1, содержащее D-H TLV сервера. Сохраненное сообщение R1 подписывают с помощью секретного ключа HI обратного прокси-сервера. Обратный прокси-сервер создает (по меньшей мере) один пакет R1 для каждого из серверов, расположенных за ним. Он должен проверять, что каждый пакет R1, который он создает, имеет различное случайное I-значение в задаче. Это I-значение позже используется для идентификации прихода пакета I2.

4. Веб-клиент решает установить связь с веб-сайтом (например, www.serviceprovider.com) и получает HIT и IP-адрес, устанавливая связь с DNS. Он получает HI и IP-адрес для обратного прокси-сервера. Клиент создает и посылает сообщение I1 в обратный прокси-сервер. I1 содержит HIT обратного прокси-сервера, и его направляют к IP-адресу обратного прокси-сервера.

5. Когда обратный прокси-сервер принимает сообщение I1, он принимает решение о том, какой из расположенных за ним веб-серверов будет обслуживать данного клиента. Это решение основано на локальной политике, например, в зависимости от текущей загрузки различных серверов. Обратный прокси-сервер затем выбирает сообщение R1, предварительно сгенерированное для выбранного сервера, которое содержит значение D-H public сервера. Обратный прокси-сервер отвечает клиенту этим сообщением R1, таким образом обеспечивая клиента открытым материалом D-H (D-H public) выбранного веб-сервера.

6. Клиент решает задачу в сообщении R1, создает пакет I2, содержащий его открытый материал D-H, и посылает его в обратный прокси-сервер. Обратный прокси-сервер проверяет I-значение в задаче (которое также идентифицирует обратный прокси-сервер, который он выбрал), проверяет задачу в сообщении I2 и направляет сообщение I2 на правильный сервер.

7. Сервер принимает сообщение I2. Cообщение I2 содержит HIT и клиента и обратного прокси-сервера.

8. Сервер проверяет сообщение, используя открытый материал D-H клиента, и генерирует материал ключа HIP и IPsec, используя свой собственный материал ключа D-H (см. этап 1), и D-H TLV клиента. Сервер связывает пару SA с HI обратного прокси-сервера и клиента. Сервер впоследствии использует HIT обратного прокси-сервера для вычисления контрольных сумм пакета. [Следует обратить внимание, что клиент не знает собственный HIT сервера.]

9. Сервер посылает в обратный прокси-сервер сообщение R2, содержащее значение SPI сервера. Он подписывает пакет R2 с помощью своего собственного секретного ключа HI-сервера.

10. Обратный прокси-сервер проверяет подпись в пакете R2, удаляет подпись сервера из пакета и добавляет свою собственную подпись, используя секретный ключ HI-обратного прокси сервера.

11. Обратный прокси-сервер посылает повторно подписанный пакет R2 клиенту.

12. Результатом является то, что клиент и сервер совместно используют тот же самый материал ключа, и что этот материал известен только им (а не обратному прокси-серверу). Связь с сервером однако прозрачна для клиента, и клиент полагает, что он осуществляет связь с прокси-сервером. Клиент посылает пакеты ESP IPsec в обратный прокси-сервер, который в свою очередь направляет пакеты на сервер.

Описанный выше подход поддерживает сквозное обеспечение безопасности между клиентом и веб-сервером. Однако предполагая, что канал связи между обратным прокси-сервером и веб-сервером безопасен и что совместное использование секретных ключей в частной сети не является проблемой, альтернативным подходом для веб-серверов является делегирование ключей шифрования и/или аутентификации IPsec обратному прокси-серверу. Когда у обратного прокси-сервера есть ключи шифрования, он может обрабатывать данные аутентификации и шифрования/дешифрования, оставляя данные в канале связи между обратным прокси-сервером и незащищенными веб-серверами. Когда у обратного прокси-сервера есть ключи аутентификации, он может аутентифицировать входящие пакеты, таким образом защищая веб-сервера от атак «отказ в обслуживании». Этот подход может быть изменен так, чтобы только аутентификация выполнялась в обратном прокси-сервере, а не шифрование/дешифрование. Это также будет обеспечивать удобную услугу «привратника» для веб-серверов.

Рассматривая альтернативный подход более подробно, когда веб-сервер захочет делегировать ключи IPsec обратному прокси-серверу, он добавляет ключи к параметру в сообщении R2 (измененный приведенный выше этап 10). Сообщение R2 требует новых параметров для этой цели: KEY_ENCR, содержащий ключи шифрования, и KEY_AUTH, содержащий ключи аутентификации. Когда обратный прокси-сервер принимает любой из этих параметров, он сохраняет ключи и удаляет их из пакета R2. Пакет R2 повторно подписывают и посылают дальше к клиенту. Основываясь на этой информации ключа, обратный прокси-сервер может выполнять требуемые криптографические операции. Может ли обратный прокси-сервер создавать ключи вместо того, чтобы принимать их от веб-сервера?

Возможно, чтобы клиент и веб-сервер выполняли повторный обмен ключами, используя сообщения «UPDATE». В этом случае сообщение «UPDATE» от сервера должно содержать параметры KEY_ENCR и/или KEY_AUTH, если соответствующие операции были делегированы обратному прокси-серверу. Обратный прокси-сервер сохраняет информацию ключа, удаляет эти параметры и повторно подписывает пакет перед доставкой его клиенту. Поскольку процедура «UPDATE» является трехэтапным установлением связи, и любая из сторон может инициировать ее, сообщение, которое включает в себя эти KEY-параметры, зависит от того, кто инициирует повторный обмен ключами. Если ее инициирует клиент, то второе сообщение «UPDATE» (единственное сообщение, посылаемое сервером) содержит эти параметры, а если ее инициирует сервер, то их содержит третье сообщение «UPDATE». Фиг. 7 показывает, когда клиент инициирует процесс повторного обмена ключами.

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

Изобретение относится к передаче данных, а именно к способу установления сеанса протокола идентификации хоста между первым и вторым хостами, поддерживающими протокол идентификации хоста, когда указанный второй хост расположен за обратным прокси-сервером. Техническим результатом является повышение масштабируемости и безопасности сети. Технический результат достигается тем, что способ содержит обеспечение обратного прокси-сервера материалом открытого ключа Диффи-Хеллмана (Diffie-Hellman) второго хоста, передачу указанного материала открытого ключа Диффи-Хеллмана с обратного прокси-сервера на первый хост как часть основной процедуры обмена протокола идентификации хоста, данный материал связывают с идентификатором хоста обратного прокси-сервера для целей сеанса протокола идентификации хоста, и в первом хосте используют идентификатор хоста обратного прокси-сервера в качестве идентификатора корреспондента для сеанса протокола идентификации хоста, а во втором хосте используют идентификатор хоста обратного прокси-сервера в качестве идентификатора вызывающего для сеанса протокола идентификации хоста. 3 н. и 5 з.п. ф-лы, 7 ил.

1. Способ установления сеанса протокола идентификации хоста между первым и вторым хостами, поддерживающими протокол идентификации хоста, где, по меньшей мере, указанный второй хост расположен за обратным прокси-сервером, причем способ содержит этапы, на которых:
обеспечивают обратный прокси-сервер материалом открытого ключа Диффи-Хеллмана второго хоста;
передают указанный материал открытого ключа Диффи-Хеллмана с обратного прокси-сервера на первый хост как часть основной процедуры обмена протокола идентификации хоста и используют этот материал для установления пары безопасных соединений между первым и вторым хостами, данные безопасные соединения связывают с идентификаторами хостов обратного прокси-сервера и указанного второго хоста для целей сеанса протокола идентификации хоста; и
в первом хосте используют идентификатор хоста обратного прокси-сервера в качестве идентификатора хоста-корреспондента для сеанса протокола идентификации хоста, а во втором хосте используют идентификатор хоста обратного прокси-сервера в качестве идентификатора вызывающего хоста для сеанса протокола идентификации хоста.

2. Способ по п.1, в котором указанным вторым хостом является веб-сервер, который является одним из нескольких веб-серверов в кластере или ферме веб-серверов.

3. Способ по п.1 или 2, в котором материал секретного ключа Диффи-Хеллмана, соответствующий указанному материалу открытого ключа Диффи-Хеллмана, хранят только с помощью второго хоста и не обеспечивают обратному прокси-серверу.

4. Способ по п.1 или 2, в котором материал ключа сеанса обеспечивают с помощью второго хоста обратному прокси-серверу для предоставления возможности обратному прокси-серверу выполнять шифрование/дешифрование и/или аутентификацию пакетов данных.

5. Способ по п.4, в котором указанный материал ключа сеанса обеспечивают к обратному прокси-серверу в сообщении R2 основной процедуры обмена протокола идентификации хоста.

6. Способ по п.4 или 5, в котором повторный обмен ключами выполняют между первым и вторым хостами, обеспечивая материал ключа сеанса обратному прокси-серверу в сообщении «UPDATE».

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

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