RFC 3879 Deprecating Site Local Addresses

Network Working Group                                         C. Huitema
Request for Comments: 3879                                     Microsoft
Category: Standards Track                                   B. Carpenter
                                                                     IBM
                                                          September 2004

Отмена адресов Site Local

Deprecating Site Local Addresses

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

Этот документ рассматривает вопросы использования индивидуальных адресов IPv6 site-local в их исходной форме и формально отменяет их применение. Данная отмена не запрещает продолжение их использования до момента стандартизации и реализации замены.

1. Введение

В течение некоторого времени рабочая группа IPv6 занималась обсуждением множества вопросов, связанных с использованием локальных для сайта (site local) адресов. На заседании в марте 2003 года группа достигла определенного соглашения по этим вопросам в части замены таких адресов в их предложенной изначально форме. Хотя единодушия по этому вопросу не было достигнуто, на заседании в июле 2003 года рабочая группа подтвердила необходимость документирования этих проблем и последующего принятия решения об отказе от использования индивидуальных адресов IPv6 site-local.

Локальные для сайта адреса были определены в архитектуре адресации IPv6 [RFC3513] (параграф 2.5.6).

В оставшейся части этого документа описаны негативные аспекты применения локальных для сайта адресов и приведен формальный отказ от их использования.

Цели такой отмены и решения по замене адресов будут описаны в дополнительных документах. Однако формальный отказ не отменяет применение ранее развернутых адресов site-local до момента стандартизации и реализации замены.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14, RFC 2119 [RFC2119].

2. Негативные эффекты адресов Site Local

Обсуждения в рабочей группе IPv6 привели к обнаружению некоторых недостатков текущей модели локальной для сайта адресации. Эти недостатки можно разделить не две категории — неоднозначность адресации и нечеткость определения сайта.

Как было отмечено, адресация site local не обеспечивает однозначности — адреса типа FEC0::1 могут присутствовать на множестве сайтов, а сам адрес не содержит какой-либо индикации сайта, к которому он относится. Это создает проблемы для разработчиков приложений и маршрутизаторов, а также сетевых администраторов. Проблема связана с нечеткостью определения сайта. Более подробное рассмотрение этого вопроса будет приведено ниже.

2.1. Проблема разработчиков — область действия идентификаторов

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

Приложение может узнать или вспомнить, что некий корреспондент использует адрес FEC0::1234:5678:9ABC, а потом попытаться поместить такой адрес в структуру адреса сокета и организовать соединение. Такая попытка завершится отказом, поскольку не будет задана переменная site identifier, как в FEC0::1234:5678:9ABC%1 (использование символа % в качестве разделителя для идентификатора зоны задано в [SCOPING]). Проблема усугубляется тем, что идентификатор сайта меняется в зависимости от конкретизации хоста (например, может быть %1 или %2), что не позволяет сохранить идентификатор хоста в памяти или узнать у сервера имен.

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

2.2. Проблема разработчиков — локальная адресация

Простые приложения клиент-сервер с разделяемым адресом IP на прикладном уровне усложняются при использовании адресации IPv6 site-local. Эти приложения должны будут принимать интеллектуальные решения в части прохождения адресов через границу сайта. На практике для решения таких вопросов приложениям потребуется информация о топологии сети. Локальные для сайта адреса могут быть применены для случаев, когда клиент и сервер размещаются на одном сайте, но попытки использовать их для разнесенных между сайтами клиентов и серверов будут заканчиваться неожиданными ошибками (например, сбросом соединения партнером) или организаций соединений не с тем узлом. Отказоустойчивость и безопасность при отправке пакетов неизвестному хосту может существенно меняться от приложения к приложению.

Приложения с множеством участников (Multi-party), которые передают адреса IP на прикладном уровне, сталкиваются с особой проблемой. Даже если узел может корректно определить место нахождения удаленного узла (на этом же или другом сайте), он не сможет узнать по какому адресу нужно отправлять пакеты для него. Наилучшим выходом для таких приложений может оказаться переход на использование только глобальных адресов. Однако это будет препятствовать использованию таких приложений в изолированных и периодически подключаемых сетях, для которых доступны только адреса site-local, и может приводить к несовместимости с использованием в некоторых случаях адресов site-local для контроля доступа.

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

2.3. Проблема администраторов — утечки

Поддержка локальных для сайта адресов IPv6 во многих случаях проще работы с приватными блоками адресов RFC 1918 [RFC1918] в некоторых сетях IPv4. Теоретически, адреса, определенные в RFC 1918 должны использоваться только локально и не появляться в сети Internet. На практике такие адреса «утекают» в публичные сети. Комбинация утечек и неоднозначностей будет вызывать проблемы управления сетями.

Имена и адреса хостов приватных сетей могут «утекать» в почтовых сообщениях, web-страницах или файлах. Использование приватных адресов в полях отправителя или получателя запросов TCP или сообщений UDP (например, DNS или traceroute) будут приводить к отказам или доставке откликов на совершенно другие хосты.

Опыт использования адресов RFC 1918 показал также некоторые нетривиальные утечки в дополнение к приватным адресам в заголовках. Приватные адреса могут указываться также реверсных запросах DNS, которые будут создавать бесполезную загрузку инфраструктуры DNS. В общем случае многие приложения, использующие адреса IP напрямую, будут в конечном итоге приводить к путаницам и отказам.

Утечки вряд ли можно предотвратить. В то время, как некоторые приложения по своей природе имеют ограниченную область действия (например, Router Advertisement, Neighbor Discovery), большинство приложений не имеет таких концептуальных ограничений. В результате происходят утечки через границы (stuff leaks across the borders). Неоднозначность локальной для сайта адресации будет препятствовать поиску причин утечек. В результате утечки становятся трудно уловимыми, что вызывает разочарование администраторов.

2.4. Проблема маршрутизаторов — рост сложности

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

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

Неоднозначность адресации имеет очевидные проявления на многосайтовых маршрутизаторах. В классической архитектуре маршрутизации выходной интерфейс непосредственно определяется адресом получателя в соответствии с единой таблицей маршрутизации. Однако для маршрутизатора, соединенного с несколькими сайтами, маршрутизация пакетов с локальными для сайта адресами зависит также от интерфейса, через который пакет был принят. Интерфейсы связываются с сайтами и маршрутные записи для адресов site-local становятся зависимыми от сайта. Поддержка такой возможности требует реализации специальных функций в протоколах маршрутизации с методов виртуализации таблиц маршрутизации и пересылки, которые обычно применяются для VPN. Это создает дополнительные сложности при реализации и обслуживании маршрутизаторов.

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

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

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

2.5. Определение сайта

Существующее определение областей действия (scope) следует идеализированной концентрической модели. Предполагается, что хосты подключены к каналу, относящемуся к сайту, который, в свою очередь, относится к сети Internet. Пакеты могут передаваться в свой (тот же) канал, на свой сайт или за пределы сайта. Однако споры вокруг определения сайта длятся уже много лет и согласия не достигнуто. Это говорит о том, что такое согласие маловероятно.

За пределами локального канала (link-local) границы области действия определены достаточно плохо. Что такое сайт? Является ли сайтом корпоративная сеть в целом или сайты должны быть территориально локализованы? Многие современные сети разделены на внутреннюю часть и внешнюю ДМЗ1, отделенную межсетевым экраном. Серверы в ДМЗ доступны как из внутренней сети, так и для хостов Internet. Относятся ли хосты ДМЗ и внутренней сети к одному сайту?

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

Имеются хорошо известные и важные случаи, когда основанный на областях действия подход не будет работать, — сети, не соединенные напрямую, мобильные узлы, мобильные сети, междоменные VPN, сети с использованием хостинга, случаи слияния или разделения сетей и т. п. В частности, это означает, что «область действия» (scope) невозможно отобразить концентрическими кругами, как в примитивной модели канал/локальный/глобальный (link/local/global). Области могут перекрываться или проникать одна в другую. Принадлежность пары хостов к одной области может даже отличаться для разных протоколов.

Отметим в заключение, что современная концепция сайта наивна и не отражает эксплуатационных требований.

3. Разработка более эффективного решения

В предыдущем разделе приведены аргументы против локальных для сайта (site-local) адресов. Тем не менее, очевидны и некоторые преимущества такой адресации, без которых такие адреса были бы уже давно удалены из спецификации. Преимуществом таких адресов является простота, стабильность и частных характер распределения. Однако такие преимущества могут быть достигнуты и при использовании иной архитектуры. Примером может служить [Hinden/Haberman], где адреса не содержат неоднозначностей и не имеют явной области действия.

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

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

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

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

Остается вопрос anycast-адресации. Такие адреса являются неоднозначными по своему устройству, поскольку они относятся, по определению, ко всем хостам, которым был присвоен данный адрес anycast. Локальные для канала или глобальные адреса могут оказаться «впечатанными» в программный код. Нужны дополнительные исследования необходимости использования адресов anycast с областью действия между локальной для канала и глобальной.

4. Отказ от применения

Этот документ формально отменяет использование префикса локальных для сайта (site-local) индивидуальных адресов IPv6, определенного в [RFC3513], как 1111111011 или FEC0::/10. Специальная обработка для этого префикса должна быть исключена из новых реализаций. Префикс недопустимо выделять для иного применения до того, как он будет заново стандартизован IETF. Новые версии архитектуры адресации [RFC3513] будут включать эту информацию.

Реализации маршрутизаторов следует настраивать для отказа от маршрутизации этого префикса по умолчанию.

Упоминания локальных для сайта адресов следует удалить из новых вресий документов Default Address Selection for Internet Protocol version 6 [RFC3484], Basic Socket Interface Extensions for IPv6 [RFC3493] и Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC3513]. Имеющиеся упоминания локальных адресов следует удалить из новых версий других документов IETF при их обновлении. Такие документы включают [RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, RFC3177, RFC3316].

Существующие реализации и развернутые системы могут продолжать использование этого префикса.

5. Вопросы безопасности

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

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

6. Согласование с IANA

Агентству IANA направлен запрос на маркировку префикса FEC0::/10, как отмененного (deprecated) со ссылкой на данный документ. Последующее использование этого префикса для тех или иных целей потребует прохождения процедуры стандартизации (IETF Standards Action) [RFC2434].

7. Благодарности

Авторы благодарны Fred Templin, Peter Bieringer, Chirayu Patel, Pekka Savola и Alain Baudot за обзор начальной версии документа. Текст параграфа 2.2 включает два абзаца из версии Margaret Wasserman, описывающие влияние локальной для сайта адресации. Alain Durand указал на необходимость пересмотра существующего RFC со ссылками на локальные для сайта адреса.

8. Литература

8.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC3513] Hinden, R. and S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 35132, April 2003.

8.2. Информационные ссылки

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2772] ockell, R. and R. Fink, «6Bone Backbone Routing Guidelines», RFC 2772, February 2000.

[RFC2894] Crawford, M., «Router Renumbering for IPv6», RFC 2894, August 2000.

[RFC3082] Kempf, J. and J. Goldschmidt, «Notification and Subscription for SLP», RFC 3082, March 2001.

[RFC3111] Guttman, E., «Service Location Protocol Modifications for IPv6», RFC 3111, May 2001.

[RFC3142] Hagino, J. and K. Yamamoto, «An Ipv6-to-IPv4 Transport Relay Translator», RFC 3142, June 2001.

[RFC3177] IAB and IESG, «IAB/IESG Recommendations on Ipv6 Address», RFC 3177, September 2001.

[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, «Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts», RFC 3316, April 2003.

[RFC3484] Draves, R., «Default Address Selection for Internet Protocol version 6 (IPv6)», RFC 3484, February 2003.

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, «Basic Socket Interface Extensions for IPv6», RFC 3493, February 2003.

[Hinden/Haberman] Hinden, R. and B. Haberman, «Unique Local Ipv6 Unicast Addresses», Work in Progress, June 2004.

[SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, «IPv6 Scoped Address Architecture», Work in Progress, August 2004.

9. Адреса авторов

Christian Huitema

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052-6399

USA

EMail: huitema@microsoft.com

Brian Carpenter

IBM Corporation

Sauemerstrasse 4

8803 Rueschlikon

Switzerland

EMail: brc@zurich.ibm.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

10. Полное заявление авторских прав

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1«Демилитаризованная» зона.

2Документ признан устаревшим и заменен RFC 4291. Прим. перев.




RFC 3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)

Network Working Group                                   X. Xiao, Ed.
Request for Comments: 3916                       Riverstone Networks
Category: Informational                            D. McPherson, Ed.
                                                      Arbor Networks
                                                        P. Pate, Ed.
                                                   Overture Networks
                                                      September 2004

Требования к сквозной эмуляции псевдопровода (PWE3)

Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)

PDF

Статус документа

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

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

В это документе описываются базовые требования для PWE31, разработанные группой PWE3 WG. Документ включает рекомендации для других рабочих групп, занимающихся определением механизмов эмуляции псевдопроводов для сетей Ethernet, ATM и Frame Relay. Требования к эмуляции псевдопроводов для (синхронных битовых потоков, определенный в спецификации ITU G.702) рассматриваются в отдельном документе2. Следует отметить, что рабочая группа PWE3 занимается стандартизацией механизмов, которые могут использоваться для обеспечения сервиса PWE3, но не сервисом, как таковым.

Оглавление

Исключено из версии HTML

1. Введение

1.1. Что такое псевдопровод?

Эмуляция сквозного псевдопровода (PWE3) представляет собой механизм эмуляции существенных атрибутов различных типов сетевого сервиса (ATM, Frame Relay или Ethernet) через сети с коммутацией пакетов (PSN3). Обязательные функции псевдопровода PW включают инкапсуляцию обусловленных типом сервиса PDU4, получаемых входным портом и передачу их через путь или туннель с обеспечением синхронизации, порядка доставки и иных операций, требуемых для эмуляции поведения и характеристик сервиса с максимально возможной полнотой.

С точки зрения пользователя PW представляется как выделенное соединение или устройство выбранного типа сервиса. Однако эмуляции присущ ряд существенных ограничений, осложняющих использование PW для некоторых приложений. Такие ограничения должны быть подробно описаны в документации сервиса и заявлениях о применимости (Applicability Statement).

1.2. Современная архитектура сетей

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

1.2.1. Множество разнотипных сетей

У любого, предоставляющего различные типы услуг сервис-провайдера, сетевая инфраструктура обычно включает “параллельные” или перекрывающиеся сети. Каждая из таких сетей поддерживает свой тип сервиса (например, Frame Relay, доступ в Internet и т. п.). Такое решение ведет к увеличению расходов как на приобретение оборудования, так и на его обслуживание. Кроме того, наличие множества разнотипных сетей усложняет планирование и управление. У сервис-провайдеров возникают естественные вопросы:

  • Какую из сетей следует развивать?
  • Какое количество оптических волокон требуется для каждой сети?
  • Как эффективно управлять многочисленными сетями?

Конвергенция поможет сервис-провайдерам ответить на все эти вопросы и обеспечить согласованное и экономичное развитие сети.

1.2.2. Переход к оптимизированным для передачи пакетов сетям

Для повышения эффективности инвестиций и снижения эксплуатационных расходов сервис-провайдеры зачастую стараются использовать одну сетевую технологию для доставки различных типов сервиса.

Поскольку пакетный трафик занимает все большую часть доступной полосы сетей, растет целесообразность перевода сетей общего пользования на протоколы IP. Однако многие сервис-провайдеры сталкиваются с проблемами при развертывании оптимизированных для передачи пакетов сетей. Хотя трафик Internet и является наиболее быстро расширяющимся по объему, на сегодняшний день он не является преобладающим. Например, трафик Frame Relay по-прежнему имеет суммарный объем, превышающий объем естественного трафика IP. А частные каналы TDM обеспечивают трафик, который по своему уровню превосходит трафик Frame Relay. Кроме того, в сетях общего пользования имеется огромное количество старого оборудования, которое не способно работать по протоколу IP. Сервис-провайдеры продолжают использовать не поддерживающее IP оборудование для различных типов сервиса и возникает необходимость сопряжения такого оборудования с оптимизированными для передачи трафика IP сетями.

1.3. PWE3 как путь сближения

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

Одним из вариантов является эмуляция устройств или служб с использованием псевдопроводов (PW). Эмуляция устройств в сетях ATM и взаимодействие между сетями Frame Relay и ATM уже стандартизованы. Эмуляция позволяет передавать трафик существующих типов сервиса через новую инфраструктуру и, таким образом, обеспечивает возможность взаимодействия разнородных сетей.

При корректной реализации PWE3 может обеспечить возможность поддержки традиционного сервиса в новых сетях.

1.4. Приложения, подходящие для PWE3

Что делает приложение подходящим (или неподходящим) для использования с PWE3? При рассмотрении PW как основы для реализации приложений следует получить ответы на приведенные ниже вопросы:

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

Если на все 4 вопроса дан положительных ответ, это приложение подходит для PWE3. В остальных случаях требуется более внимательный учет требований пользователей, сервис-провайдеров, производителей оборудования и сетевых технологий.

1.5. Резюме

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

Для создания сетей следующего поколения должны быть разработаны стандартные методы эмуляции существующих телекоммуникационных форматов (Ethernet, Frame Relay, ATM) в сетях IP. Данный документ описывает требования к решению этой задачи.

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119.

Ниже приведены определения некоторых терминов, используемых в документе.

Attachment Circuit (AC) – устройство подключения, соединительное устройство

Физическое или виртуальное устройство, обеспечивающее подключение CE к PE. В качестве AC может выступать Frame Relay DLCI, ATM VPI/VCI, порт Ethernet, VLAN, канал HDLC, соединение PPP на физическом интерфейсе, сессия PPP через туннель L2TP, MPLS LSP и т. п.

Customer Edge (CE) – пользовательский край

Устройство, на котором сервис начинается или завершается. Для CE не имеет значения используется эмулируемый естественный сервис.

Packet Switched Network (PSN) – сеть с коммутацией пакетов

В контексте PWE3 это сеть, использующая IP или MPLS в качестве механизма пересылки пакетов.

Provider Edge (PE) – провайдерский край

Устройство, обеспечивающее PWE3 для CE.

Pseudo Wire (PW) – псевдопровод

Механизм, обеспечивающий передачу значимых элементов эмулируемого устройства от одного PE к другому через сеть PSN.

Pseudo Wire Emulation Edge to Edge (PWE3) – сквозная эмуляция псевдопровода

Механизм, эмулирующий значимые атрибуты сервиса (например, выделенные каналы T1 или Frame Relay) через сеть PSN.

Pseudo Wire PDU – модуль данных псевдопровода

Протокольный модуль данных (PDU5), передаваемый в PW и содержащий все данные и управляющую информацию, требуемые для эмуляции сервиса.

PSN Tunnel – туннель PSN

Туннель через сеть PSN, внутри которого поддерживается один или несколько PW.

                    |<------- Pseudo Wire ------>|
                    |                            |
                    |    |<-- PSN Tunnel -->|    |
                    V    V                  V    V
                    +----+                  +----+
   +-----+          | PE1|==================| PE2|          +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |          |    |                  |    |          | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^       |    |==================|    |          +-----+
         ^  |       +----+                  +----+          ^
         |  |   Provider Edge 1         Provider Edge 2     |
         |  |                                               |
         | Attachment Circuit                               |
         |                                                  |
         |<-------------- Emulated Service ---------------->|

   Customer                                                 Customer
    Edge 1                                                   Edge 2

Рисунок 1: Эталонная модель PWE3

3. Эталонная модель PWE3

Псевдопровод (PW) представляет собой соединение между устройствами провайдерского края (PE), к которым подключены два AC. В качестве AC могут использоваться Frame Relay DLCI, ATM VPI/VCI, порт Ethernet, VLAN, канал HDLC, соединение PPP на физическом интерфейсе, сессия PPP через туннель L2TP, MPLS LSP и т. п.

В процессе организации PW два устройства PE будут настроены вручную или автоматически согласуют параметры эмулируемого сервиса, что позволит впоследствии корректно обрабатывать пакеты, поступающие с другого конца псевдопровода. После организации PW между парой PE кадры, полученные одним из PE от AC, инкапсулируются и передаются через PW удаленному PE, где восстанавливаются естественные для данного сервиса кадры и передаются в устройство CE. Детальное описание архитектуры PWE3 приведено в документе [PWE3_ARCH].

В этом документе не используется допущений о природе PW (например, сессия [L2TPv3], [MPLS] LSP) или PSN (например, IP или MPLS). Вместо этого описываются базовые требования, которые применимы ко всем типам PW и PSN для всех эмулируемых служб, включая Ethernet, ATM, Frame Relay и т. д.

4. Обработка пакетов

В этой главе описаны требования PWE3 в части данных.

4.1. Инкапсуляция

Каждое устройство PE должно обеспечивать механизм инкапсуляции PDU от AC. Следует отметить, что инкапсулируемые PDU могут включать или не включать заголовки канального уровня (L2) – это зависит от типа сервиса. Каждый сервис PWE3 должен указывать что собой представляет PDU.

Заголовок PW PDU содержит все поля, которые используются на выходе PW для определения механизмов обработки PDU. Заголовок туннеля PSN не рассматривается как часть заголовка PW.

Конкретные требования к инкапсуляции PDU рассматриваются ниже.

4.1.1. Передача требуемой информации из заголовков канального уровня

На выходной стороне PW требуется некая информация (например, тип естественного сервиса, к которому относятся PW PDU, а в некоторых случаях информация из заголовка L2) для определения способа обработки принятых PDU. Механизм инкапсуляции PWE3 должен обеспечивать тот или иной способ передачи такой информации со входной стороны PW на выходную. Следует отметить, что вся информация этого типа должна содержаться в PW-заголовке PW PDU. Часть информации (например, тип сервиса для PW) может сохраняться на выходной стороне как состояние в процессе организации PW.

4.1.2. Поддержка переменного размера PDU

Реализации PWE3 должны поддерживать PDU переменной длины, если такие PDU поддерживаются исходным сервисом. Например, от PWE3 для Frame Relay требуется поддержка переменного размера кадров.

4.1.3. Поддержка мультиплексирования и демультиплексирования

Если исходный сервис может группировать множество устройств (соединений) в “транк” (например, объединение ATM VCC в VPC или поддержка на одном порту множества интерфейсов Ethernet 802.1Q), следует обеспечивать какие-либо механизмы, позволяющие использовать один PW для соединения двух транковых устройств. С точки зрения инкапсуляции должна передаваться информация, достаточная для того, чтобы PW на приемной стороне мог демультиплексировать отдельные устройста (соединения).

4.1.4. Проверка корректности PW-PDU

Большинство кадров L2 имеют поле контрольной суммы для проверки целостности кадра. Каждый сервис PWE3 должен указывать требуется ли сохранение контрольных сумм кадров при передаче через PW или контрольные суммы могут исключаться на входном PE и заново рассчитываться на выходном PE. Для протоколов типа ATM и FR контрольные суммы включают данные канального уровня (идентификаторы устройств — FR DLCI или ATM VPI/VCI). Следовательно, такие контрольные суммы должны исключаться на входном PE и заново рассчитываться на выходе.

4.1.5. Доставка информации о типе данных

В некоторых случаях желательно отличать трафик PW от других типов трафика (например, IPv4, IPv6 или OAM). В частности, при использовании ECMP6 в сети PSN такое различие может использоваться для снижения вероятности нарушения порядка доставки пакетов PW при использовании механизмов распределения нагрузки. При необходимости следует обеспечивать какой-либо механизм поддержки таких различий. Такие механизмы могут определены рабочей группой PWE3 или другими группами.

4.2. Порядок доставки кадров

Когда пакеты, содержащие PW PDU проходят через PW, порядок их доставки может нарушаться. Для некоторых типов сервиса требуется сохранение порядка доставки кадров (это может относиться только к кадрам управления или ко всем кадрам). В таких случаях должен обеспечиваться тот или иной механизм обеспечения упорядоченной доставки. Одним из вариантов решения этой задачи может служить включение порядковых номеров в заголовки PW, что позволит детектировать нарушение порядка на приемной стороне. Механизм восстановления нарушенного порядка может обеспечиваться NSP-обработкой7 [PWE3_ARCH], но этот вопрос выходит за рамки PWE3.

4.3. Дублирование кадров

В редких случаях пакеты при прохождении через PW могут дублироваться. Для некоторых типов сервиса дублирование кадров недопустимо. В таких случаях должен обеспечиваться механизм предотвращения доставки дубликатов. Этот механизм может быть самостоятельным или служить частью механизма обеспечения корректного порядка доставки.

4.4. Фрагментация

Если суммарный размер данных L2 и связанных с ними заголовков PWE3 и PSN превосходит значение MTU на пути через PSN, может возникнуть необходимость фрагментации данных L2 (в противном случае кадр L2 может быть отброшен на пути). Для некоторых типов сервиса фрагментация может потребоваться также для сохранения относительной позиции управляющего кадра среди кадров данных (например, относительное положение ячеек ATM PM). В общем случае фрагментация оказывает влияние на производительность и, следовательно, фрагментации следует избегать по возможности. Однако для отдельных типов сервиса требования фрагментации могут быть иными. Для случаев, когда фрагментация необходима, документ PWE3 для соответствующего типа сервиса должен указывать следует ли отбрасывать кадр или фрагментировать его. Если эмулируемый сервис выбирает для кадра отбрасывание, это должно быть указано в заявлении о применимости.

4.5. Объединение PDU для снижения объема служебного трафика

Когда размер L2 PDU мал, для снижения загрузки туннеля PSN можно объединять множество PDU перед тем, как в пакет будет добавлен заголовок туннеля PSN. Каждый инкапсулированный PDU по-прежнему содержит свой заголовок PW, поэтому PE на выходе знает как обрабатывать данные. Однако при объединении PDU следует принимать во внимание рост задержек и их флуктуаций (jitter), а также влияние потери пакетов.

5. Обслуживание эмулируемого сервиса

В этой главе рассматриваются требования по обслуживанию PWE3.

5.1. Организация и разрыв псевдопроводных соединений

Псевдопроводное соединение PW должно быть организовано до того, как будет использоваться эмулируемое устройство, и должно разрываться после того, как необходимость использования эмулируемого устройства отпадет. Организация и разрыв PW могут инициироваться командами из системы управления PE, командами Setup/Teardown со стороны AC (например, ATM SVC) или с помощью механизмов автоматического детектирования.

В каждой реализации PWE3 должен быть определен тот или иной механизм организации PW. В процессе установки соединения PE требуется обмен той или иной информацией (например, определение возможностей удаленной стороны). Механизм организации соединения должен обеспечивать устройствам PE способ обмена всей необходимой информацией. Например, обе конечные точки должны согласовать методы инкапсуляции PDU и поддержки упорядоченной доставки кадров. Выбор сигнального протокола и передаваемой информации зависит от типа сервиса. Каждая реализация PWE3 должна указывать это. Ручная настройка PW может рассматриваться как специальный случай организации соединений.

Если в естественных условиях устройство является двунаправленным, соответствующее эмулируемое устройство может сигнализировать о своей готовности к работе (состояние «Up») только в том случае, когда связанные с ним PW и туннель PSN работают в обоих направлениях.

5.2. Обработка управляющих сообщений исходного сервиса

Некоторые типы сервиса в естественной форме поддерживают те или иные механизмы, используемые для обслуживания (например, ATM OAM или FR LMI). Служебные сообщения этих механизмов могут передаваться в основной полосе (т. е, помещаться вместе с данными в одном AC) или по отдельному каналу (например, с использованием выделенного для управления устройства). Для таких служб все передаваемые в основной полосе управляющие сообщения следует также передавать в основной полосе так же, как данные, с использованием соответствующего PW на удаленное устройство CE. Иными словами, для передаваемых в основной полосе управляющих сообщений не требуется трансляции в устройствах PE. Кроме того, может оказаться желательным обеспечения максимальной надежности доставки управляющих сообщений. Механизмы обеспечения высокой надежности доставки не определяются рабочей группой PWE3.

Управляющие сообщения, передаваемые по отдельному каналу между CE и PE могут относиться к различным AC между данной парой CE PE. Эти сообщения должны обрабатываться на локальном PE, а в некоторых случаях и на удаленном PE. Если в естественной форме сервиса используются те или иные управляющие сообщения, передаваемые по отдельному каналу, соответствующий эмулируемый сервис должен указать способы обработки таких сообщений в устройствах PE. В общем случае такие сообщения транслируются в in-band-сообщения естественного сервиса или определяемые PWE управляющие сообщения для каждого AC, связанного с данным сообщением, типа out-of-band. Для примера предположим, что некоторые AC между CE и PE используют ATM VCC в VPC. При получении F4 AIS [UNI3.0] от CE устройству PE следует транслировать F4 AIS с F5 AIS и передать сообщение удаленному CE для каждого VCC. В качестве альтернативного варианта PE следует генерировать определяемое PWE управляющее сообщение (например, аннулирование метки) удаленному PE для каждого VCC. Когда удаленное устройство PE получает такое сообщение может потребоваться генерация управляющего сообщения для естественного сервиса и передача этого сообщения подключенному CE.

5.3. Инициированные PE управляющие сообщения

От PE при некоторых обстоятельствах может потребоваться генерация служебных сообщений, которые не были вызваны тем или иным естественным управляющим сообщением от CE. Такие обстоятельства обычно связаны с отказами – например, отказ PW в PSN или повреждение канала между CE и PE.

Причина, по которой от PE требуется генерация сообщений при возникновении отказов, обусловлена тем, что наличие PW между парой CE будет существенно снижать возможности CE в части обслуживания. Пример подобной ситуации показан на рисунке. Если два CE соединены напрямую проводами, естественный сервис (например, ATM) может использовать уведомления от нижележащего уровня (например, уровня физического канала) для обслуживания. Например, ATM PVC может передавать сигнал Down при повреждении физического канала. Рассмотрим теперь несколько иную ситуацию.

   +-----+ Phy-link +----+              +----+ Phy-link +-----+
   | CE1 |----------| PE1|......PW......|PE2 |----------| CE2 |
   +-----+          +----+              +----+          +-----+

Если происходит отказ в PW между PE1 и PE2, устройства CE1 и CE2 не будут получать уведомлений о повреждении физического канала. В результате этого они не смогут своевременно объявить об отказе в эмулируемом устройстве приложениям вышележащих уровней. Следовательно, при отказе PW устройствам PE1 и PE2 необходимо инициировать передачу служебных сообщений, уведомляющих клиентский уровень CE1 и CE2, использующих данный PW как серверный уровень (в этом случае клиентским уровнем является эмулируемый сервис). Если происходит повреждение физического канала между PE1 и CE1, устройство PE1 должно инициировать передачу некого служебного сообщения (или сообщений), которые будут уведомлять клиентский уровень CE2. Устройство PE2 также может быть вовлечено в процесс генерации служебных сообщений.

В редких случаях, когда в физическом соединении между CE возникает множество битовых ошибок, для физического соединения может декларироваться состояние Down с уведомлением клиентского уровня устройств CE. В псевдо-соединениях PW может происходить потеря пакетов, их повреждение или нарушение порядка доставки. Такие события могут рассматриваться как «обобщенные битовые ошибки8» с декларированием для PW состояния Down и детектированием для PE необходимости генерации служебного сообщения, уведомляющего клиентский уровень CE.

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

  • условий, при которых требуется генерация служебных сообщений по инициативе PE;
  • формата служебных сообщений;
  • способов обработки служебных сообщений на удаленном PE.

Для детектирования состояний, в которых требуется генерация служебных сообщений (например, отказ PW), нужны механизмы мониторинга. Такие механизмы могут быть определены рабочей группой PWE3 или иными организациями.

Статус группы эмулируемых устройств может быть изменен в результате одного сетевого инцидента. Например, при отказе физического канала между CE и PE все эмулируемые устройства, работающие через этот канал тоже откажут. Желательно, чтобы одно сообщение использовалось для уведомления всей группы эмулируемых устройств, соединенных с одним удаленным PE. Метод PWE3 может обеспечивать тот или иной механизм уведомления об изменении состояния группы эмулируемых устройств. Одним из возможных вариантов является связывание каждого эмулируемого устройства с идентификатором группы (group ID) при организации PW для этого эмулируемого устройства. В служебном сообщении этот идентификатор группы может служить для указания на все эмулируемые устройства данной группы.

Если PE нужно генерировать и передавать служебное сообщение CE, устройство PE должно использовать служебное сообщение естественного сервиса. Это важно для сохранения прозрачности эмулируемых устройств с точки зрения CE.

Приведенные в этой главе требования согласованы с философией управления ITU-T для телекоммуникационных сетей [G805] (т. е., с концепцией уровень клиента/уровень сервера).

6. Управление эмулируемыми службами

Каждому методу PWE3 следует обеспечивать сетевым операторам те или иные механизмы для управления эмулируемым сервисом. Эти механизмы могут быть описаны ниже.

6.1. Базы MIB

Должны обеспечиваться базы SNMP MIB [SMIV2] для управления каждым эмулируемым устройством, а также псевдопроводом в целом. Эти базы MIB следует создавать с учетом приведенных ниже требований.

6.2. Общие требования к MIB

Новые базы MIB должны добавлять или расширять, когда это применимо, существующие таблицы, как определено в других, связанных с сервисом MIB для существующих типов сервиса таких, как MPLS или L2TP. Например, ifTable, как определено в Interface MIB [IFMIB] должна быть дополнена для поддержки учета пакетов, доставленных с нарушением порядка. Другим примером может служить расширение MPLS-TE-MIB [TEMIB] для эмуляции устройств через MPLS. Например, вместо того, чтобы переопределять tunnelTable для обеспечения устройствам PWE возможности использовать туннели MPLS, записи этой таблицы должны быть расширены для добавления связанных с PWE объектов. Еще одним примером может служить расширение IP Tunnel MIB [IPTUNMIB] таким способом, чтобы обеспечить связанную с PWE3 семантику при использовании отличного от MPLS транспорта для PSN. Такой подход упрощает естественное расширение объектов, определенных в существующих MIB с точки зрения управления, а также взаимодействие с существующими реализациями агентов управления.

Устройства подключения (AC) должны появляться как интерфейсы в таблице ifTable.

6.3. Настройка и обслуживание

Таблицы MIB должны быть разработаны с целью облегчения настройки конфигурации и обслуживания AC.

Базы MIB должны облегчать настройку и мониторинг AC внутри PSN.

6.4. Мониторинг производительности

Базы MIB должны собирать статистику производительности и данных об отказах.

Базы MIB должны содержать описание использования существующих счетчиков для эмуляции PW. Имеющиеся счетчики не следует заменять.

6.5. Контроль отказов и уведомления о них

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

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

6.6. Проверка и трассировка псевдопроводных соединений

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

7. Недостатки эмулируемых служб

Эмулируемым службам следует быть похожими на естественные типы сервиса, насколько это возможно, но полная идентичность не требуется. Декларация применимости сервиса PWE3 должна сообщать об ограничениях, присущих эмулируемым устройствам.

Некоторые базовые требования к сходству для эмулируемых устройств описаны ниже.

7.1. Характеристики эмулируемого сервиса

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

  1. Должна обеспечиваться возможность задать тип (например, Ethernet),наследуемый от естественного сервиса, скорость(например, 100 Мбит/с) и размер MTU для эмулируемого устройства, если это возможно для естественного устройства.
  2. Если две конечных точки (CE1 и CE2) эмулируемого устройства #1 соединены с PE1 и PE2, соответственно, а точки CE3 и CE4 эмулируемого устройства #2 также соединены с PE1 и PE2, тогда PW этих двух эмулируемых устройств могут использовать один и тот же физический путь между PE1 и PE2. Но с точки зрения каждого из CE эмулируемое устройство должно представляться выделенным (unshared). Например, пара CE1/CE2 не должна знать о существовании эмулируемого устройства #2 или CE3/CE4.
  3. При отказе в эмулируемом устройстве (на одной из ACs или в средней части PW) оба CE должны быть уведомлены своевременно, если такие уведомления поддерживаются для естественного сервиса (см. параграф 5.3). Трактовка понятия “своевременность” зависит от типа сервиса.
  4. Если естественное устройство позволяет организовать отношения смежности для протокола маршрутизации (например, IGP), должна обеспечиваться возможность организации таких же отношений через эмулируемое устройство.

7.2. Качество обслуживания для эмулируемого сервиса

От эмулируемых устройств не требуется обеспечение такого же качества сервиса, который присущ естественным устройствам. Рабочая группа PWE3 лишь определяет механизмы эмуляции PW, но не сами эмулируемые типы сервиса. Уровень сервиса, достаточный для поддержки тех или иных эмулируемых служб между сервис-провайдером (SP) и его пользователями определяется этими сторонами и не входит в число задач рабочей группы PWE3.

8. Что не относится к числу требований

В различных частях этого документа обозначены некоторые характеристики (аспекты), которые не являются требованиями к эмулируемомму сервису. Эти аспекты не входят в число задач рабочей группы PWE3. Краткий перечень таких вопросов приведен ниже:

  • межсетевое взаимодействие9;

    В межсетевом взаимодействии IWF (Interworking Function) между двумя непохожими протоколами (например, ATM и MPLS, Frame Relay и ATM, ATM и IP, ATM и L2TP и т. п.) прерывает действие используемого в одной сети протокола и транслирует (т. е., отображает) управляющие данные PCI10 в данные PCI того протокола, который используется в другой сети, для функций пользовательского, управляющего и контролирующего плана.

  • иыбор отдельных типов PW;
  • точное соответствие эмулируемых устройств их естественным аналогам;
  • определение механизмов сигнализации для туннелей PSN;
  • определение механизмов управления трафиком для пакетов, содержащих PW PDU;
  • обеспечение той или иной групповой адресации, которая не является естественной для эмулируемой среды.Например, передача кадров Ethernet по групповым адресам IEEE-48 входит в число рассматриваемых вопросов, тогда как групповая адресация типа [MARS] не входит в их число.

9. Качество обслуживания (QoS)

Некоторые службы в естественной форме (например, ATM) могут предлагать более высокое качество обслуживания, нежели доступный в сети Internet уровень best effort11. Параметры QoS, следовательно, важны для того, чтобы эмулируемые услуги были совместимы (но не обязательно идентичны) с естественной их формой. Сетевые операторы сами определяют, как им обеспечивать QoS – они могут выбрать их с учетом имеющихся ресурсов и/или развернутых механизмов QoS.

Чтобы воспользоваться механизмами QoS, определенными другими рабочими группами (например, схемы управления трафиком, определенные группой DiffServ), желательно иметь некоторые механизмы, приводящие к дифференциации пакетов на основе инкапсуляции PDU. Эти механизмы не определены непосредственно в PWE3. Например, если получаемые в результате пакеты относятся к MPLS или IP, поля EXP или DSCP этих пакетов могут применяться для маркировки и дифференциации. PWE3 может включать рекомендации по маркировке и дифференциации.

Применимость PWE3 для того или иного типа сервиса зависит от чувствительности этого сервиса (или реализации CE) к задержкам и их вариациям, а также от способности прикладного уровня компенсировать задержки и их изменения. PWE3 может не подойти для служб, имеющих жесткие ограничения в части требований к задержкам.

10. Вопросы междоменного взаимодействия

Эмуляция PWE имеет значение для конечных точек PW и прозрачна для сетевых устройств между этими точками. Следовательно, междоменные PWE подобны внутридоменным PWE. Если конечные точки PW используют одну модель PWE, они могут эффективно взаимодействовать между собой, независимо от того, относятся эти точки к одному домену или к разным. Для междоменного взаимодействия могут стать более важными вопросы безопасности (например, может использоваться аутентификация конечных точек). При междоменном взаимодействии усложняется поддержка QoS, поскольку сервис-провайдеры не имеют сквозного контроля за трафиком и не могут изменять политику контроля трафика других провайдеров. Для решения задачи обеспечения QoS при междоменном взаимодействии требуется кооперация провайдеров. После того, как на уровне контракта будет достигнуто соглашение об обеспечении высокого качества обслуживания того или иного трафика (например, PWE), можно будет использовать механизмы. созданные другими рабочими группами (например, Diffserv).

Междоменные туннели PSN в общем случае сложнее с точки зрения организации, разрыва и поддержки, нежели туннели внутри домена. Но эта проблема относится к протоколам туннелирования PSN (таким, как MPLS и L2TPv3) и выходит за пределы PWE3.

11. Вопросы безопасности

Конечные устройства PW, механизмы демультиплексирования PW и данные естественного сервиса могут быть уязвимы для атак. PWE3 следует усиливать механизмы, обеспечиваемые демультиплексорами PW и уровнем PSN. Этим механизмам следует обеспечивать защиту конечных точек PW и механизмов демультиплексирования PW от атак на службы (DoS) и подмены модулей данных естественного сервиса. Предотвращение несанкционированного доступа к конечным точкам PW и другим сетевым устройствам в общем случае обеспечивает эффективную защиту от DoS-атак и подмены (spoofing), обеспечивая важный механизм защиты. Следует обеспечить также механизмы защиты от подмены туннелируемых данных PW. Проверка корректности трафика, адресованного конечной точкой мультиплексору PW является важной компонентой обеспечения целостности инкапсуляции PW. Могут использоваться протоколы защиты, типа [RFC2401].

12. Благодарности

Авторы выражают свою признательность M. Aissaoui, M. Bocci, S. Bryant, R. Cohen, N. Harrison, G. Heron, T. Johnson, A. Malis, L. Martini, E. Rosen, J. Rutemiller, T. So, Y. Stein, S. Vainshtein.

13. Литература

13.1. Нормативные документы

[IFMIB] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[SMIV2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

13.2. Ссылки

[G805] «Generic Functional Architecture of Transport Networks», ITU-T Recommendation G.805, 2000.

[IPTUNMIB] Thaler, D., «IP Tunnel MIB», RFC 2667, August 1999.

[L2TPv3] Lau, J., Townsley, M., and I. Goyret, et al., «Layer Two Tunneling Protocol (Version 3)», Work in Progress12, June 2004.

[MARS] Armitage, G., «Support for Multicast over UNI 3.0/3.1 based ATM Networks», RFC 2022, November 1996.

[MPLS] Rosen, E., Viswanathan, A., and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, January 2001.

[PWE3_ARCH] S. Bryant and P. Pate, et. al., «PWE3 Architecture», Work in Progress14, March 2004.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240115, November 1998.

[TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, «Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)», RFC 3812, June 2004.

[UNI3.0] ATM Forum, «ATM User-Network Interface Specification Version 3.0», Sept. 1993.

14. Адреса авторов

XiPeng Xiao (редактор)

Riverstone Networks

5200 Great America Parkway

Santa Clara, CA 95054

EMail: xxiao@riverstonenet.com

Danny McPherson (редактор)

Arbor Networks

EMail: danny@arbor.net

Prayson Pate (Editor)

Overture Networks

507 Airport Boulevard, Suite 111

Morrisville, NC, USA 27560

EMail: prayson.pate@overturenetworks.com

Vijay Gill

AOL Time Warner

EMail: vijaygill9@aol.com

Kireeti Kompella

Juniper Networks, Inc.

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Thomas D. Nadeau

Cisco Systems, Inc.

300 Beaver Brook Drive

Boxborough, MA 01719

EMail: tnadeau@cisco.com

Craig White

Level 3 Communications, LLC.

1025 Eldorado Blvd.

Broomfield, CO, 80021

EMail: Craig.White@Level3.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

15. Полное заявление авторских прав

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Pseudo-Wire Emulation Edge to Edge – эмуляция сквозного псевдопровода.

2RFC 4197.

3Packet Switched Network.

4PDU – Protocols Data Unit – модуль данных протокола. Прим. перев.

5Protocol Data Unit.

6Equal Cost Multi-Path – множество равноценных путей.

7Native Service Processing – естественная обработка для сервиса.

8Generalized bit error.

9В оригинале — Service Interworking. Прим. перев.

10Protocol Control Information – управляющая информация протокола.

11По-русски, наверное, лучше всего сказать “сделаем, настолько хорошо, насколько сумеем, но без гарантий”. Прим. перев.

12Эта работа завершена и опубликована в RFC 3931, который частично обновлен RFC 5641. Прим. перев.

14Работа завершена и опубликована в RFC 3985. Прим. перев.

15Этот документ признан устаревшим и заменен RFC 4301. Прим. перев.




RFC 3912 WHOIS Protocol Specification

Network Working Group                                      L. Daigle
Request for Comments: 3912                            VeriSign, Inc.
Obsoletes: 954, 812                                   September 2004
Category: Standards Track

Спецификация протокола WHOIS

WHOIS Protocol Specification

PDF

Статус документа

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

Этот документ обновляет спецификацию протокола WHOIS, содержащуюся в RFC 954. Обновление заключается в удалении из RFC 954 материалов, которые не имеют отношения к протоколу и неприменимы к сети Internet в ее современном состоянии. В документе не предпринимается попыток изменения протокола, как такового или добавления вариантов его использования сверх того, что опубликовано в RFC 954.

1. Введение

WHOIS представляет собой основанный на TCP и ориентированный на транзакции “запрос-отклик” протокол, который широко используется в сети Internet для получения информации. Протокол был изначально разработан для поддержки сервиса white pages — получения сведений о зарегистрированных доменных именах, однако сегодня спектр предоставляемой на основе этого протокола информации существенно шире. Протокол обеспечивает представление информации в удобном для человека формате. Данный документ обновляет спецификацию протокола WHOIS и, следовательно, действие документа RFC 954 [1].

В силу исторических причин протокол WHOIS имеет достаточно много недостатков (например, отсутствие языковой поддержки или средств обеспечения безопасности) по сравнению в более современными протоколами IETF. В этом документе не предпринимается попыток исправить эти недостатки – протокол WHOIS просто документируется в его текущем состоянии. Некоторые недостатки WHOIS из числа хорошо известных достаточно подробно рассматриваются в этом документе. Рассмотрение вопросов преодоления недостатков существующего протокола и добавления в него новых функций входит в сферу интересов рабочей группы CRISP в составе IETF.

2. Спецификация протокола

Сервер WHOIS прослушивает клиентские запросы TCP через порт 43. Клиенты WHOIS передают серверу текстовые запросы, а сервер возвращает свои отклики также в текстовом формате. Каждый запрос заканчивается последовательностью символов ASCII CRLF. Отклик может содержать более одной строки, поэтому символы CR и/или LF не должны трактоваться как завершение отклика. Сервер WHOIS закрывает соединение после завершения передачи отклика. Закрытое соединение TCP показывает клиенту, что отклик получен.

3. Пример протокола

Предположим, что некий клиент обращается к серверу WHOIS, на сайте whois.nic.mil для получения информации о пользователе Smith. Обмен пакетами будет иметь вид:

клиент                           сервер whois.nic.mil
open TCP   ---- (SYN) ------------------------------>
           <---- (SYN+ACK) --------------------------
send query ---- "Smith<CR><LF>" -------------------->
get answer <---- "Info about Smith<CR><LF>" ---------
           <---- "More info about Smith<CR><LF>" ----
close      <---- (FIN) ------------------------------
           ----- (FIN) ----------------------------->

4. Реализация

Протокол WHOIS не поддерживает интернационализации и не включает механизмов указания используемого набора символов. Обычно информация храниться в кодировке US-ASCII. На практике некоторые серверы WHOIS, особенно за пределами США могут использовать другие наборы символов для запросов, откликов или для того и другого сразу. Невозможность предсказания или выбора кодировки снижает уровень интероперабельности и практическую пользу протокола WHOIS.

5. Вопросы безопасности

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

Отсутствие механизмов обеспечения безопасности означает, что протокол в текущем состоянии не будет принят IETF.

6. Благодарности

Автор благодарит Рэна Аткинсона (Ran Atkinson) за подготовку первого варианта этого документа. Авторами исходного предварительного стандарта (Draft Standard) для протокола WHOIS являются Ken Harrenstien, Mary Stahl и Elizabeth Feinler.

7. Литература

7.1. Нормативные документы

[1] Harrenstien, K., Stahl, M., and E. Feinler, «NICNAME/WHOIS», RFC 954, October 1985.

Адрес автора

Leslie Daigle

VeriSign, Inc.

21355 Ridgetop Circle

Dulles, VA 20166

US

EMail: leslie@verisignlabs.com; leslie@thinkingcat.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC’s procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.




RFC 3882 Configuring BGP to Block Denial-of-Service Attacks

Network Working Group                                        D. Turk
Request for Comments: 3882                               Bell Canada
Category: Informational                               September 2004

Настройка BGP для блокирования DoS-атак

Configuring BGP to Block Denial-of-Service Attacks

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

В этом документе обсуждается практический метод, использующий группы BGP в качестве способа удаленного запуска механизма создания «черной дыры» для определенной сети-адресата с целью блокирования атаки на службы (denial-of-service или DoS). «Черные дыры» могут создаваться для избранных маршрутизаторов, а не для всех понимающих BGP маршрутизаторов в сети. Документ также описывает метод «сливной трубы» (sinkhole tunnel), использующий группы BGP и туннели для того, чтобы направить трафик в специальный маршрутизатор (sinkhole router) для анализа пакетов.

Оглавление

Исключено из версии HTML

1. Методы активизации «черных дыр» с помощью BGP

Существующие методы организации «черных дыр», запускаемые с помощью BGP1, основаны на изменении адреса следующего интервала BGP2 для сети, атакуемой через сеть iBGP. Генерируется специально подготовленный анонс iBGP от маршрутизатора, находящегося в целевой/атакуемой AS, и в этом анонсе адрес следующего интервала для маршрута в атакуемую сеть (или хост) заменяется на адрес RFC 1918 [RFC1918] (приватный адрес). Большинство маршрутизаторов в Internet (особенно краевые маршрутизаторы) имеет статические маршруты, указывающие на адреса RFC 1918 для null-интерфейса. Такие статические маршруты уводят весь трафик, адресованный в атакуемую сеть, на null-интерфейс.

Когда узел iBGP в целевой AS получает обновление iBGP, анонсируемый префикс будет добавляться в таблицу маршрутизации с адресом из какой-либо сети RFC 1918, в качестве следующего интервала (next-hop). Маршрутизатор будет пытаться преобразовать адрес RFC 1918 для следующего интервала, чтобы квалифицировать маршрут и определить интерфейс для пересылки. Этот процесс будет корректно возвращать в качестве следующего интервала null-интерфейс. В предположении, что маршрутизатор корректно настроен для направления адресованного в сеть RFC 1918 трафика в null-интерфейс, весь трафик, направленный в атакуемую сеть, будет в результате отброшен, а сама атакуемая сеть станет недоступной как для атакующего, так и для всех остальных.

Хотя такой метод позволяет экранировать сетевую инфраструктуру от атак, защищая большое число устройств, он имеет нежелательный побочный эффект, делающий атакуемую сеть недоступной для всей AS, в которой находится эта сеть. Даже если статический маршрут, указывающий на адрес RFC 1918 для null-интерфейса, задан не на всех маршрутизаторах AS, измененное значение next hop делает невозможной доставку трафика легитимным адресатам.

Обычно сетевые операторы используют такие методы в течение коротких периодов. Метод приводит к отбрасыванию трафика, адресованного в атакуемую сеть, на всех точках входа в AS. По умолчанию маршрутизаторам, отбрасывающим трафик в null-интерфейс, следует возвращать по адресу отправителя, относящемуся к исходной/атакующей AS, сообщение «ICMP unreachable».

Когда процедура достигнет этой точки3, один из адресов источников связанного с атакой трафика захватывается путем введения устройства с таким же IP-адресом в домен BGP целевой/атакуемой AS. Устройство, захватившее адрес источника, будет собирать пакеты ICMP unreachable. Адреса отправителей в таких пакетах ICMP будут показывать, через какие из граничных маршрутизаторов атакуемой AS проходит трафик данной атаки. Оператор после этого может вручную заблокировать этот трафик на определенных таким путем маршрутизаторах.

2. Расширенный метод активизации «черных дыр» с помощью BGP

В этом документе описан метод, позволяющий проинструктировать выбранный набор маршрутизаторов о необходимости изменения адреса следующего интервала для определенного префикса путем использования протокола BGP. В качестве следующего интервала может использоваться null-интерфейс или интерфейс рассмотренной ниже «сливной трубы». Метод не использует списков доступа или средств ограничения трафика для трактовки связанного с атакой трафика, а также не включает изменения адреса следующего интервала для всей сети. Значение next hop будет изменяться только на выбранных маршрутизаторах вспомогательной группы BGP в целевой/атакуемой AS.

Для подготовки сети к использованию этого метода оператору нужно определить уникальную группу (community) для каждого граничного маршрутизатора AS, который может использоваться для доставки в сеть связанного с атакой трафика. Например, сеть с номером автономной системы BGP 65001 имеет два граничных маршрутизатора R1 и R2. Группа 65001:1 создается для идентификации маршрутизатора R1, группа 65001:2 – для R2, а группа 65001:666 используется для идентификации обоих маршрутизаторов.

После определения групп BGP маршрутизаторы R1 и R2 нужно настроить, как показано ниже.

  1. Создать статический маршрут, указывающий на сеть RFC 1918 для null-интерфейса.
  2. Создать список управления доступом для AS-Path, которому соответствует анонс локального префикса BGP.
  3. Создать список управления доступом для BGP community, которому соответствует значение группы, выделенное оператором для соответствующего маршрутизатора (например, 65001:1 для маршрутизатора R1).
  4. Создать список управления доступом для BGP community, которому соответствует значение группы, выделенное оператором для всех маршрутизаторов (т. е., 65001:666 для R1 и R2).
  5. В BGP следует применять политику импорта маршрутов iBGP к получаемым анонсам iBGP для реализации показанной ниже логики (должны выполняться все приведенные ниже условия — AND)

  1. Правило, разрешающее маршруты, соответствующие перечисленным ниже критериям, и вносящее указанные изменения:
  1. проверить соответствие группе (community) указанной для данного маршрутизатора (т. е., 65001:1 для R1);

  2. проверить соответствие AS-Path для локально сгенерированных анонсов BGP;
  3. установить для BGP next hop сеть RFC 1918;
  4. заменить BGP community на общеизвестную группу no-advertise (не анонсировать).

  1. Правило, разрешающее маршруты, соответствующие перечисленным ниже критериям и вносящее указанные изменения.
  1. проверить соответствие группе, включающей все маршруты (т. е., 65001:666);
  2. проверить соответствие AS-Path для локально сгенерированных анонсов BGP;
  3. установить для BGP next hop сеть RFC 1918;
  4. заменить BGP community на общеизвестную группу no-advertise.

После того, как заданы правила для R1 и R2, сетевой оператор может в случае атаки анонсировать целевую сеть, которая может содержать маршруты к одному или множеству хостов (/32) в iBGP атакуемой AS. Анонсы должны содержать значение группы, связанное с маршрутизатором или маршрутизаторами, через которые проходит атака, в дополнение к общепринятой группе no-export. Использование групп BGP сохраняет исходный адрес next hop целевой сети на всех маршрутизаторах, где не присутствует специальная маршрутная политика. iBGP будет тогда передавать анонс префиксов во все маршрутизаторы атакуемой AS. Все маршрутизаторы в этой AS, за исключением тех, которые соответствуют указанной в префиксе группе, будут устанавливать маршрут с легитимным значением next hop. Маршрутизаторы, соответствующие группе, также будут устанавливать в своей таблице маршрут, но значение next hop будет указывать на сеть RFC 1918 и далее на null-интерфейс, как при настройке политики для маршрутов и рекурсивном просмотре маршрутов. Поиск соответствия среди локально анонсируемых сетей производится для того, чтобы ни один из партнеров eBGP не мог ошибочно воспользоваться этим анонсом и направить какую-либо сеть в null-интерфейс. Рекомендуется создавать «черную дыру» для атакуемых хостов, но не для всего блока, к которому они относятся, чтобы оказывать минимальное воздействие на работу атакуемой сети.

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

3. «Сливные» туннели

Метод Enhanced BGP-Triggered Black-holing может потребовать просмотра связанного с атакой трафика для его дальнейшего анализа. Это требование усложняет задачу. Обычно при использовании интерфейсов в широковещательные среды операторы для анализа сетевого трафика подключают анализатор к порту коммутатора. Другим вариантом будет анонсирование сетевого префикса, который включает адрес атакуемого хоста в iBGP и заменяет значение next hop адресом «сливного устройства4», способного сохранять трафик для анализа. Этот метод приводит к недоступности служб, обеспечиваемых атакуемыми адресами IP. Внешний (Inter-AS) трафик будет попадать в «слив» вместе с внутренним (Intra-AS). Анализ на уровне пакетов включает перенаправление трафика хоста-адресата в анализатор или маршрутизатор. В результате, если в этот поток входит и легитимный трафик, последний просто не попадет к адресату. В конечном итоге для легитимного трафика атакуемый хост становится недоступным.

Более эффективным вариантом будет использование «сливного туннеля5». Такой туннель организуется на всех возможных точках входа, через которые связанный с атакой трафик может передаваться в атакуемую AS. Используя группы BGP, можно перенаправить связанный с атакой трафик на специальный путь (туннель), где анализатор протоколов может собирать пакеты для последующего их анализа. После анализа трафика он выходит из туннеля и нормально маршрутизируется к хосту-адресату. Иными словами, трафик будет проходить через сеть к анализатору без изменения значений next hop для атакуемой сети. Все маршрутизаторы в домене iBGP атакуемой AS будут иметь корректный адрес next hop и только маршрутизаторы в точках входа будут иметь измененный адрес следующего интервала.

В сети устанавливается «сливной» маршрутизатор с подключенным к нему анализатором протоколов. Этот маршрутизатор настраивается на участие в IGP и iBGP атакуемой AS. Далее создаются туннели (например, с использованием MPLS TE6) от всех маршрутизаторов, через которые может входить связанный с атакой внешний трафик к «сливному» маршрутизатору. При возникновении атаки на хост или сеть передается специально подготовленный анонс iBGP с адресом атакуемого хоста или сети и подходящим адресом next hop, который обеспечит доставку трафика хосту или сети. Этот анонс будет также включать группу (community), которой соответствует набор граничных маршрутизаторов, используемых для передачи в сеть связанного с атакой трафика, как описано в параграфе 2. Новому значению next hop, заданному в правилах всех граничных маршрутизаторов, следует указывать IP-адрес «слива». Этот адрес относится к сети с маской /30, выделенной для «сливного» туннеля, соединяющего граничный маршрутизатор со «сливным».

Маршрутизаторы, которые не соответствуют группе, будут работать как обычно. Отсутствие соответствия в этих маршрутизаторах будет гарантировать, что специальное правило замены значения next hop не будет применено. Трафик, входящий в сеть через граничные маршрутизаторы, которые не соответствуют группе, будет проходить к легитимным адресатам через обычные интерфейсы этих маршрутизаторов. Может также потребоваться передача направленного в туннель трафика адресатам после его анализа. В этом случае создается используемый по умолчанию маршрут к любому интерфейсу, подключенному и сконфигурированному для сети iBGP. Этот маршрут будет также включать физический интерфейс, использованный для создания туннеля. Поскольку адрес next hop не меняется на «сливном» устройстве, попавший в это устройство трафик из туннеля будет передаваться обратно в сеть, благодаря наличию принятого по умолчанию маршрута. Протоколы маршрутизации после этого будут предпринимать попытки корректной маршрутизации трафика адресату (в атакуемую сеть).

Ясно, что этот метод можно использовать не только для анализа трафика, связанного с атаками. Легитимный трафик также можно перенаправить в туннель и вернуть в сеть после анализа без изменения схемы адресации next hop в сети iBGP.

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

Для изменения адреса next hop на граничном маршрутизаторе подсеть RFC 1918 статически маршрутизируется на интерфейс туннеля. Примером такого маршрута может быть

ip route 192.168.0.12 255.255.255.255 Tunnel0

Установка в качестве next hop для IP-адреса получателя значения 192.168.0.12/32 будет приводить к направлению трафика в туннель.

Трафик принимается «сливным» интерфейсом через туннель TE. Следовательно, могут использоваться три метода, а именно – правила ограничения скорости, правила QoS и списки управления доступом. Эти правила позволяют ограничить скорость передачи трафика, связанного с атакой, или отбросить этот трафик совсем. Процесс будет полностью выполнен на интерфейсе “сливного» устройства. Другим полезным применением «сливных» маршрутизаторов является направление трафика в туннели при наличии принятого по умолчанию маршрута, который будет пересылать трафик на интерфейс Ethernet. Этот интерфейс подключается к сети iBGP и гарантирует корректную доставку трафика, который при этом остается доступным анализатору для сбора пакетов и последующего анализа связанного с атакой трафика.

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

4. Вопросы безопасности

Прежде, чем реализовать описанный метод на практике, следует попрактиковаться в контроле партнерских точек eBGP. Пользователи eBGP могут направить в «черную дыру» трафик для той или иной сети, используя группы Blackhole. Для избавления от риска не следует пренебрегать проверкой соответствия для локально генерируемых анонсов BGP с использованием специальной политики маршрутизации.

5. Благодарности

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

6. Литература

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

7. Адрес автора

Doughan Turk

Bell Canada

100 Wynford Drive

EMail: doughan.turk@bell.ca


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

8. Полное заявление авторских прав

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечивается Internet Society.

1BGP-triggered black-holing.

2BGP next hop.

3Отправки сообщения ICMP unreachable. Прим. перев.

4Sinkhole device.

5Sinkhole tunnel.

6Traffic Engineering – организация трафика.




RFC 3874 A 224-bit One-way Hash Function: SHA-224

Network Working Group                                     R. Housley
Request for Comments: 3874                            Vigil Security
Category: Informational                               September 2004

Необратимая 224-битовая хэш-функция SHA-224

A 224-bit One-way Hash Function: SHA-224

PDF

Статус документа

В этом документе содержится информация для сообщества Internet. Документ не содержит каких-либо стандартов Internet. Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2004).

Тезисы

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

1. Введение

В этом документе содержится спецификация 224-битовой необратимой хэш-функции, носящей название SHA-224. Национальный институт стандартов и технологии США (NIST) в документе FIPS 180-2 Change Notice от 28 февраля 2004 подтвердил необратимость хэш-функции SHA-224. Необратимые хэш-функции называют также цифровыми подписями1. Функция SHA-224 основана на алгоритме SHA-256, обеспечивающем необратимое 256-битовое хэширование, подтвержденное NIST [SHA2]. Расчет хэш-значения SHA-224 выполняется в два этапа. Сначала определяется значение SHA-256 (при этом используется иное стартовое значение) и затем полученный результат сокращается до 224 битов.

NIST занимается разработкой руководства по ключам шифрования и недавно этот институт опубликовал для комментариев черновой вариант документа [NISTGUIDE]. В руководстве обсуждаются пять уровней конфиденциальности с ключами размером 80, 112, 128, 192 и 256 битов. Для всех этих уровней, за исключением одного, доступны необратимые хэш-функции. SHA-224 предназначена для заполнения пустого места в этом списке. Необратимая хэш-функция SHA-224 обеспечивает ключи размером 112 битов, что совпадает с одним из общепринятых вариантов Triple-DES [3DES].

В этом документе приводится спецификация необратимой хэш-функции SHA-224 для сообщества Internet, а также идентификаторы объектов для использования в протоколах, основанных на ASN.1.

1.1. Вопросы применения

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

Для некоторых сред важен каждый передаваемый октет. В таких случаях сокращение сигнатуры на 4 октета по сравнению с SHA-256 имеет важное значение.

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

  • при использовании с алгоритмами шифрования, основанными на ключах размером 112 битов SHA-224 обеспечивает подходящую необратимую хэш-функцию;
  • когда компактность сигнатур не играет важной роли, следует использовать SHA-256, а не SHA-224.

1.2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [STDWORDS].

2. Описание SHA-224

Алгоритм SHA-224 может использоваться при расчете необратимых хэш-значений для сообщений размером до 264 битов.

SHA-224 использует алгоритм SHA-256 [SHA2]. Для расчета необратимой хэш-функции SHA-256 использует опись2 из шестидесяти четырех 32-битовых слов, восемь 32-битовых рабочих переменных и создает хэш-значение из восьми 32-битовых слов.

Функция SHA-224 определяется также, как SHA-256, с двумя отличиями:

  1. Для SHA-224 начальное хэш-значение представляет собой восемь 32-битовых рабочих переменных, совместно обозначаемых как H, которые должны быть равны:

         H_0 = c1059ed8               H_4 = ffc00b31
         H_1 = 367cd507               H_5 = 68581511
         H_2 = 3070dd17               H_6 = 64f98fa7
         H_3 = f70e5939               H_7 = befa4fa4
  1. SHA-224 просто использует первые сеть 32-битовых слов результата SHA-256. Таким образом, окончательное значение H представляет собой конкатенацию (||) семи компонент:

         H_0 || H_1 || H_2 || H_3 || H_4 || H_5 || H_6

3. Тестовые векторы

В этом параграфе описаны три тестовых вектора, которые могут использоваться для проверки реализации алгоритма SHA-224.

3.1. Вектор #1

Предположим, что хэшируемое сообщение содержит 24-битовую строку ASCII «abc», которая эквивалентна двоичной строке:

      01100001 01100010 01100011

Функция SHA-224 в этом случае должна возвращать значение (в шестнадцатеричном представлении):

      23097d22 3405d822 8642a477 bda255b3 2aadbce4 bda0b3f7 e36c9da7

3.2. Вектор #2

При хэшировании 448-битовой строки ASCII «abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq» функция SHA-224 должна возвращать значение (в шестнадцатеричном представлении):

      75388b16 512776cc 5dba5da1 fd890150 b0c6455c b4f58b19 52522525

3.3. Вектор #3

При хэшировании сообщения, содержащего 1 000 000 символов «a», функция SHA-224 должна возвращать хэш-значение (в шестнадцатеричном представлении):

      20794655 980c91d8 bbb4c1ea 97618a4b f03f4258 1948b2ee 4ee7ad67

4. Идентификатор объекта

NIST выделил идентификатор объекта ASN.1 [X.208-88, X.209-88] для SHA-224. Некоторые протоколы используют идентификатор объекта для именования необратимых хэш-функций. Примером такого протокола является CMS [CMS]. Разработчики такого типа протоколов, которые используют SHA-224, должны указывать идентификатор объекта.

    id-sha224  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                    country(16) us(840) organization(1) gov(101)
                    csor(3) nistalgorithm(4) hashalgs(2) sha224(4) }

5. Вопросы безопасности

Необратимые хэш-функции обычно используются с другими криптографическими алгоритмами (такими, как алгоритмы создания цифровых подписей и кодов аутентификации сообщений) или при генерации случайных значений. При использовании необратимой хэш-функции вместе с другим алгоритмом могут присутствовать указанные где-либо требования по уровню безопасности (размер ключа). Например, если сообщение подписывается сигнатурой размером 128 битов, алгоритм создания такой сигнатуры может потребовать использования необратимой хэш-функции, возвращающей хэш-значение такого же размера. SHA-224 генерирует 112-битовые хэш-значения, в общем случае пригодные для Triple-DES [3DES].

Этот документ содержит спецификацию SHA-224 для сообщества Internet. Автор не дает гарантий безопасности для того или иного использования алгоритма. Однако, поскольку применение SHA-256 обеспечивает ожидаемый уровень безопасности, SHA-224 также будет обеспечивать ожидаемый уровень.

6. Литература

6.1. Нормативные документы

[SHA2] Federal Information Processing Standards Publication (FIPS PUB) 180-2, Secure Hash Standard, 1 August 2002.

[STDWORDS] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

6.2. Информационные ссылки

[3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.

[CMS] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3852, July 2004.

[NISTGUIDE] National Institute of Standards and Technology. Second Draft: «Key Management Guideline, Part 1: General Guidance.» June 2002. [http://csrc.nist.gov/encryption/kms/guideline-1.pdf]

[X.208-88] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.

[X.209-88] CCITT Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

7. Благодарности

Большое спасибо Джиму Шааду (Jim Schaad) за генерацию тестовых векторов. Для подтверждения корректности этих векторов была использована реализация Брайана Глэдмана (Brian Gladman).

8. Адреса авторов

Russell Housley

Vigil Security, LLC

918 Spring Knoll Drive

Herndon, VA 20170

USA

EMail: housley@vigilsec.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

9. Полное заявление авторских прав

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1 Английский термин — message digest. Прим. перев.

2 В оригинале message schedule. Прим. перев.




RFC 3036 LDP Specification

Этот документ заменен RFC 5036.

Оригинал доступен по ссылке.