7.1.1. Защита данных
Защита информации - ключевая проблема, которую нужно решить для превращения Internet в публичную всемирную сеть с интеграцией услуг. Без обеспечения гарантий конфиденциальности передаваемой информации бум вокруг Internet быстро утихнет, оставив ей роль поставщика интересной информации.
Сегодня защиту информации в Internet обеспечивают различные нестандартные средства и протоколы - firewall'ы корпоративных сетей и специальные прикладные протоколы, типа S/MIME, которые обеспечивают аутентификацию сторон и шифрацию передаваемых данных для какого-либо определенного прикладного протокола, в данном случае - электронной почты.
Существуют также протоколы, которые располагаются между прикладным и транспортным уровнями стека TCP/IP. Наиболее популярным протоколом такого типа является протокол SSL (SecureSocketLayer), предложенный компанией NetscapeCommunications, и широко используемый в серверах и браузерах службы WWW. Протоколы типа SSL могут обеспечить защиту данных для любых протоколов прикладного уровня, но недостаток их заключается в том, что приложения нужно переписывать заново, если они хотят воспользоваться средствами защиты, так как в приложения должны быть явно встроены вызовы функций протокола защиты, расположенного непосредственно под прикладным уровнем.
Проект IPv6 предлагает встроить средства защиты данных в протокол IP. Размещение средств защиты на сетевом уровне сделает их прозрачными для приложений, так как между уровнем IP и приложением всегда будет работать протокол транспортного уровня. Приложения переписывать при этом не придется.
В протоколе IPv6 предлагается реализовать два средства защиты данных. Первое средство использует дополнительный заголовок "AuthenticationHeader" и позволяет выполнять аутентификацию конечных узлов и обеспечивать целостность передаваемых данных. Второе средство использует дополнительный заголовок "EncapsulatingSecurityPayload" и обеспечивает целостность и конфиденциальность данных.
Разделение функций защиты на две группы вызвано практикой, применяемой во многих странах на ограничение экспорта и/или импорта средств, обеспечивающих конфиденциальность данных путем шифрации. Каждое из имеющихся двух средств защиты данных может использоваться как самостоятельно, так и одновременно с другим.
В проектах протоколов защиты данных для IPv6 нет привязки к определенным алгоритмам аутентификации или шифрации данных. Методы аутентификации, типы ключей (симметричные или несимметричные, то есть пара "закрытый-открытый"), алгоритмы распределения ключей и алгоритмы шифрации могут использоваться любые. Параметры, которые определяют используемые алгоритмы защиты данных, описываются специальным полем SecurityParametersIndex, которое имеется как в заголовке "AuthenticationHeader", так и в заголовке "EncapsulatingSecurityPayload".
Тем не менее, для обеспечения совместимой работы оборудования и программного обеспечения на начальной стадии реализации протокола IPv6 предложено использовать для аутентификации и целостности широко распространенный алгоритм хеш-функции MD5 с секретным ключом, а для шифрации сообщений - алгоритм DES.
Ниже приведен формат заголовка AuthenticationHeader.
| Следующий заголовок | Длина аутентификационных данных | Зарезервированное поле |
| Индекс параметров безопасности (SPI) | ||
| Аутентификационные данные | ||
Протокол обеспечения конфиденциальности, основанный на заголовке "EncapsulatingSecurityPayload", может использоваться в трех различных схемах.
В первой схеме шифрацию и дешифрацию выполняют конечные узлы. Поэтому заголовок пакета IPv6 остается незашифрованным, так как он нужен маршрутизаторам для транспортировки пакетов по сети.
Во второй схеме шифрацию и дешифрацию выполняют пограничные маршрутизаторы, которые отделяют частные сети предприятия от публичной сети Internet. Эти маршрутизаторы полностью зашифровывают пакеты IPv6, получаемые от конечных узлов в исходном виде, а затем инкапсулируют (эта операция и дала название заголовку - Encapsulating) зашифрованный пакет в новый пакет, который они посылают от своего имени. Информация, находящаяся в заголовке "EncapsulatingSecurityPayload", помогает другому пограничному маршрутизатору-получателю извлечь зашифрованный пакет, расшифровать его и направить узлу-получателю.
В третьей схеме один из узлов самостоятельно выполняет операции шифрации-дешифрации, а второй узел полагается на услуги маршрутизатора-посредника.
7.1.2. Гарантированная пропускная способность
Многие аналитики считают, что сеть Internet сможет приспособиться к требованиям времени только в том случае, если она сможет предложить своим абонентам такие же гарантии по предоставляемой пропускной способности, которые сегодня являются обычными для пользователей сетей framerelay и ATM. Это значит, что сети IP должны достаточно тонко различать классы трафика и, в зависимости от класса, гарантировать либо определенную постоянную пропускную способность (например, для голосового трафика), либо среднюю интенсивность и максимальную пульсацию трафика (например, для передачи компрессированного видеоизображения), либо предоставлять полосу пропускания не ниже определенного уровня (для пульсирующего компьютерного трафика).
Для обеспечения заданного качества обслуживания в протокол IPv6 введено такое понятие как "метка потока" (flowlabel). Метка потока - это признак, размещаемый в основном заголовке IP-пакета и указывающий принадлежность данного пакета к последовательности пакетов - потоку, для которого требуется обеспечить определенные параметры обслуживания, отличные от принятых по умолчанию.
Для того, чтобы конечные узлы могли сообщить маршрутизаторам сети требования к качеству обслуживания своих потоков, необходим дополнительный протокол. Именно для этой цели разработан протокол резервирования ресурсов RSVP (ResourcereSerVationProtocol). Этот протокол имеет пока статус проекта стандарта (draft) и состоит в следующем.
Узел-источник, который собирается передавать данные, требующие определенного нестандартного качества обслуживания, например постоянной полосы пропускания для передачи видеоинформации, посылает по сети по протоколу RSVP специальное сообщение. Это сообщение, называемое сообщением о пути, содержит данные о том, какую информацию собирается пересылать по образуемому потоку узел-отправитель, и какая пропускная способность нужна для получения ее с хорошим качеством. Это сообщение передается от маршрутизатора к маршрутизатору, при этом определяется последовательность маршрутизаторов, в которых нужно зарезервировать определенную пропускную способность.
Когда узел назначения получает сообщение о пути, то он извлекает из него данные о том, какую пропускную способность он должен зарезервировать и в каких маршрутизаторах. Узлов назначения может быть и несколько, если узел-отправитель хочет начать мультивещательную сессию. На основании полученной информации каждый узел назначения отправляет по протоколу RSVP сообщение, с помощью которого он запрашивает у сети определенную пропускную способность для определенного потока. Это сообщение передается каждому маршрутизатору на пути от узла-отправителя до узла назначения.
Маршрутизатор, который получает такое сообщение, проверяет свои ресурсы для того, чтобы выяснить, может ли он выделить требуемую пропускную способность. Если нет, то маршрутизатор запрос отвергает. Если же да, то маршрутизатор настраивает алгоритм обработки пакетов таким образом, чтобы указанному потоку всегда предоставлялась требуемая пропускная способность, а затем передает запрос конечного узла следующему маршрутизатору вдоль пути.
По мере передачи запроса о резервировании пропускной способности по направлению к узлу-источнику он может слиться с аналогичным запросом от другого узла назначения (если сессия мультивещательная). Слияние запросов исключает ненужное дублирование потоков. При слиянии запросов удовлетворяются потребности в максимальной пропускной способности, найденной в нескольких запросах. При этом ни один из узлов-приемников не получит обслуживания с качеством ниже того, что он запросил.
Кроме протокола RSVP, существует также проект протокола RTP (Real-TimeProtocol), который должен использоваться на транспортном уровне вместо протоколов TCP и UDP в том случае, когда необходимо передавать по Internet трафик реального времени. Протокол RTP будет переносить в своем заголовке временные отметки, необходимые для успешного восстановления голоса или видеоизображения в приемном узле, а также данные о типе кодирования информации (JPEG, MPEG и т.п.).
В конце прошлого года число фирм, предоставляющих услуги доступа к информационным ресурсам Internet в нашей стране едва превышало десяток. При этом спектр услуг был достаточно однотипным (электронная почта, терминал и, как исключение, IP). Объявление компанией SovamTeleport своего проекта Россия-OnLine вызвало широкий резонанс, т.к. по сути впервые было заявлено о появлении настоящей информационной службы: построенной на основе технологии IP.
Прошло всего полгода и ситуация в корне изменилась. По всей стране созданы информационные центры, которые в настоящее время предлагают практически полный спектр услуг по информационному обслуживанию пользователей и подключению в различных режимах к сети Internet.
Прежде чем приступить к обзору этих фирм, рассмотрим предлагаемые технологии подключения и обслуживания. Это необходимо для отчетливого представления о том, что реально стоит за каждой строкой прайс-листа и на что пользователи могут рассчитывать.
Виды сервиса и схемы подключения
Для начала попробуем отклассифицировать схемы подключения и типы сервиса с точки зрения различных типов пользователей, протоколов взаимодействия (программного обеспечения) и технических средств подключения. Представить такую классификацию можно в виде таблицы: