RFC 4635 HMAC SHA TSIG Algorithm Identifiers

Network Working Group                                    D. Eastlake 3rd
Request for Comments: 4635                         Motorola Laboratories
Category: Standards Track                                    August 2006

 

Идентификаторы HMAC SHA алгоритма TSIG

HMAC SHA TSIG Algorithm Identifiers

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

Использование записей DNS1 TSIG требует спецификации кода криптографической аутентификации сообщений. В настоящее время спецификации имеются только для двух алгоритмов TSIG — HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) и GSS (Generic Security Service). Данный документ стандартизует идентификаторы и требования к реализациям для дополнительных алгоритмов HMAC SHA (Secure Hash Algorithm), а также спецификацию и отсечку значений HMAC в TSIG.

Оглавление

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

1. Введение

[RFC2845] задает спецификацию записей о ресурсах TSIG RR2, которые могут применяться для аутентификации запросов и откликов DNS (Domain Name System [STD13]). Запись RR содержит элемент данных с синтаксисом доменного имени, указывающий используемый алгоритм аутентификации. [RFC2845] определяет имя HMAC-MD5.SIG-ALG.REG.INT для кодов аутентификации, использующих алгоритм HMAC3 [RFC2104] с хэшированием MD54 [RFC1321]. Агентство IANA также зарегистрировало gss-tsig в качестве идентификатора аутентификации TSIG, при которой криптографические операции делегируются службе GSS5 [RFC3645].

Отметим, что использование TSIG предполагает предварительное соглашения между распознавателем (resolver) и сервером в части используемого алгоритма и ключа.

В разделе 2 данного документа указаны дополнительные имена алгоритмов аутентификации TSIG, основанных на алгоритмах US NIST SHA (United States, National Institute of Science and Technology, Secure Hash Algorithm) и HMAC, а также приведены требования к реализациям этих алгоритмов.

В разделе 3 рассмотрено влияние несовпадения выходного размера указанной хэш-функции и размера кода MAC6 в TSIG RR. В частности, что избыточные по размеру значению усекаются, а малоразмерные приводят к ошибке.

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

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

2. Алгоритмы и идентификаторы

Записи TSIG RR [RFC2845] используются для аутентификации запросов и откликов DNS. Они предназначены для обмена эффективными симметричными кодами аутентификации, создаваемые на основе общего секрета (вогут применяться также асимметричные подписи с использованием SIG RR [RFC2931], в частности могут применяться записи SIG(0) для подписи транзакций). При использовании сго строгой функцией хэширования HMAC [RFC2104] обеспечивает способ расчета таких симметричных кодов аутентификации. Единственным алгоритмом TSIG на основе HMAC был указан HMAC-MD5.SIG-ALG.REG.INT, использующий функцию MD5 [RFC1321].

Использование алгоритма SHA-1 [FIPS180-2, RFC3174] с размером хэша 160 битов, в сравнении со 128 битами MD5, а также дополнительных алгоритмов хэширования из семейства SHA [FIPS180-2, RFC3874, RFC4634] с размерами хэша 224, 256, 384 и 512 битов в некоторых случаях может обеспечивать преимущества. Добавление этих алгоритмов обусловлено возможностью успешных криптоаналитических атак в случае применения более коротких значений.

Использование TSIG между распознавателем и сервером DNS согласовывается этими сторонами. Такое соглашение может включать поддержку дополнительных алгоритмов и критерии приемлемости алгоритмов и методов отсечки, к которым применимы ограничения и рекомендации разделов 3 и 4. Согласование ключей может выполняться с помощью механизма TKEY [RFC2930] или иным взаимоприемлемым методом.

Текущие идентификаторы HMAC-MD5.SIG-ALG.REG.INT и gss-tsig включены в приведенную ниже таблицу для удобства. Поддерживающие TSIG реализации должны поддерживать HMAC SHA1 и HMAC SHA256, а также могут поддерживать gss-tsig и другие перечисленные ниже алгоритмы.

Обязательный

HMAC-MD5.SIG-ALG.REG.INT

Необязательный

gss-tsig

Обязательный

hmac-sha1

Необязательный

hmac-sha224

Обязательный

hmac-sha256

Необязательный

hamc-sha384

Необязательный

hmac-sha512

Следует реализовать алгоритм SHA-1 с отсечкой до 96 битов (12 октетов).

3. Задание отсечки

Когда размер желательно сокращать и полной силы HMAC не требуется, разумно отсекать выход HMAC по размеру и применять для аутентификации сокращенное значение. Опция HMAC SHA-1 с отсечкой до 96 битов доступна для некоторых протоколов IETF, включая IPsec и TLS.

TSIG RR [RFC2845] включает поле размера кода аутентификации MAC size, которое указывает размер поля MAC в октетах. Однако [RFC2845] не задает поведения в ситуациях, когда размер поля MAC отличается от выходного размера конкретной функции HMAC. Отсечка выхода HMAC до размера поля MAC описана ниже.

3.1. Спецификация отсечки

Спецификация обработки TSIG изменяется в соответствии с приведенными ниже описаниями.

  1. Значение поля MAC size превышает выходной размер функции HMAC.

    Такая ситуация недопустима и при получении пакета с неполным полем MAC такой пакет должен отбрасываться с возвратом сообщения об ошибке RCODE 1 (FORMERR).

  2. Значение поля MAC size совпадает с выходным размером функции HMAC.

    Выполняются операции, указанные в [RFC2845] с представлением полного результата HMAC.

  3. Значение поля MAC size меньше выходного размера функции HMAC, но больше указанного ниже в п. 4.

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

  4. Значение поля MAC size меньше большего из двух чисел — 10 (октетов) и половина выходного размера хэш-функции.

    За исключением некоторых сообщений об ошибках TSIG, описанных в параграфе 3.2 RFC 2845, где допускается нулевое значение MAC,генерация таких пакетов недопустима и при получении они должны отбрасываться с возвратом ошибки RCODE 1 (FORMERR). В качестве предельного размера для этого случая может приниматься большее из значений половины выходного размера упоминаемых здесь хэш-функций (кроме MD5) и 10 октетов для MD5.

4. Политика отсечки TSIG и информирование об ошибках

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

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

Когда локальная политика разрешает принимать TSIG с конкретным алгоритмом и отличным от нуля значением параметра отсечки, ей следует разрешать также использование этого алгоритма с меньшей отсечкой (более длинный код MAC) или с полным выводом HMAC.

Независимо от заданного локальной политикой минимального допустимого размера усеченного кода MAC, отклик следует передавать с размером MAC не меньше полученного в соответствующем запросе, если запрос не указывает размер MAC, превышающий выходной размер HMAC.

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

При получении TSIG с отсечкой, разрешенной разделом 3, но размером MAC, который слишком мал по требованиям локальной политики, должна возвращаться ошибка RCODE 22 (BADTRUNC).

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

Этот документ (1) регистрирует в IANA новые идентификаторы алгоритмов TSIG, указанные в разделе 2, и (2) выделяет код BADTRUNC RCODE 22, описанный в разделе 4 [RFC2845].

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

Для всех алгоритмов аутентификации сообщений, упомянутых в этом документе, более длинные значения кодов предполагаются более защищенными. Хотя имеются аргументы в пользу того, что некоторое укорачивание MAC усиливает защиту за счет сокращения доступной атакующему информации, однако избыточная отсечка явно ослабляет аутентификацию, за счет уменьшения числа битов, которые атакующий должен попытаться угадать методом подбора (или грубой силы — brute force) [RFC2104].

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

Прочтите раздел «Вопросы безопасности» в [RFC2845], а также одноименный раздел [RFC2104], где рассматриваются ограничения для используемой в данном RFC отсечки.

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

[FIPS180-2] «Secure Hash Standard», (SHA-1/224/256/384/512) US Federal Information Processing Standard, with Change Notice 1, February 2004.

[RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm «, RFC 1321, April 1992.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

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

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, «Secret Key Transaction Authentication for DNS (TSIG)», RFC 2845, May 2000.

[RFC3174] Eastlake 3rd, D. and P. Jones, «US Secure Hash Algorithm 1 (SHA1)», RFC 3174, September 2001.

[RFC3874] Housley, R., «A 224-bit One-way Hash Function: SHA-224», RFC 3874, September 2004.

[RFC4634] Eastlake, D. and T. Hansen, «US Secure Hash Algorithms (SHA)», RFC 4634, July 2006.

[STD13] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.
Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

8. Дополнительная литература

[RFC2930] Eastlake 3rd, D., «Secret Key Establishment for DNS (TKEY RR)», RFC 2930, September 2000.

[RFC2931] Eastlake 3rd, D., «DNS Request and Transaction Signatures ( SIG(0)s )», RFC 2931, September 2000.

[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, «Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS- TSIG)», RFC 3645, October 2003.

Адрес автора

Donald E. Eastlake 3rd

Motorola Laboratories

155 Beaver Street

Milford, MA 01757 USA

Phone: +1-508-786-7554 (w)

EMail: Donald.Eastlake@motorola.com

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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

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/SHE 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 procedures with respect to rights in RFC 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 обеспечено IETF Administrative Support Activity (IASA).

1Domain Name System — система доменных имен.

2Resource Record.

3Hashed Message Authentication Code — хэшированный код аутентификации сообщения.

4Message Digest 5 — подпись (дайджест) сообщения, вариант 5.

5Generic Security Service — базовый сервис защиты.

6Message Authentication Code — код аутентификации сообщения.




RFC 4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding («IGMP/MLD Proxying»)

Network Working Group                                          B. Fenner
Request for Comments: 4605                                 AT&T Research
Category: Standards Track                                          H. He
                                                                  Nortel
                                                             B. Haberman
                                                                 JHU-APL
                                                              H. Sandick
                                          Little River Elementary School
                                                             August 2006

 

Пересылка групповых пакетов на основе IGMP/MLD Proxy

Internet Group Management Protocol (IGMP) /

Multicast Listener Discovery (MLD)-Based Multicast Forwarding

(«IGMP/MLD Proxying»)

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

В некоторых вариантах топологии нет потребности в использовании протокола групповой маршрутизации. Промежуточному устройству достаточно получить данные о принадлежности к группе и просто пересылать групповые пакеты на основе этой информации. В данном документе описан механизм рассылки на основе лишь информации IGMP1 или MLD2.

1. Введение

Этот документ использует групповую маршрутизацию на базе остовного дерева [MCAST] для сред IGMP или MLD. Топология среды ограничена деревом, поскольку не задается протокола для построения дерева в более сложной топологии. Предполагается, что корень дерева соединен с более широкой инфраструктурой групповой адресации.

1.1. Мотивация

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

Использование пересылки на основе IGMP/MLD для репликации группового трафика на краевых устройствах можно значительно упростить устройство и реализацию такого оборудования. За счет отказа от поддержки сложных протоколов групповой маршрутизации типа PIM4 или DVMRP5 снижается не только стоимость устройств, но и операционные расходы. Другим преимуществом является независимость промежуточных устройств (proxy device) от протоколов групповой маршрутизации, используемых в ядре сети. Следовательно, такие устройства-посредники можно легко развернуть в любой сети с групповой передачей.

Отказоустойчивость краевых устройств обычно обеспечивается за счет «горячего» резервирования соединения с ядром сети. При отказе основного соединения такое устройство просто переключается на резервный канал. Пересылка на основе IGMP/MLD может выиграть от такого решения, используя избыточное соединение для резервирования связи с multicast-маршрутизаторами. При переключении краевого устройства на резервный канал восходящее proxy-соединение также будет работать через этот канал.

1.2. Заявление о применимости

Пересылка на основе IGMP/MLD работает только в топологии простого дерева. Дерево настраивается вручную путем указания восходящих и нисходящих интерфейсов на каждом промежуточном устройстве. В дополнение к этому применяемую схему адресации IP следует настроить так, чтобы устройство-посредник могло быть выбранным в качестве IGMP/MLD Querier для того, чтобы иметь возможность пересылки группового трафика. Кроме промежуточных устройств не используется каких-либо multicast-маршрутизаторов и предполагается, что корень дерева соединен с более широкой инфраструктурой групповой передачи. Работа данного протокола ограничена одним административным доменом.

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

1.3. Соглашения

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

Этот документ является результатом работы группы MAGMA6 в рамках IETF7. Комментарии приветствуются и их следует направлять по адресу списка рассылок группы magma@ietf.org и/или непосредственно авторам.

2. Определения

2.1. Восходящий интерфейс

Интерфейс промежуточного устройства (proxy device) в направлении корня дерева. Используется также термин «хост-интерфейс» (Host interface).

2.2. Нисходящий интерфейс

Каждый из интерфейсов промежуточного устройства, который не направлен в сторону корня дерева. Используется также термин «интерфейс маршрутизатора» (Router interface).

2.3. Групповой режим

В среде IPv4 multicast-группа относится к IGMP версии 1 (IGMPv1) [RFC1112], если она использует отчеты IGMPv1, к IGMP версии 2 (IGMPv2) [RFC2236] при использовании отчетов IGMPv2, но не IGMPv1, и к IGMP версии 3 (IGMPv3) [RFC3376], если она слышит отчеты IGMPv3, но не слышит IGMPv1 и IGMPv2.

В среде IPv6 multicast-группа относится к MLD версии 1 (MLDv1) [RFC2710], если в ней используются отчеты MLDv1. MLDv1 является эквивалентом IGMPv2. Группа относится к MLD версии 2 (MLDv2) [MLDv2], если слышны отчеты MLDv2, но не слышны MLDv1. MLDv2 является эквивалентом IGMPv3.

2.4. Подписка

Когда группа работает в режиме IGMPv1 или IGMPv2/MLDv1, подпиской на группу является принадлежность интерфейса к данной группе. Для групп с режимом IGMPv3/MLDv2 подпиской является элемент состояния IGMPv3/MLDv2, т. е., неупорядоченный список (групповой адрес, групповой таймер, режим фильтрации, список источников) на интерфейсе.

2.5. База данных о принадлежности

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

(групповой адрес, режим фильтрации, список источников)

Определения полей «режим фильтрации» (filter-mode) и «список источников» (source-list) приведены в спецификациях IGMPv3/MLDv2 [RFC3376, MLDv2]. Операционное поведение базы данных описано в параграфе 4.1.

3. Абстрактное определение протокола

Промежуточное устройство с пересылкой на основе IGMP/MLD имеет один восходящий и один или множество нисходящих интерфейсов. Роли интерфейсов явно задаются в конфигурации устройства — протокола, определяющего тип интерфейса, не предусмотрено. Устройство выполняет связанную с маршрутизацией часть протокола IGMP [RFC1112, RFC2236, RFC3376] или MLD [RFC2710, MLDv2] на своих исходящих интерфейсах и связанную с хостом часть IGMP/MLD — на восходящем интерфейсе. Промежуточному устройство недопустимо выполнять связанную с маршрутизацией часть IGMP/MLD на его восходящем интерфейсе.

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

Промежуточное устройство передает отчеты о принадлежности IGMP/MLD на восходящем интерфейсе по запросам, а также незапрошенные отчеты при изменении базы данных.

Когда промежуточное устройство получает пакет, адресованный в multicast-группу (канал в SSM8), оно использует список, состоящий из его восходящего интерфейса и всех входящих интерфейсов, связанных с подпиской на относящейся к этому пакету, для которых имеется статус IGMP/MLD Querier. Этот список может создаваться динамически или кэшироваться. Устройство исключает из списка принявший пакет интерфейс и пересылает этот пакет во все оставшиеся в списке интерфейсы (возможно, и в восходящий).

Отметим, что необходимость иметь статус запрашивающего (querier) на прокси-устройстве для пересылки пакетов вносит ограничения в схему используемой адресации IP — в частности, пересылающие на базе IGMP/MLD устройства должны иметь адрес, который меньше IP-адреса любого потенциального IGMP/MLD Querier для выбора этого устройства в качестве IGMP/MLD Querier. Правило выбора IGMP/MLD Querier определяет в качестве запрашивающего устройство с наименьшим адресом IP (это правило определено в спецификациях IGMP/MLD, как элемент поведения IGMP/MLD). По этой причине, если выбор IGMP/MLD Querier отдается устройству, не являющемуся прокси, пересылка пакетов не будет выполняться.

На рисунке приведен пример среды с пересылкой исключительно на основе IGMP/MLD.

           ЛВС 1  ----------------------------------------
                  Восходящ.|                | Восходящ.
                           A(не прокси)     B(прокси)
                  Нисходящ.|(наименьший IP) | Нисходящ.
           ЛВС 2  --------------------------------------

 

Устройство A имеет наименьший адрес IP в сети ЛВС 2, но не является прокси-устройством. В соответствии с правилом выбора IGMP/MLD Querier устройство A будет выбрано для ЛВС 2, поскольку оно имеет наименьший адрес IP. Устройство B не будет пересылать трафик в ЛВС 2, поскольку оно не является запрашивающим для этой сети.

Выбор единственного пересылающего прокси обусловлен необходимостью предотвращения петель и избыточного трафика в каналах, которые считаются нисходящими множеством устройств, пересылающих пакеты на основе IGMP/MLD. Это правило piggy-backs для выбора IGMP/MLD Querier. Использование процесса выбора IGMP/MLD Querier для выбора пересылающего прокси обеспечивает на локальном канале функциональность, похожую на механизм PIM Assert. На канале с единственным пересылающим на базе IGMP/MLD устройством это правило может быть отменено (т. е., устройство может быть настроено на пересылку пакетов через интерфейс, для которого оно не имеет статуса querier). Однако используемая по умолчанию конфигурация должна включать указанное правило для поддержки избыточности, как показано на рисунке ниже.

           ЛВС 1  --------------------------------------
                  Восходящ.|              | Восходящ.
                           A              B
                  Нисходящ.|              | Нисходящ.
           ЛВС 2  --------------------------------------

 

ЛВС 2 может иметь два промежуточных устройства — A и B. В такой конфигурации одно из прокси-устройств должно быть выбрано для пересылки пакетов. Этот документ требует, чтобы пересылка выполнялась устройством, которое имеет статус IGMP/MLD querier. Следовательно, промежуточное устройство A будет пересылать пакеты в ЛВС 2 только в том случае, когда оно выбрано запрашивающим (querier). На приведенном выше рисунке, если A является единственным прокси-устройством, оно может пересылать пакеты даже при выборе в качестве querier устройства B.

Отметим, что это не обеспечивает предотвращения «восходящей петли» (upstream loop). Пример можно видеть на следующем рисунке.

           ЛВС 1  --------------------------------------
                  Восходящ.|              | Нисходящ.
                           A              B
                  Нисходящ.|              | Восходящ.
           ЛВС 2  --------------------------------------

 

B будет безусловно пересылать пакеты из ЛВС 2 в ЛВС 1 и A будет безусловно пересылать пакеты из ЛВС 1 в ЛВС 29, что приведет к возникновению петли в восходящем направлении. Для устранения таких петель требуется протокол групповой маршрутизации, поддерживающий алгоритм построения дерева пересылки.

3.1. Топологические ограничения

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

3.2. Supporting Senders

Для обеспечения возможности передачи отправителям, находящимся внутри прокси-дерева, весь трафик пересылается в направлении корня. Multicast-маршрутизатор (маршрутизаторы), соединенный с более широкой инфраструктурой групповой передачи, следует настроить так, чтобы все системы внутри прокси-дерева трактовали, как подключенные напрямую — например, для PIM-SM10 [PIM-SM]. Этим маршрутизаторам следует инкапсулировать трафик от новых источников внутри прокси-дерева в пакеты Register, как будто эти источники подключены непосредственно к маршрутизатору.

Эти настройки задаются вручную — групповая пересылка на основе IGMP/MLD не поддерживает для восходящих маршрутизаторов прокси-дерева способа детектирования подключенных к дереву сетей. Если прокси-топология совпадает с топологией маршрутизации, эту информацию можно получить от протокола маршрутизации (например, маршрутизатор можно настроить так, чтобы он трактовал групповые пакеты из всех префиксов, полученных от протокола маршрутизации X через интерфейс Y, как пакеты от подключенных непосредственно систем).

4. Поведение промежуточного устройства

В этом разделе более подробно описана работа устройства групповой пересылки на основе IGMP/MLD.

4.1. База данных о принадлежности

Промежуточное устройство выполняет связанную с маршрутизацией часть протокола IGMP/MLD на каждом из своих нисходящих интерфейсов. Для каждого интерфейса используемая версия IGMP/MLD задается явно и по умолчанию используется старшая из поддерживаемых системой версий.

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

База данных о принадлежности к группам представляет собой множество записей вида:

(групповой адрес, режим фильтрации, список источников)

Каждая запись является результатом слияния всех подписок для данного группового адреса на нисходящих интерфейсах. Если некоторые подписки относятся к версии IGMPv1 или IGMPv2/MLDv1, они преобразуются к версии IGMPv3/MLDv2. Подписки IGMPv3/MLDv2 и преобразованные подписки сначала обрабатываются на предмет удаления таймеров в подписках, а затем, если используется режим фильтрации EXCLUDE, удаляются все источники, для которых значение таймера источника > 0. После предварительной обработки подписки сливаются с использованием правил слияния для множества принадлежностей к группам на одном интерфейсе (правила указаны в параграфе 3.2 спецификации IGMPv3 [RFC3376] и параграфе 4.2 спецификации MLDv2 [MLDv2]) для создания записи о принадлежности к группам. Например, имеется два нисходящих интерфейса I1 и I2 с подписками на групповой адрес G. I1 имеет подписку IGMPv2/MLDv1, которая имеет вид (G). I2 имеет подписку IGMPv3/MLDv2 с информацией о принадлежности к группе (G, INCLUDE, (S1, S2)). Подписка I1 преобразуется к версии IGMPv3/MLDv2 и будет иметь вид (G, EXCLUDE, NULL). Затем эти подписки обрабатываются и сливаются, давай в результате запись о принадлежности к группе (G, EXCLUDE, NULL).

Промежуточное устройство выполняет относящуюся к хосту часть протокола IGMP/MLD на своем восходящем интерфейсе. Если устройство является запрашивающим (querier) IGMPv1 или IGMPv2/MLDv1 в восходящей сети, оно будет выполнять на восходящем интерфейсе функции IGMPv1 или IGMPv2/MLDv1. В противном случае будет использоваться IGMPv3/MLDv2.

Если прокси-устройство выполняет на восходящем интерфейсе функции IGMPv3/MLDv2, то при изменении базы данных о принадлежности к группам через восходящий интерфейс будет передаваться отчет о таком изменении, как будто это устройство является хостом, выполнившим соответствующие действия. Если промежуточное устройство выполняет на восходящем интерфейсе функции IGMPv1 или IGMPv2/MLDv1, то при создании или удалении записи о принадлежности к группе отчет о таком изменении будет передаваться через восходящий интерфейс. Все прочие изменения в этом случае игнорируются. При отправке промежуточным устройством отчетов, использующих IGMPv1 или IGMPv2/MLDv1 в записи о принадлежности к группе заполняется только поле группового адреса.

4.2. Пересылка пакетов

Промежуточное устройство пересылает полученные на восходящем интерфейсе пакеты в свои нисходящие интерфейсы на основе подписок для этого интерфейса с учетом статуса IGMP/MLD Querier на каждом интерфейсе прокси-устройства. Промежуточное устройство пересылает все пакеты, полученные на любом нисходящем интерфейсе в восходящий интерфейс и друге нисходящие интерфейсы (в соответствии с подписками на каждом интерфейсе и статусом IGMP/MLD Querier для него). Промежуточное устройство может использовать кэширование, чтобы не приходилось принимать решение о пересылке для каждого отдельного пакета, но этот кэш должен обновляться с использованием указанного выше правила при каждом изменении информации, использованной для создания кэша.

4.3. Поддержка SSM

Для поддержки специфической для источника групповой рассылки (SSM11) промежуточное устройство должно соответствовать спецификации применения IGMPv3 для SSM [SSM]. Отметим, что прокси-устройство должно соответствовать требованиям IGMP Host и IGMP Router для SSM, поскольку оно выполняет IGMP Host Portion на восходящем интерфейсе и IGMP Router Portion на каждом нисходящем интерфейсе.

Интерфейс может быть настроен на работу в режиме IGMPv1 или IGMPv2. В таких случаях семантика SSM не будет поддерживаться интерфейсом. Однако промежуточным устройствам, соответствующим данной спецификации, следует игнорировать подписки IGMPv1 и IGMPv2, передаваемые по адресам SSM. Более важным является то, что пакеты со специфическими для источника адресами не следует пересылать на интерфейсы с подписками IGMPv2 или IGMPv1 для таких адресов.

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

Поскольку пересылку пакетов выполняют только устройства со статусом Querier, процесс выбора IGMP/MLD Querier может приводить к возникновению «черных дыр», если в качестве Querier будет выбрано не пересылающее пакеты устройство. Атакующий из ЛВС на нисходящей стороне может спровоцировать выбор себя в качестве Querier, что приведет к блокированию пересылки пакетов.

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

Пересылка на основе IGMP/MLD не обеспечивает механизмов обнаружения «восходящих петель» (upstream loop), описанных в разделе 3. Следовательно, для предотвращения проблем, связанных с такими петлями, должны использоваться административные средства, гарантирующие отсутствие таких петель в среде IGMP/MLD Proxy.

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

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

Авторы благодарят Erik Nordmark, Dave Thaler, Pekka Savola, Karen Kimball и других людей за рецензирование спецификации и комментарии к ней.

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

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

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, «Internet Group Management Protocol, Version 3», RFC 3376, October 2002.

[RFC2236] Fenner, W., «Internet Group Management Protocol, Version 2», RFC 2236, November 1997.

[RFC1112] Deering, S., «Host extensions for IP multicasting», STD 5, RFC 1112, August 1989.

[RFC2710] Deering, S., Fenner, W., and B. Haberman, «Multicast Listener Discovery (MLD) for IPv6», RFC 2710, October 1999.

[MLDv2] Vida, R. and L. Costa, «Multicast Listener Discovery Version 2 (MLDv2) for IPv6», RFC 3810, June 2004.

[SSM] Holbrook, H., Cain, B., and B. Haberman, «Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast», RFC 4604, August 2006.

8. Дополнительная литература

[MCAST] Deering, S., «Multicast Routing in a Datagram Internetwork», Ph.D. Thesis, Stanford University, December 1991.

[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, «Protocol Independent Multicast — Sparse Mode (PIM-SM): Protocol Specification (Revised)», RFC 4601, August 2006.

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

Bill Fenner

AT&T Labs — Research

1 River Oaks Place

San Jose, CA 95134

Phone: +1 408 493-8505

EMail: fenner@research.att.com

Haixiang He

Nortel

600 Technology Park Drive

Billerica, MA 01821

EMail: haixiang@nortel.com

Brian Haberman

Johns Hopkins University Applied Physics Lab

11100 Johns Hopkins Road

Laurel, MD 20723-6099

EMail: brian@innovationslab.net

Hal Sandick

Little River Elementary School

2315 Snow Hill Road

Durham, NC 27712

EMail: sandick@nc.rr.com

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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

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/SHE 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 procedures with respect to rights in RFC 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 обеспечено IETF Administrative Support Activity (IASA).

1Internet Group Management Protocol — протокол управления группами.

2Multicast Listener Discovery — обнаружение групповых получателей.

3Digital Subscriber Line Access Multiplexer.

4Protocol Independent Multicast — независимая от протокола групповая пересылка.

5Distance Vector Multicast Routing Protocol — протокол групповой маршрутизации на основе «дистантного» вектора.

6Multicast & Anycast Group Membership — принадлежность к группам Multicast и Anycast.

7Internet Engineering Task Force.

8Source-Specific Multicast — связанная с источником групповая адресация.

9В исходном документе указаны обратные направления пересылки, что является ошибкой (см. https://www.rfc-editor.org/errata_search.php?eid=3285). Прим. перев.

10Protocol Independent Multicast — Sparse Mode.

11Source-Specific Multicast.