Маршрутизация для групп ЭВМ

Представление ISP VPN в качестве части VPN

Если определенная сеть VPN является в действительности ISP, но ее маршрутизаторы CE поддерживают MPLS, тогда VPN может рассматриваться как частичная VPN. Маршрутизаторы CE и PE должны только обмениваться маршрутами, которые являются внутренними по отношению к VPN. Маршрутизатор PE отправит маршрутизатору CE метку для каждого из этих маршрутов. Маршрутизаторы в других сайтах VPN могут тогда стать партнерами BGP. Когда маршрутизатор CE просматривает адрес назначения пакета, маршрутный поиск всегда возвращает внутренний адрес — обычно адрес BGP следующего шага. CE помечает пакеты соответствующим образом и посылает их к PE.

Безопасность

a) Помеченные пакеты не воспринимаются маршрутизаторами опорной сети, если они пришли из источников, не внушающих доверия, за исключением случаев, когда известно, что такие пакеты покинут опорную сеть до того, как будут проанализированы IP-заголовки или какие-либо метки в стеке; и

b) помеченные маршруты VPN-IPv4 не воспринимаются, если они пришли из источников не внушающих доверия; безопасность, предоставляемая этой архитектурой, виртуально идентична той, которая реализуется опорными сетями VPN Frame Relay или ATM.

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

Использование MPLS позволяет также расширить зону действия VPN на несколько SP вне какой-либо зависимости от междоменной рассылки маршрутной информации.

Для пользователя VPN возможно также обеспечить себе повышенную безопасность, применяя туннельный режим IPSEC [5].

Пользователи VPN, чувствительные к проблемам безопасности, могут требовать гарантии того, что некоторые или все пакеты, которые проходят через опорную сеть, были аутентифицированы и/или зашифрованы. Стандартный путь получения такого режима заключается в создании "безопасного туннеля" для каждой пары маршрутизаторов CE в VPN, используя туннельный режим IPSEC.

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

Способ достижения этого предложен в [6]. Каждый маршрут VPN может иметь атрибут, идентифицирующий следующий маршрутизатор CE, через который пройдет путь. Если эта информация предоставлена всем маршрутизаторам CE в VPN, тогда может использоваться стандартный туннельный режим IPSEC.

Если CE и PE являются BGP-партнерами, естественно представить эту информацию в виде атрибута BGP.

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

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

Многокомпонентные безопасные ассоциации

Вместо построения безопасного туннеля между каждой парой маршрутизаторов CE может оказаться более привлекательным сформировать одну безопасную ассоциацию с большим числом участников. В такой ассоциации все маршрутизаторы CE, которые находятся в конкретной VPN, будут иметь идентичные параметры безопасности (например, некоторый ключ, определенный алгоритм и т.д.). Тогда устройство CE не должно будет знать, какое CE должно получать данные следующим, — оно должно знать какой сети VPN предназначена эта информация. Оконечное устройство клиента CE, которое принадлежит нескольким VPN, может использовать различные параметры безопасности для каждой из них, таким образом, защищая, например, пакеты интранет от попадания в экстранет. Для такой схемы не может быть применен стандартный туннельный режим IPSEC, так как здесь нет способа заполнить поле IP-адреса места назначения внешнего заголовка. Однако когда MPLS используется для переадресации, реальной необходимости этого не существует; маршрутизатор PE может использовать MPLS, чтобы ввести пакет в конечную точку туннеля, даже не зная его IP-адреса; он только должен отслеживать IP-адреса места назначения внутреннего заголовка.

Существенным преимуществом схемы, подобной этой, является то, что изменение в маршрутизации (в частности, изменение выхода CE для конкретного адресного префикса) прозрачны для механизма безопасности. Это может быть важным, в частности, в случае мультипровайдерских VPN, где нужно пересылать информацию об изменении маршрутов с целью поддержания механизмов безопасности. BGP-4 транспортирует три типа данных, которые ориентированы на IPv4:

a. атрибут NEXT_HOP (представляет собой адрес IPv4);

b. AGGREGATOR (содержит адрес IPv4), и

c. NLRI (Network Layer Reachability Information — представляет собой префикс IPv4).

В данном документе предполагается, что любой BGP-партнер (включая тот, который поддерживает мультипротокольные возможности, рассмотренные ниже) должен иметь IPv4 адрес (который будет использоваться в атрибуте AGGREGATOR). Следовательно, чтобы BGP-4 мог поддерживать несколько протоколов сетевого уровня, необходимо добавить две вещи:

a. возможность ассоциирования конкретного протокола сетевого уровня с данными о следующем шаге, и

b. возможность для заданного протокола сетевого уровня работать с NLRI.

Чтобы идентифицировать протокол сетевого уровня, здесь применяется понятие семьи адресов (Address Family), как это определено в [RFC-1700].

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

Чтобы обеспечить обратную совместимость, а также упростить введение мультипротокольных возможностей в BGP-4, здесь используются новые атрибуты: многопротокольная NLRI достижимости ( MP_REACH_NLRI ), и многопротокольная NLRI недостижимости ( MP_UNREACH_NLRI ). Первый из них ( MP_REACH_NLRI ) нужен для хранения набора достижимых адресатов и данных о следующем шаге, который следует использовать для достижения этих мест назначения. Второй атрибут ( MP_UNREACH_NLRI ) применяется для хранения набора недостижимых адресатов. Таким способом партнер BGP, который не поддерживает мультипротокольные возможности, будет просто игнорировать информацию, содержащуюся в этих атрибутах, и не передаст эти данные другим BGP партнерам.