Энциклопедия сетевых протоколов

Network Working Group                                    S. Lehtinen
Request for Comments: 4250          SSH Communications Security Corp
Category: Standards Track                            C. Lonvick, Ed.
                                                 Cisco Systems, Inc.
                                                        January 2006

Номера, выделенные для протокола SSH

The Secure Shell (SSH) Protocol Assigned Numbers

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

В этом документе определены инструкции для IANA и начальные значения выделенные IANA для протокола SSH. Документ предназначен исключительно для инициализации реестров IANA, упомянутых в комплекте документов SSH.

1. Введение

В этом документе не определяются какие-либо новые протоколы. Документ предназначен только для создания начальных баз данных IANA для протокола SSH и содержит также инструкции по дальнейшему выделению значений. Кроме одного алгоритма, имеющего в основном историческое значение, данный документ не определяет никаких новых протоколов или диапазонов значений, которые не были бы определены в документах [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH] и [SSH-CONNECT].

2. Разработчики

Основными разработчиками этого комплекта документов являются: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (все из SSH Communications Security Corp) и Markku-Juhani O. Saarinen (университет Jyvaskyla). Darren Moffat был редактором этого комплекта документов и внес важный вклад в работу.

За годы подготовки этого документа множество людей внесло свой вклад. В их число входят: Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse и Tadayoshi Kohno. Указанные в списке люди могли не участвовать в написании данного документа, но они внесли свой вклад в его подготовку.

3. Используемые в документе соглашения

3.1. Ключевые слова RFC 2119

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

3.2. Ключевые слова RFC 2434

Ключевые слова приватное использование (PRIVATE USE), иерархическое выделение (HIERARCHICAL ALLOCATION), выделение в соответствии с порядком запросов (FIRST COME FIRST SERVED), экспертное рассмотрение (EXPERT REVIEW), требуется спецификация (SPECIFICATION REQUIRED), одобрение IESG (IESG APPROVAL), согласование с IETF (IETF CONSENSUS), стандартизация (STANDARDS ACTION) в данном документе при их использовании в контексте распределения пространства имен интерпретируются в соответствии с [RFC2434]. Толкование ключевых слов для ясности продублировано в этом документе.

Приватное использование (PRIVATE USE) — только для приватного или локального использования с типом и целями, определяемыми локальным сайтом. Не предпринимается попыток предотвратить использование этого имени на других сайтах с иными (и несовместимыми) целями. Для IANA нет необходимости рассматривать такие объекты и в общем случае они бесполезны с точки зрения совместимости.

Иерархическое выделение (HIERARCHICAL ALLOCATION) — обладающие полномочиями менеджеры могут выделять контролируемые ими значения, как часть общего пространства имен. IANA контролирует верхние уровни пространства имен в соответствии со своей политикой.

Выделение в соответствии с порядком запросов (FIRST COME FIRST SERVED) — выделенные значения доступны каждому, кто предоставит о себе контактную информацию и краткое описание целей использования. Конкретные значения в общем случае выделяются IANA, конкретные имена обычно выдаются по запросам.

Экспертное рассмотрение (EXPERT REVIEW) — требуется одобрение уполномоченного эксперта (Designated Expert).

Требуется спецификация (SPECIFICATION REQUIRED) — значения и их трактовки должны быть документированы в RFC или иных легкодоступных документах с достаточным уровнем детализации для обеспечения совместимости между независимыми реализациями.

Одобрение IESG (IESG APPROVAL) — выделение должно быть одобрено IESG, но не требуется документирования в RFC (хотя IESG может затребовать документы или иные материалы для поддержки).

Согласование с IETF (IETF CONSENSUS) — новые значения выделяются с согласия IETF. В частности, новые значения выделяются в RFC одобренных IESG. Обычно IESG рассматривает предложения уполномоченных лиц (например, участников рабочей группы, если таковая существует).

Стандартизация (STANDARDS ACTION) — значения выделяются только для предложенных стандартов (Standards Track RFC), одобренных IESG.

3.3. Поля протокола и их значения

В данном наборе документов определяются поля протокола и возможные значения этих полей. Поля будут определяться вместе с протокольными сообщениями. Например, поле SSH_MSG_CHANNEL_DATA определяется следующим образом:

byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel (канал получателя)
string data (данные)

В данном документе поля протокола будут указываться в одинарных кавычках, а значения полей – в двойных. В приведенном выше примере поле ‘data’ может содержать значения «foo» и «bar».

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

Этот документ целиком представляет собой соображения IANA по поводу протокола SSH, как определено в документах [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT]. Данный раздел включает соглашения, используемые при именовании пространств имен, начальное состояние реестра и рекомендации по распределению.

4.1. Номера сообщений

Поле номера сообщения (Message Number) представляет собой один байт, описывающий тип содержимого пакета.

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

Пакеты SSH используют номера сообщений от 1 до 255. Эти номера распределены между различными компонентами:

Протокол транспортного уровня

1 — 19 базовые сообщения транспортного уровня (например, disconnect, ignore, debug и т. п.);

20 — 29 согласование алгоритма;

30 — 49 сообщения, связанные с обменом ключами (допускается совпадение номеров для разных методов аутентификации).

Протокол аутентификации пользователей

50 — 59 базовые сообщения протокола аутентификации;

60 — 79 сообщения, связанные с методом аутентификации (допускается совпадение номеров для различных методов).

Протокол соединений

80 — 89 базовые сообщения протокола;

90 — 127 сообщения, связанные с каналом.

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

128 — 191 резерв

Локальные расширения

192 — 255 локальные расширения.

4.1.2. Начальное распределение

В приведенной ниже таблице содержатся выделенные изначально значения идентификаторов сообщений (Message ID).

4.1.3. Последующее выделение

Запросы на выделение новых номеров для сообщений из диапазонов 1 — 29, 50 — 59, 80 — 127 должны обрабатываться с использованием процедуры стандартизации (STANDARDS ACTION), описанной в [RFC2434].

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

Толкование сообщений с номерами от 60 до 79 связано с используемым методом аутентификации и должно быть указано при определении соответствующего метода.

Запросы на выделение новых номеров в диапазоне от 128 до 191 должны обрабатываться путем согласования с IETF (метод IETF CONSENSUS), как описано в [RFC2434].

IANA не контролирует сообщения с номерами от 192 до 255. Этот диапазон будет сохранен для приватного использования (PRIVATE USE).

4.2. Коды и описания причин разрыва соединения

Код сообщения о разрыве (Disconnection Message ‘reason code’) представляет собой 32-битовое целое число без знака (uint32). Связанное с сообщением Disconnection Message описание (‘description’) причины включает понятный человеку текст, поясняющий причину разрыва соединения.

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

Пакеты протокола, содержащие сообщение SSH_MSG_DISCONNECT, должны иметь код причины ‘reason code’ в диапазоне от 0x00000001 до 0xFFFFFFFF. Конкретные значения описаны в документе [SSH-TRANS].

4.2.2. Начальное распределение

Приведенная таблица содержит выделенные описания (description) и коды причины (reason code) для сообщений SSH_MSG_DISCONNECT.

4.2.3. Последующее выделение

Значения кода причины для сообщений о разрыве (Disconnection Message) должны выделяться последовательно. Запросы на выделение новых значений кодов и связанных с ними описаний (Disconnection Message description) из диапазона 0x00000010 – 0xFDFFFFFF должны обрабатываться методом согласования с IETF, как описано в [RFC2434]. IANA не будет распределять значения Disconnection Message reason code из диапазона 0xFE000000 – 0xFFFFFFFF, сохраняемые для приватного использования, как описано в [RFC2434].

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

Коды причин отказа в канальных соединениях (Channel Connection Failure reason code) указываются 32-битовыми целыми числами без знака (uint32). Связанные с кодом описания (Channel Connection Failure description) представляют собой понятный человеку текст, объясняющий причину отказа. Описания приведены в документе [SSH-CONNECT].

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

Пакеты протокола, содержащие сообщение SSH_MSG_CHANNEL_OPEN_FAILURE, должны иметь значение кода причины отказа (Channel Connection Failure reason code) из диапазона 0x00000001 — 0xFFFFFFFF.

4.3.2. Начальное распределение

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

4.3.3. Последующее выделение

Значения кодов причин отказа Channel Connection Failure reason code должны выделяться последовательно. Запросы на выделение новых значений кодов и связанных с ними описаний из диапазона 0x00000005 — 0xFDFFFFFF должны обрабатываться методом согласования с IETF, как описано в [RFC2434]. IANA не будет выделять значения кодов причины отказа из диапазона 0xFE000000 — 0xFFFFFFFF, оставляя эти значения для приватного использования, как описано в [RFC2434].

4.3.4. Замечания для диапазона, выделенного для приватных целей

Хотя IANA не контролирует использование кодов из диапазона 0xFE000000 — 0xFFFFFFFF, этот диапазон разбит на две части и управляется на основе приведенных ниже соглашений.

• Значения кодов от 0xFE000000 до 0xFEFFFFFF используются с локально распределенными каналами. Например, если в предлагаемом канале типа (channel type) example_session@example.com возникает отказ, сервер будет передавать код причины, выделенный IANA (из указанного выше диапазона 0x00000001 – 0xFDFFFFFF) или локально выделенный код из диапазона 0xFE000000 — 0xFEFFFFFF. Естественно, что в тех случаях, когда сервер не понимает предложенное значение channel type, даже если это определенное локально значение типа канала, код причины должен иметь значение 0x00000003, как указано выше. Если сервер понимает тип канала, но канал не удается открыть, серверу следует передавать локально распределенное значение кода причины, согласованное с предложенным локальным значением типа канала. Предполагается, что на практике сначала будет предприниматься попытка использования выделенного IANA значения ‘reason code’, а потом локально распределенных значений кода причины.
• Для кодов, начинающихся с 0xFF не существует каких-либо ограничений или рекомендаций по использованию. Для этих кодов не предполагается также какой-либо совместимости. Данный диапазон предназначен прежде всего для экспериментальных целей.

4.4. data_type_code и data

Значение Extended Channel Data Transfer data_type_code представляет собой 32-битовое целое число без знака (uint32). Связанное с ним текстовое сообщение data предназначено для человека и описывает тип данных, которые могут передаваться в этом канале.

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

Пакеты протокола, содержащие сообщения SSH_MSG_CHANNEL_EXTENDED_DATA, должны иметь значения data_type_code из диапазона 0x00000001 — 0xFFFFFFFF. Описание приведено в документе [SSH-CONNECT].

4.4.2. Начальное распределение

Начальное распределение значений для data_type_code и data приведено в таблице. Отметим, что значение data_type_code для удобства приведено в десятичном представлении, хотя оно имеет тип uint32.

4.4.3. Последующее выделение

Значения Extended Channel Data Transfer data_type_code должны выделяться последовательно. Запросы на выделение новых кодов типа данных и связанных с ними описаний (data) из диапазона 0x00000002 – 0xFDFFFFFF должны обрабатываться методом согласования с IETF, как описано в [RFC2434]. IANA не будет выделять значений data_type_code из диапазона 0xFE000000 – 0xFFFFFFFF, оставляя их для приватного использования, как описано в документе [RFC2434].

4.5. Терминальные режимы псевдотерминала

Сообщения SSH_MSG_CHANNEL_REQUEST со строкой «pty-req» должны содержать encoded terminal modes. Значения терминальных режимов (encoded terminal modes) представляют собой байтовый поток пар «код-аргумент» (opcode-argument).

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

Пакеты протокола, содержащие сообщение SSH_MSG_CHANNEL_REQUEST со строкой «pty-req», должны включать значение encoded terminal modes. Код операции (opcode) представляет собой 1 байт и может принимать значения от 1 до 255. Коды из диапазона 1 — 159 имеют аргумент типа uint32. Коды операций от 160 до 255 пока не определены.

4.5.2. Начальное распределение

В приведенной ниже таблице дано начальное распределение значений кодированных режимов терминала (encoded terminal modes).

4.5.3. Последующее выделение

Запросы на выделение новых кодов операций и связанных с ними аргументов должны обрабатываться методом согласования с IETF, как описано в документе [RFC2434].

4.6. Имена

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

4.6.1. Соглашения для имен

Все имена, регистрируемые IANA в соответствии со следующими параграфами, должны состоять только из печатаемых символов набора US-ASCII; недопустимо включение в имена символов @, запятых (,), пробелов, управляющих символов (коды ASCII до 32 включительно) и символа ASCII с кодом 127 (DEL). Регистр символов в именах принимается во внимание, недопустимы имена длиной более 64 символов.

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

Имена с символом @ будут использовать формат name@domainname; собственно именем является часть, расположенная слева от символа @. Формат этой части не задается спецификацией, однако она должна содержать только печатаемые символы набора US-ASCII; недопустимо включение запятых (,), пробелов, символов управления (коды ASCII до 32 включительно) и символов с кодом ASCII 127 (DEL). Символ @ должен быть единственным в имени. Часть имени после символа @ должна быть корректным полным доменным именем [RFC1034], контролируемым персоной или организацией, определившей имя. Регистр символов в именах принимается во внимание; недопустимо создание имен, размер которых превышает 64 символа. Каждый домен волен самостоятельно управлять своим локальным пространством имен. Следует отметить, что такие имена похожи на определяемые в соответствии с STD 11 [RFC0822] адреса электронной почты. Однако это сходство совершенно случайно и не имеет ничего общего с STD 11 [RFC0822]. Примером локально определенного имени может служить ourcipher-cbc@example.com.

4.6.2. Последующее выделение имен

Запросы на выделение новых имен должны обрабатываться путем согласования с IETF, как описано в [RFC2434].

4.7. Имена служб

Имя службы (service name) используется для описания протокольного уровня. Определенные в настоящее время имена указаны в таблице справа.

4.8. Имена методов аутентификации

Название метода аутентификации (Authentication Method Name) используется для описания метода применяемого службой ssh-userauth [SSH-USERAUTH]. В таблице справа приводятся определенные в настоящее время имена методов аутентификации.

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

В приведенных ниже таблицах указаны имена, выделенные для типов каналов протокола соединений (Connection Protocol Type) и запросов этого протокола.

4.9.1. Типы каналов протоколов соединений

В таблице приведены имена, выделенные для типа каналов протокола соединений (Connection Protocol Channel Type).

4.9.2. Названия запросов протокола соединений

В таблице приведены имена запросов протокола соединений (Connection Protocol Global Request Name).

4.9.3. Названия запросов канала протокола соединений

В таблице приводятся выделенные значения имен запросов канала протокола соединений (Connection Protocol Channel Request Name).

4.9.4. Начальное распределение имен для сигналов

В таблице справа приведены имена, выделенные для сигналов (Signal Name).

4.9.5. Имена подсистем протокола соединений

Для имен подсистем протокола соединений (Connection Protocol Subsystem Name) начальные значения не выделены.

4.10. Имена методов обмена ключами

Имя diffie-hellman-group1-sha1 служит для метода обмена ключами, использованного Oakley в соответствии с [RFC2409]. SSH поддерживает свое пространство идентификаторов групп, которое логически отличается от Oakley [RFC2412] и IKE. Однако для одной дополнительной группы было адаптировано значение номера, выделенного в [RFC3526], с использованием diffie-hellman-group14-sha1 в качестве имени второй определенной группы. Реализациям следует трактовать эти имена, как простые идентификаторы и не следует предполагать наличие каких-либо связей между группами, используемыми SSH, и группами, определенными для IKE.

В таблице слева приведены имена, выделенные для методов обмена ключами.

4.11. Выделенные имена алгоритмов

4.11.1. Имена алгоритмов шифрования

В таблице приведены имена, выделенные для алгоритмов шифрования (Encryption Algorithm Name).

4.11.2. Имена алгоритмов MAC

В таблице указаны имена, выделенные для алгоритмов MAC (MAC Algorithm Name).

4.11.3. Имена алгоритмов открытых ключей

В таблице слева приведены имена, выделенные для алгоритмов открытых ключей (Public Key Algorithm).

4.11.4. Имена алгоритмов компрессии

В таблице справа перечислены имена, выделенные для алгоритмов сжатия данных (Compression Algorithm).

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

Данный протокол обеспечивает поддержку защищенных шифрованных соединений через сети, не обеспечивающие защиты.

Полное рассмотрение вопросов безопасности для этого протокола содержится в документе [SSH-ARCH].

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

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

[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Architecture», RFC 4251, January 2006.

[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, January 2006.

[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Authentication Protocol», RFC 4252, January 2006.

[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Connection Protocol», RFC 4254, January 2006.

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

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

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

[RFC3526] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

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

[RFC0822] Crocker, D., «Standard for the format of ARPA Internet text messages», STD 11, RFC 822², August 1982.

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

[RFC2412] Orman, H., «The OAKLEY Key Determination Protocol», RFC 2412, November 1998.

[FIPS-46-3] US National Institute of Standards and Technology, «Data Encryption Standard (DES)», Federal Information Processing Standards Publication 46-3, October 1999.

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

Sami Lehtinen

SSH Communications Security Corp

Valimotie 17

00380 Helsinki

Finland

EMail: sjl@ssh.com

Chris Lonvick (редактор)

Cisco Systems, Inc.

12515 Research Blvd.

Austin 78759

USA

EMail: clonvick@cisco.com

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

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

nmalykh@gmail.com

Торговые марки

ssh – торговый знак, зарегистрированный в США и/или других странах.

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

Network Working Group                                    D. Eastlake 3rd
Request for Comments: 4343                         Motorola Laboratories
Updates: 1034, 1035, 2181                                   January 2006
Category: Standards Track

Разъяснение вопроса о регистре символов в DNS

Domain Name System (DNS) Case Insensitivity Clarification

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

Система доменных имен DNS¹ не принимает во внимание регистр символов. В этом документе даны разъяснения этого вопроса и приведена четкая спецификация правил. Эти разъяснения обновляют RFC 1034, 1035 и 2181.

1. Введение

Система доменных имен (DNS) представляет собой глобальную иерархическую систему распределенных баз данных для адресов Internet, почтовых proxy-серверов и другой информации. Каждый узел в дереве DNS имеет имя, которое может включать метки [STD13, RFC1591, RFC2606], трактуемые независимо от регистра символов в них. В этом документе разъясняются вопросы независимости от регистра и вносятся обновления в RFC 1034, RFC 1035 [STD13] и [RFC2181].

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

2. Независимость от регистра меток DNS

Спецификация DNS была разработана в «эпоху [ASCII]». Предполагалось, что имена DNS будут выглядеть подобно именам хостов, правой половине почтовых адресов Internet (справа от символа @) или выражаться числами, как в пространстве имен in-addr.arpa. Например,

foo.example.net.
aol.com.
www.gnu.ai.mit.edu.

или

69.2.0.192.in-addr.arpa.

Чувствительные к регистру варианты [RFC3092] приведенных выше имен DNS будут иметь вид

Foo.ExamplE.net.
AOL.COM.
WWW.gnu.AI.mit.EDU.

или

69.2.0.192.in-ADDR.ARPA.

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

2.1. Представление «необычных» октетов в метках DNS

В первичных файлах [STD13] и другом контексте ASCII, чтение и запись в котором рассчитаны на участие человека, требуется использование специального escape-символа для точки (0x2E, «.») и всех символов, которые выходят за пределы диапазона 0x21 (!) — 0x7E (~). Иными словами, специальное представление требуется для символа с кодом 0x2E и всех символов с кодами из диапазонов 0x00 — 0x20 и 0x7F — 0xFF.

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

Такое же соглашение может использоваться для печатных символов ASCII, включая и сам символ \, который будет представляться в форме \092 или \\, а также символа точки (.), который будет представляться в форме \046 или \. Желательно избегать использования символа \ для квотирования сразу после кода непечатного символа ASCII во избежание сложностей при реализации.

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

2.2. Примеры меток с Escape-символами

Первый из приведенных ниже примеров включает метку с символами пробела и точкой, а во втором дана 5-октетная метка, в которой все биты второго октета равны 0, а все биты четвертого — 1.

Donald\032E\.\032Eastlake\0323rd.example.

и

a\000\\\255z.example.

3. Просмотр имен, типы меток и CLASS

В соответствии с изначальным устройством DNS сравнение при поиске имен в запросах DNS следует выполнять без учета регистра символов [STD13]. Т. е., поиск строки, символы которой представляются октетами из диапазона 0x41 — 0x5A (прописные буквы набора ASCII) должен давать такой же результат, как поиск для строки, содержащей символы с кодами из диапазона 0x61 — 0x7A (строчные буквы набора ASCII). Поиск строки с символом нижнего регистра ASCII должен давать такой же результат, как при поиске строки с соответствующим символом верхнего регистра ASCII².

Одним из способов реализации этого правила является вычитание значения 0x20 из всех октетов с кодами из диапазона 0x61 — 0x7A перед операцией сравнения. Такую операцию обычно называют приведением регистра (case folding), но реализация такого приведения не требовалась спецификацией. Отметим, что независимость от регистра в DNS не соответствует приведению регистра, заданному в стандартах [ISO-8859-1] и [ISO-8859-2]. Например, октеты 0xDD (\221) и 0xFD (\253) не соответствуют друг другу, хотя в другом контексте, они могут интерпретироваться, как буква «Y» в верхнем и нижнем регистре.

3.1. Исходные типы меток DNS

Метки DNS при кодировании для передачи, имеют связанный с ними тип. Исходная спецификация DNS [STD13] включала лишь два типа — метки ASCII размером от 0³ до 63 октетов и косвенные (или сжатые) метки, которые состоят из указателя смещения по отношению к имени, хранящемуся где-то в сообщении DNS представленном для передачи. Метки ASCII следуют соглашению о преобразовании регистра, описанному здесь, и, как отмечено выше, могут на практике содержать произвольные значения байтов. Косвенные метки, по сути, заменяются именами, на которые они указывают, и после этого трактуются в соответствии с описанными здесь правилами независимости от регистра.

3.2. Независимость от регистра меток расширенного типа

В [RFC2671] было введено расширение DNS в части поддержки дополнительных типов меток⁴.

Соглашение о независимости от регистра меток ASCII применимо только к ASCII-меткам, т. е., меткам типа 0x0 независимо от того, указаны они явно или косвенно.

3.3. Независимость от регистра значений CLASS

Как описано в [STD13] и [RFC2929], DNS использует для также классы (CLASS). Единственным повсеместно применяемым классом является IN (Internet).

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

4. Регистр символов на вводе и выводе

Хотя сравнение меток ASCII не зависит от регистра символов, в [STD13] сказано, что регистр символов меток должен сохраняться при выводе и, по возможности, при вводе. Однако это требование не столь жестко, как может показаться, поскольку сохранение регистра при выводе не требуется, когда выходная информация оптимизируется за счет использования косвенных меток, как описано ниже.

4.1. Сохранение регистра на выходе DNS

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

4.2. Сохранение регистра на вводе DNS

Исходные данные DNS берутся из первичного файла ASCII, как определено в [STD13], или получаются в результате переноса зоны. Динамическое обновление DNS и инкрементальный перенос зон [RFC1995] были позднее добавлены [RFC2136, RFC3007] в качестве дополнительных источников данных DNS. При создании дерева имен DNS любым из этих способов преобразования регистра символов не происходит. Таким образом, все метки ASCII сохраняют регистр символов, если эти метки созданы для узлов. Однако если имя метки является входной информацией для узла, который уже существует в данных DNS, ситуация усложняется. Реализация может сохранить регистр символов первоначально загруженной метки, чтобы позволить при новом вводе изменить регистр, или поддерживать раздельные копии с сохранением исходного регистра.

Например, если загружаются данные с именем владельца foo.bar.example [RFC3092], а позднее вводятся данные с именем владельца xyz.BAR.example, имя метки узла bar.example (т. е., bar) может быть заменено на BAR в сохраняемых в DNS данных. Таким образом, при последующем поиске данных, сохраненных для xyz.bar.example, во всех возвращаемых данных может указываться метка xyz.BAR.example или xyz.bar.example, а также при возврате более одной записи RR могут указываться оба варианта вперемешку. Последний вариант маловероятен, поскольку оптимизация размера отклика за счет использования косвенных меток приводит к использованию одного варианта «хвоста» метки (bar.example или BAR.example) для всех возвращаемых RR. Отметим, что это не оказывает никакого влияния на число и полноту возвращаемого набора RR и может воздействовать лишь на регистр символов в именах.

Такие же соображения применимы и для случаев ввода множества записей, в которых имена владельцев отличаются лишь регистром символов. Например, если одна запись A является первой записью, сохраненной с именем владельца xyz.BAR.example, а вторая запись A сохраняется с именем владельца XYZ.BAR.example, вторая запись может быть сохранена с первым (строчные буквы) именем, может переписать первую с использованием прописных (заглавных) букв, а могут быть сохранены оба варианта в данных DNS. В любом случае при поиске данных будут возвращаться все RR, независимо от регистра символов в запросе.

Отметим, что порядок вставки в базу данных сервера имен узлов дерева DNS из первичного файла (Master File) не определен, поэтому несогласованное использование регистра символов в Master File ведет к непредсказуемому регистру символов на выходе.

5. Доменные имена на других языках

Схема была адаптирована для доменных имен на других языках (internationalized domain name и internationalized label), как описано в [RFC3490, RFC3454, RFC3491, RFC3492]. Это делает доступной большую часть символов [UNICODE] с помощью отдельного преобразования из доменных имен на национальных языках в имена DNS и обратно. Чувствительность к регистру символов в именах доменов на национальных языках зависит от используемого преобразования и обрабатывается в соответствии с [RFC3454] и [RFC3491]. Это не относится к протоколам DNS, стандартизованным в STD 13.

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

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

Кроме того, доменные имена могут использоваться за пределами контекста DNS. Они могут применяться в качестве чувствительных к регистру символов индексов в некоторых базах данных или файловых системах. Возможна также интерпретация имен, как двоичных данных, в некоторых системах защиты целостности или аутентификации. Эти проблемы обычно решаются за счет использования стандартизованной или «канонической» формы меток DNS типа ASCII (т. е., приведения значений всех октетов символов ASCII в метках типа ASCII к верхнему или нижнему регистру). Пример канонической формы доменных имен (и канонического порядка их сортировки) приведен в разделе 6 [RFC4034]. См. также документ [RFC3597].

И, наконец, в DNS могут храниться имена, отличные от DNS, с ошибочным предположением о сохранении регистра символов в них. Например, хотя и достаточно редко, в системах с регистрочувствительной локальной (слева от @) частью адресов электронной почты попытка сохранить две записи RP⁵ [RFC1183], различающиеся только регистром символов, может приводить к неожиданным результатам, способным оказать влияние на безопасность. Это обусловлено тем, что весь адрес электронной почты, включая регистрочувствительную локальную часть, преобразуется в имя DNS с возможным изменением регистра некоторых символов, как было описано выше.

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

Благодарим Rob Austein, Olafur Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, Andreas Gustafsson, Andrew Main, Thomas Narten и Scott Seligman за их вклад в подготовку документа.

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

[ASCII] ANSI, «USA Standard Code for Information Interchange», X3.4, American National Standards Institute: New York, 1968.

[RFC1995] Ohta, M., «Incremental Zone Transfer in DNS», RFC 1995, August 1996.

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

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, September 2003.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.

[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.

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

[ISO-8859-1] International Standards Organization, Standard for Character Encodings, Latin-1.

[ISO-8859-2] International Standards Organization, Standard for Character Encodings, Latin-2.

[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, «New DNS RR Definitions», RFC 1183, October 1990.

[RFC1591] Postel, J., «Domain Name System Structure and Delegation», RFC 1591, March 1994.

[RFC2606] Eastlake 3rd, D. and A. Panitz, «Reserved Top Level DNS Names», BCP 32, RFC 2606, June 1999.

[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 2929, September 2000.

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC2673] Crawford, M., «Binary Labels in the Domain Name System», RFC 2673, August 1999.

[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, «Etymology of «Foo»», RFC 3092, 1 April 2001.

[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, «Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)», RFC 3363, August 2002.

[RFC3454] Hoffman, P. and M. Blanchet, «Preparation of Internationalized Strings («stringprep»)», RFC 3454, December 2002.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, March 2003.

[RFC3491] Hoffman, P. and M. Blanchet, «Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)», RFC 3491, March 2003.

[RFC3492] Costello, A., «Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)», RFC 3492, March 2003.

[UNICODE] The Unicode Consortium, «The Unicode Standard», <http://www.unicode.org/unicode/standard/standard.html>.

Адрес автора

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@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

Network Working Group                                           V. Popov
Request for Comments: 4357                                   I. Kurepkin
Category: Informational                                      S. Leontiev
                                                              CRYPTO-PRO
                                                            January 2006

Дополнительные криптографические алгоритмы для применения с алгоритмами ГОСТ 28147-89, ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94

Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

В этом документе описаны криптографические алгоритмы и параметры, дополняющие исходные спецификации ГОСТ — ГОСТ 28147-89, ГОСТ Р R 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94 для использования в приложениях Internet.

1. Введение

Российские криптографические стандарты, определяющие алгоритмы ГОСТ 28147-89 [GOST28147], ГОСТ Р 34.10-94 [GOSTR341094], ГОСТ Р 34.10-2001 [GOSTR341001] и ГОСТ Р 34.11-94 [GOSTR341194], содержат базовые сведения о работе этих алгоритмов, однако для эффективного применения алгоритмов нужны дополнительные спецификации (краткие технические описания алгоритмов на английском языке приведены в работе [Schneier95]).

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

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

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

Ниже перечислены используемые в документе операторы и функции:

| конкатенация;

~ битовый оператор отрицания (NOT);

^ оператор возведения в степень;

encryptECB(K, D) значение D, зашифрованное с использованием ключа K на основе алгоритма ГОСТ 28147-89 в режиме простой замены (ECB);

decryptECB(K, D) значение D, расшифрованное с использованием ключа K на основе алгоритма ГОСТ 28147-89 в режиме ECB;

encryptCFB(IV, K, D) значение D, зашифрованное на основе алгоритма ГОСТ 28147-89 в режиме гаммирования с обратной связью (64-bit CFB) с использованием ключа K и вектора инициализации IV;

encryptCNT(IV, K, D) значение D, зашифрованное на основе алгоритма ГОСТ 28147-89 в режиме гаммирования (counter) с использованием ключа K и вектора инициализации IV;

gostR3411(D) 256-битовое значение хэш-функции ГОСТ Р 34.11-94, используемой с нулевым вектором инициализации и параметром S-Box, определяемым id-GostR3411-94-CryptoProParamSet (см. параграф 11.2);

gost28147IMIT(IV, K, D) 32-битовый результат применения алгоритма ГОСТ 28147-89 в режиме имитовставки (MAC) к значению D с использованием ключа K и вектора инициализации IV; отметим, что стандарт задает использование алгоритма в этом режиме только с нулевым значением вектора инициализации.

При операциях преобразования ключей и векторов инициализации в байтовые массивы предполагается порядок байтов little-endian (от младшего к старшему).

2. Режимы и параметры шифров

В этом документе определены 4 параметра шифров, что позволит разработчикам приложений изменять операции шифрования. К числу этих параметров относятся режим шифрования, алгоритм усложнения ключей (key meshing), режим заполнения (padding mode) и S-блок (S-box¹).

[GOST28147] определяет для алгоритма ГОСТ 28147-89 только три режима шифрования: ECB (простая замена), CFB (гаммирование с обратной связью) и counter (гаммирование). В этом документе определен дополнительный режим шифрования — CBC.

При использовании ГОСТ 28147-89 для обработки больших объемов данных симметричные ключи следует защищать с помощью алгоритма усложнения ключей. Операции усложнения следует выполнять после обработки некоторого объема данных. В этом документе определен алгоритм усложнения ключей CryptoPro.

Режим шифрования, алгоритм усложнения ключей, режим заполнения и S-box являются параметрами алгоритма.

2.1. Режим CBC в ГОСТ 28147-89

В этом параграфе приведена дополнительная информация о ГОСТ 28147-89 (примитив «блок-блок»), требующаяся для работы в режиме CBC.

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

2.2. Режимы заполнения ГОСТ 28147-89

В этом параграфе приведена дополнительная информация о ГОСТ 28147-89, требуемая для работы с данными, размер которых не кратен размеру блока ГОСТ 28147-89 (8 байтов).

Предположим, что x (0 < x <= 8) указывает число байтов в последнем (возможно, неполном) блоке данных.

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

• заполнение нулями: 8-x оставшихся байтов заполняются нулями;

• заполнение PKCS#5: 8-x оставшихся байтов заполняются значением 8-x (при отсутствии неполных блоков один дополнительный блок будет заполняться значением 8);

• случайное заполнение: 8-x оставшихся байтов заполняются случайными значениями.

2.3. Алгоритмы усложнения ключей

Алгоритмы усложнения ключей (Key Meshing) преобразуют ключ шифрования после обработки некоторого объема данных. В приложениях, где требуется высокий уровень устойчивости к атакам на основе анализа синхронизации и EMI, не следует применять один и тот же симметричный ключ для шифрования данных в объеме более 1024 октетов.

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

Все наборы параметров шифрования, определенные в данном документе, задают применение алгоритма усложнения ключа CryptoPro. Единственным исключением является набор id-Gost28147-89-TestParamSet, для которого задано применение пустого алгоритма усложнения ключа.

2.3.1. Пустой алгоритм

Пустой алгоритм усложнения (Null Key Meshing) не вносит в ключ каких-либо изменений.

Идентификатор этого алгоритма имеет вид:

       id-Gost28147-89-None-KeyMeshing OBJECT IDENTIFIER ::=
           { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)keyMeshing(14) none(0) }

Данный алгоритм не имеет значимых параметров. При наличии поля AlgorithmIdentifier.parameters оно должно содержать значение NULL.

2.3.2. Алгоритм усложнения ключей CryptoPro

Алгоритм усложнения ключей CryptoPro преобразует ключ и вектор инициализации после шифрования каждых 1024 октетов (8192 бита или 256 блоков по 64 бита) данных.

Этому алгоритму присущ тот же недостаток, что и режиму шифрования OFB — невозможно восстановить крипто-синхронизацию при расшифровке, если часть зашифрованных данных утеряна, повреждена или обработана с нарушением порядка следования. Более того, восстановление синхронизации невозможно даже при явном предоставлении вектора инициализации IV для каждого пакета. При использовании этого алгоритма в протоколах типа ESP требует принятия специальных мер.

Идентификатор алгоритма имеет вид:

       id-Gost28147-89-CryptoPro-KeyMeshing  OBJECT IDENTIFIER ::=
           { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) keyMeshing(14) cryptoPro(1) }

Алгоритм не имеет значимых параметров. При наличии поля AlgorithmIdentifier.parameters оно должно иметь значение NULL.

Алгоритм ГОСТ 28147-89 в режиме шифрования, дешифрования или имитовставки (MAC) начинает работу с ключом K[0] = K, IV0[0] = IV, i = 0. IVn[0] будет обозначать вектор инициализации после обработки первых 1024 октетов данных.

Обработка следующих 1024 октетов будет начинаться с K[1] и IV0[1], рассчитываемых по формулам:

       K[i+1] = decryptECB (K[i], C);
       IV0[i+1] = encryptECB (K[i+1],IVn[i])

Где C = {0x69, 0x00, 0x72, 0x22, 0x64, 0xC9, 0x04, 0x23, 0x8D, 0x3A, 0xDB, 0x96, 0x46, 0xE9, 0x2A, 0xC4, 0x18, 0xFE, 0xAC, 0x94, 0x00, 0xED, 0x07, 0x12, 0xC0, 0x86, 0xDC, 0xC2, 0xEF, 0x4C, 0xA9, 0x2B}.

После обработки каждых 1024 октетов данных:

• результирующий вектор инициализации сохраняется, как IVn[i];

• рассчитываются значения K[i+1] и IV0[i+1];

• инкрементируется значение i;

• шифруются следующие 1024 байта с использованием нового ключа и IV.

Процесс повторяется до завершения обработки всех данных.

3. HMAC_GOSTR3411

Функция HMAC_GOSTR3411(K, text) основана на хэш-функции ГОСТ Р 34.11-94, как определено в [HMAC], со значениями параметров

   B = 32, L = 32

4. PRF_GOSTR3411

PRF_GOSTR3411 — псевдослучайная функция на основе HMAC_GOSTR3411. Она вычисляется, как P_hash (см. параграф 5 работы [TLS]).

PRF_GOSTR3411(secret,label,seed) = P_GOSTR3411 (secret,label|seed).

5. Алгоритмы создания ключей

Стандарты [GOSTR341094] и [GOSTR341001] не определяют алгоритмов диверсификации ключей.

В параграфе 5.1 описан алгоритм VKO ГОСТ Р 34.10-94, который обеспечивает генерацию ГОСТ KEK с использованием двух ключевых пар ГОСТ Р 34.10-94.

В параграфе 5.2 описан алгоритм VKO ГОСТ Р 34.10-2001, который обеспечивает генерацию ГОСТ KEK с использованием двух ключевых пар ГОСТ Р 34.10-2001 и пользовательского ключевого материала UKM².

Ключевые пары должны иметь идентичные параметры.

5.1. VKO ГОСТ Р 34.10-94

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

Обменный ключ KEK представляет собой 256-битовое хэш-значение для 1024-битового разделяемого секрета (shared secret), генерируемое с использованием механизма согласования ключей Diffie-Hellman.

1. Пусть K(x,y) = a^(x*y) (mod p), где

   x — секретный ключ отправителя, a^x — открытый ключ отправителя,

   y — секретный ключ получателя, a^y — открытый ключ получателя,

   a, p — параметры.

2. 256-битовое хэш-значение для K(x,y) рассчитывается, как:

   KEK(x,y) = gostR3411 (K(x,y))

Ключевые пары (x,a^x) и (y,a^y) должны соответствовать требованиям [GOSTR341094].

Это алгоритм недопустимо применять в случаях, когда a^x = a (mod p) или a^y = a (mod p).

5.2. VKO ГОСТ Р 34.10-2001

Этот алгоритм позволяет создавать ключ шифрования ключей (KEK) с использованием 64-битового значения UKM, секретного ключа отправителя и открытого ключа получателя (или с обратным вариантом ключей).

1. Пусть K(x,y,UKM) = ((UKM*x)(mod q)).(y.P) (512 битов), где

   x — секретный ключ отправителя (256 битов),

   x.P — открытый ключ отправителя (512 битов),

   y — секретный ключ получателя (256 битов),

   y.P — открытый ключ получателя (512 битов),

   UKM — отличное от 0 целое число, получаемое на этапе 2 в п. 6.1 [GOSTR341001],

   P — базовая точка эллиптической кривой (две 256-битовых координаты),

   UKM*x — целое значение произведения x и UKM,

   x.P — точка кратности.

2. Рассчитывается 256-битовое хэш-значение (x,y,UKM)

   KEK(x,y,UKM) = gostR3411 (K(x,y,UKM))

Ключевые пары (x,x.P) и (y,y.P) MUST соответствуют [GOSTR341001].

Этот алгоритм недопустимо применять в тех случаях, когда x.P = P, y.P = P

6. Алгоритмы экспорта ключей

Этот документ определяет два алгоритма экспорта ключей (key wrap) — ГОСТ 28147-89 и CryptoPro. Эти алгоритмы применяются с ключами шифрования содержимого (CEK³) и ключами шифрования ключей (KEK⁴).

6.1. Экспорт ключа ГОСТ 28147-89

Этот алгоритм шифрует ключ ГОСТ 28147-89 CEK с использованием ключа ГОСТ 28147-89 KEK.

Примечание. Этот алгоритм недопустимо использовать с ключами KEK, созданными с помощью VKO ГОСТ Р 34.10-94, поскольку в этом случае значение KEK будет постоянным для каждой пары «отправитель — получатель». Шифрование множества разных ключей шифрования содержимого с использованием одного ключа KEK может приводить к раскрытию этого ключа KEK.

Процесс экспорта ключа ГОСТ 28147-89 состоит из перечисленных ниже этапов.

1. Для уникального симметричного ключа KEK генерируется 8 случайных октетов, которые обозначены UKM. Для KEK, согласованного с помощью VKO ГОСТ Р 34.10-2001, в качестве UKM служит ключевой материал, применявшийся при создании ключа.

2. Рассчитывается 4-байтовое значение контрольной суммы⁵ gost28147IMIT(UKM, KEK, CEK), обозначенное CEK_MAC.

3. Ключ CEK шифруется в режиме ECB с использованием ключа KEK, давая в результате CEK_ENC.

4. Экспортным представлением ключа шифрования содержимого служит конкатенация (UKM | CEK_ENC | CEK_MAC).

6.2. Импорт ключа ГОСТ 28147-89

Этот алгоритм расшифровывает ключ ГОСТ 28147-89 CEK зашифрованный с помощью ключа ГОСТ 28147-89 KEK. Процесс импорта ключа ГОСТ 28147-89 состоит из перечисленных ниже этапов.

1. Если размер экспортированного ключа шифрования содержимого отличается от 44, генерируется сигнал ошибки.

2. Экспортированный ключ шифрования содержимого разбивается на блоки UKM, CEK_ENC и CEK_MAC. UKM включает 8 старших (первых) 8 октетов, CEK_ENC — 32 следующих октета и CEK_MAC младшие (последние) 4 октета.

3. Значение CEK_ENC расшифровывается с использованием ключа KEK в режиме ECB. Результат обозначен CEK.

4. Рассчитывается 4-байтовое значение контрольной суммы gost28147IMIT(UKM, KEK, CEK) и сравнивается с CEK_MAC. При несовпадении генерируется сигнал ошибки.

6.3. Экспорт ключа CryptoPro

Этот алгоритм шифрует ключ ГОСТ 28147-89 CEK с использованием ключа ГОСТ 28147-89 KEK. Алгоритм может применяться с любым ключом KEK (например, созданным с помощью VKO ГОСТ Р 34.10-94 или VKO ГОСТ Р 34.10-2001) поскольку в нем применяется уникальное значение UKM для диверсификации KEK.

Экспорт ключа CryptoPro состоит из перечисленных ниже этапов.

1. Для уникального симметричного ключа KEK или ключа KEK, согласованного с использованием VKO ГОСТ Р 34.10-94, генерируется 8 октетов случайных данных, которые обозначены UKM. Для KEK, согласованного с помощью VKO ГОСТ Р 34.10-2001, в качестве UKM служит ключевой материал, применявшийся при создании ключа.

2. Выполняется диверсификация KEK, с использованием алгоритма CryptoPro, описанного в параграфе 6.5. Результат диверсификации обозначен KEK(UKM).

3. Рассчитывается 4-байтовое значение контрольной суммы gost28147IMIT(UKM, KEK, CEK), обозначенное CEK_MAC.

4. Ключ CEK шифруется в режиме ECB с использованием ключа KEK(UKM), давая в результате CEK_ENC.

5. Экспортным представлением ключа шифрования содержимого служит конкатенация (UKM | CEK_ENC | CEK_MAC).

6.4. Импорт ключа CryptoPro

Этот алгоритм расшифровывает ключ ГОСТ 28147-89 CEK с использованием ключа ГОСТ 28147-89 KEK. Импорт ключа CryptoPro состоит из перечисленных ниже этапов.

1. Если размер экспортированного ключа шифрования содержимого отличается от 44, генерируется сигнал ошибки.

2. Экспортированный ключ шифрования содержимого разбивается на блоки UKM, CEK_ENC и CEK_MAC. UKM включает 8 старших (первых) 8 октетов, CEK_ENC — 32 следующих октета и CEK_MAC младшие (последние) 4 октета.

3. Выполняется диверсификация KEK, с использованием алгоритма CryptoPro, описанного в параграфе 6.5. Результат диверсификации обозначен KEK(UKM).

4. Значение CEK_ENC расшифровывается с использованием ключа KEK(UKM). Результат обозначен CEK.

5. Рассчитывается 4-байтовое значение контрольной суммы gost28147IMIT(UKM, KEK, CEK) и сравнивается с CEK_MAC. При несовпадении генерируется сигнал ошибки.

6.5. Алгоритм диверсификации KEK CryptoPro

На основе 64-битового значения UKM и ключа ГОСТ 28147-89, обозначенного K этот алгоритм создает новый ключ ГОСТ 28147-89, обозначенный K(UKM). Процедура диверсификации показана ниже.

1. Пусть K[0] = K;

2. Ключевой материал UKM делится на компоненты a[i,j] так, что

   UKM = a[0]|..|a[7]

   где индекс указывает номер байта, а j – номер бита в байте.

3. Пусть i = 0.

4. Рассчитываются значения K[1]..K[8] путем 8-кратного повторения показанных ниже операций

   1. K[i] делится на компоненты k[i,j] так, что

      K[i] = k[i,0] | k[i,1] | .. | k[i,7]

      каждая из компонент k[i,j] представляет собой 32-битовое целое число;

   2. Рассчитывается вектор S[i]

      S[i] = ((a[i,0] * k[i,0] + ... + a[i,7] * k[i,7]) mod 232) | (((~a[i,0]) * k[i,0] + ... + (~a[i,7]) * k[i,7]) mod 2232 );

   3. K[i+1] = encryptCFB (S[i], K[i], K[i]);

   4. i = i + 1:

5. K(UKM) принимается равным K[8].

7. Диверсификация секретного ключа

Этот алгоритм создает ключ ГОСТ 28147-89, обозначенный Kd, на основе секретного ключа K размером 256 битов и данных диверсификации D, размером от 4 до 40 байтов⁶.

1. Создается 40-байтовый блок данных B на основе D путем его клонирования нужное число раз и конкатенации для получения в результате 40 байтов. Например, для D размером 40 байтов B будет равно D, для D размером 6 байтов B = D | D | D | D | D | D | D[0..3].

2. B разбивается на 8-байтовое значение UKM и 32-байтовое значение SRCKEY (B = UKM|SRCKEY).

3. для создания K(UKM) из ключа K и значения UKM используется алгоритм, описанный в параграфе 6.5, с двумя отличиями

   • вместо S[i] применяется вектор (0, 0, 0, UKM[i], ff, ff, ff, ff XOR UKM[i]);

1. • на каждом этапе шифрования выполняется только 8 раундов алгоритма ГОСТ 28147-89 из полных 32.

4. Kd рассчитывается по формуле

   Kd = encryptCFB (UKM, K(UKM), SRCKEY).

8. Параметры алгоритмов

Стандарты [GOST28147], [GOST341194], [GOSTR341094] и [GOSTR341001] не определяют конкретных значений параметров алгоритмов.

В этом документе вводится использование идентификаторов объектов ASN.1 OID⁷ для задания параметров алгоритма.

Идентификаторы для всех предлагаемых наборов параметров приведены в разделе 10, соответствующие значения параметров — в разделе 11.

8.1. Параметры алгоритма шифрования

Алгоритм ГОСТ 28147-89 можно использовать в нескольких режимах, в параграфе 2.1 определен дополнительный режим CBC. Он также использует параметр S-Box (параметры алгоритма описаны в [GOST28147] на русском языке, а английское описание имеется в работе [Schneier95], на стр. 331).

Ниже приведен список предложенных наборов параметров для алгоритма ГОСТ 28147-89.

Gost28147-89-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= {
    { Gost28147-89-ParamSetParameters IDENTIFIED BY id-Gost28147-89-TestParamSet  } |
    { Gost28147-89-ParamSetParameters IDENTIFIED BY id-Gost28147-89-CryptoPro-A-ParamSet  } |
    { Gost28147-89-ParamSetParameters IDENTIFIED BY id-Gost28147-89-CryptoPro-B-ParamSet  } |
    { Gost28147-89-ParamSetParameters IDENTIFIED BY id-Gost28147-89-CryptoPro-C-ParamSet  } |
    { Gost28147-89-ParamSetParameters IDENTIFIED BY id-Gost28147-89-CryptoPro-D-ParamSet  }
}

Значения идентификаторов описаны в разделе 10, а соответствующие параметры — в параграфе 11.1.

Параметры для алгоритма ГОСТ 28147-89 представлены ниже.

    Gost28147-89-ParamSetParameters ::= SEQUENCE {
        eUZ          Gost28147-89-UZ,
        mode         INTEGER {
                         gost28147-89-CNT(0),
                         gost28147-89-CFB(1),
                         cryptoPro-CBC(2)
                     },
        shiftBits    INTEGER { gost28147-89-block(64) },
        keyMeshing   AlgorithmIdentifier
    }
    Gost28147-89-UZ ::= OCTET STRING (SIZE (64))
    Gost28147-89-KeyMeshingAlgorithms  ALGORITHM-IDENTIFIER ::= {
        { NULL IDENTIFIED BY id-Gost28147-89-CryptoPro-KeyMeshing } |
        { NULL IDENTIFIED BY id-Gost28147-89-None-KeyMeshing }
    }

где

eUZ — значение S-box;

mode — режим шифра;

shiftBits — параметр шифра;

keyMeshing — идентификатор алгоритма усложнения ключа.

8.2. Параметры алгоритма цифровой подписи

Ниже представлен список предложенных наборов параметров для [GOST341194].

    GostR3411-94-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= {
        { GostR3411-94-ParamSetParameters IDENTIFIED BY id-GostR3411-94-TestParamSet } |
        { GostR3411-94-ParamSetParameters IDENTIFIED BY id-GostR3411-94-CryptoProParamSet }
    }

Значения идентификаторов описаны в разделе 10, а соответствующие параметры — в параграфе 11.2.

Параметры для [GOST341194] представлены ниже.

    GostR3411-94-ParamSetParameters ::=
        SEQUENCE {
            hUZ Gost28147-89-UZ,    -- S-Box для дайджеста (отпечатка)
            h0  GostR3411-94-Digest — начальное значение дайджеста
        }
    GostR3411-94-Digest ::= OCTET STRING (SIZE (32))

8.3. Параметры алгоритма с открытым ключом ГОСТ Р 34.10-94

Ниже представлен список предложенных наборов параметров для ГОСТ Р 34.10-94.

    GostR3410-94-ParamSetAlgorithm ALGORITHM-IDENTIFIER ::= {
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-TestParamSet } |
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-CryptoPro-A-ParamSet  } |
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-CryptoPro-B-ParamSet  } |
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-CryptoPro-C-ParamSet  } |
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-CryptoPro-D-ParamSet  } |
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-CryptoPro-XchA-ParamSet  } |
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-CryptoPro-XchB-ParamSet  } |
        { GostR3410-94-ParamSetParameters IDENTIFIED BY
               id-GostR3410-94-CryptoPro-XchC-ParamSet  }
    }

Значения идентификаторов описаны в разделе 10, а соответствующие параметры — в параграфе 11.3.

Параметры для ГОСТ Р 34.10-94 представлены ниже.

    GostR3410-94-ParamSetParameters ::=
       SEQUENCE {
           t       INTEGER,
           p       INTEGER,
           q       INTEGER,
           a       INTEGER,
           validationAlgorithm   AlgorithmIdentifier {{
             GostR3410-94-ValidationAlgorithms
             }} OPTIONAL
       }

    GostR3410-94-ValidationParameters ::=
         SEQUENCE {
             x0      INTEGER,
             c       INTEGER,
             d       INTEGER OPTIONAL
         }

где

t — число битов p (512 или 1024);

p — модуль, простое число из диапазона 2^(t-1) < p < 2^t;

q — порядок циклической группы, простое число из диапазона 2²⁵⁴ < q < 2²⁵⁶, q является делителем p-1;

a — генератор, целое число из диапазона 1 < a < p-1, такое, что aq (mod p) = 1;

validationAlgorithm — алгоритм расчета значений констант p, q и a;

x0 — «затравка»;

c — используется для генерации значений p и q;

d — используется для генерации.

8.4. Параметры алгоритма с открытым ключом ГОСТ Р 34.10-2001

Ниже приведен список предлагаемых наборов параметров для ГОСТ Р 34.10-2001.

    GostR3410-2001-ParamSetAlgorithm ALGORITHM-IDENTIFIER ::= {
        { GostR3410-2001-ParamSetParameters IDENTIFIED BY
               id-GostR3410-2001-TestParamSet } |
        { GostR3410-2001-ParamSetParameters IDENTIFIED BY
               id-GostR3410-2001-CryptoPro-A-ParamSet  } |
        { GostR3410-2001-ParamSetParameters IDENTIFIED BY
               id-GostR3410-2001-CryptoPro-B-ParamSet  } |
        { GostR3410-2001-ParamSetParameters IDENTIFIED BY
               id-GostR3410-2001-CryptoPro-C-ParamSet  } |
        { GostR3410-2001-ParamSetParameters IDENTIFIED BY
               id-GostR3410-2001-CryptoPro-XchA-ParamSet  } |
        { GostR3410-2001-ParamSetParameters IDENTIFIED BY
               id-GostR3410-2001-CryptoPro-XchB-ParamSet  }
    }

Значения идентификаторов описаны в разделе 10, а соответствующие параметры — в параграфе 11.4.

Параметры для ГОСТ Р 34.10-2001 представлены ниже.

    GostR3410-2001-ParamSetParameters ::=
       SEQUENCE {
           a       INTEGER,
           b       INTEGER,
           p       INTEGER,
           q       INTEGER,
           x       INTEGER,
           y       INTEGER
       }

a, b — коэффициенты a и b эллиптической кривой E;

p — простое число, модуль эллиптической кривой;

q — простое число, порядок циклической группы;

x, y — координаты базовой точки p.

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

Программным приложениям рекомендуется проверять соответствие значений подписей и открытых ключей, а также параметров алгоритма стандартам [GOSTR341001] и [GOSTR341094] до начала использования.

Параметры криптографического алгоритма влияют на его строгость. Предложенные и описанные здесь наборы параметров, за исключением тестовых наборов (id-Gost28147-89-TestParamSet, id-GostR3411-94-TestParamSet, id-GostR3410-94-TestParamSet, id-GostR3410-2001-TestParamSet), были протестированы специальной сертификационной лабораторией НТЦ «Атлас» и Центром сертификации на соответствие уровням TOE⁸, согласно [RFDSL], [RFLLIC] и [CRYPTOLIC].

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

10. Модули ASN.1

10.1. Cryptographic-Gost-Useful-Definitions

   Cryptographic-Gost-Useful-Definitions
       { iso(1) member-body(2) ru(643) rans(2)
         cryptopro(2) other(1) modules(1)
         cryptographic-Gost-Useful-Definitions(0) 1 }

   DEFINITIONS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
     -- Ветвь Crypto-Pro OID
       id-CryptoPro OBJECT IDENTIFIER ::=
           { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) }
       id-CryptoPro-algorithms OBJECT IDENTIFIER ::= id-CryptoPro
       id-CryptoPro-modules OBJECT IDENTIFIER ::=
           { id-CryptoPro other(1) modules(1) }
       id-CryptoPro-hashes OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms hashes(30) }
       id-CryptoPro-encrypts OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms encrypts(31) }
       id-CryptoPro-signs OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms signs(32) }
       id-CryptoPro-exchanges OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms exchanges(33) }
       id-CryptoPro-extensions OBJECT IDENTIFIER ::=
           { id-CryptoPro extensions(34) }
       id-CryptoPro-ecc-signs OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms ecc-signs(35) }
       id-CryptoPro-ecc-exchanges OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms ecc-exchanges(36) }
       id-CryptoPro-private-keys OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms private-keys(37) }
       id-CryptoPro-policyIds OBJECT IDENTIFIER ::=
         { id-CryptoPro policyIds(38) }
       id-CryptoPro-policyQt OBJECT IDENTIFIER ::=
           { id-CryptoPro policyQt(39) }
       id-CryptoPro-pkixcmp-infos OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms pkixcmp-infos(41) }
       id-CryptoPro-audit-service-types OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms audit-service-types(42) }
       id-CryptoPro-audit-record-types OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms audit-record-types(43) }
       id-CryptoPro-attributes OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms attributes(44) }
       id-CryptoPro-name-service-types OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms name-service-types(45) }

     -- Модули ASN.1 российских криптографических стандартов ГОСТ и ГОСТ Р
       cryptographic-Gost-Useful-Definitions OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules cryptographic-Gost-Useful-Definitions(0) 1 }

     -- ГОСТ Р 34.11-94
       gostR3411-94-DigestSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gostR3411-94-DigestSyntax(1) 1 }
       gostR3411-94-ParamSetSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gostR3411-94-ParamSetSyntax(7) 1 }

     -- ГОСТ Р 34.10-94
       gostR3410-94-PKISyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules  gostR3410-94-PKISyntax(2) 1 }
       gostR3410-94-SignatureSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gostR3410-94-SignatureSyntax(3) 1 }
       gostR3410-EncryptionSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gostR3410-EncryptionSyntax(5) 2 }
       gostR3410-94-ParamSetSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules  gostR3410-94-ParamSetSyntax(8) 1 }

     -- ГОСТ Р 34.10-2001
       gostR3410-2001-PKISyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules  gostR3410-2001-PKISyntax(9) 1 }
       gostR3410-2001-SignatureSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gostR3410-2001-SignatureSyntax(10) 1 }
       gostR3410-2001-ParamSetSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gostR3410-2001-ParamSetSyntax(12) 1 }

     -- ГОСТ 28147-89
       gost28147-89-EncryptionSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost28147-89-EncryptionSyntax(4) 1 }
       gost28147-89-ParamSetSyntax OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost28147-89-ParamSetSyntax(6) 1 }

     -- Расширенное использование ключей для Crypto-Pro
       gost-CryptoPro-ExtendedKeyUsage OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost-CryptoPro-ExtendedKeyUsage(13) 1 }
     -- Секретные ключи Crypto-Pro
       gost-CryptoPro-PrivateKey OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost-CryptoPro-PrivateKey(14) 1 }

     -- Структуры Crypto-Pro PKIXCMP
       gost-CryptoPro-PKIXCMP OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost-CryptoPro-PKIXCMP(15) 1 }
     -- Структуры Crypto-Pro Transport Layer Security
       gost-CryptoPro-TLS OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost-CryptoPro-TLS(16) 1 }

     -- Политика Crypto-Pro
       gost-CryptoPro-Policy OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost-CryptoPro-Policy(17) 1 }
       gost-CryptoPro-Constants OBJECT IDENTIFIER ::=
           { id-CryptoPro-modules gost-CryptoPro-Constants(18) 1 }

     -- Полезные типы
       ALGORITHM-IDENTIFIER ::= CLASS {
           &id    OBJECT IDENTIFIER UNIQUE,
           &Type  OPTIONAL
       }
       WITH SYNTAX { [&Type] IDENTIFIED BY &id }
   END -- Cryptographic-Gost-Useful-Definitions

10.2. Gost28147-89-EncryptionSyntax

   Gost28147-89-EncryptionSyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gost28147-89-EncryptionSyntax(4) 1 }
   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           id-CryptoPro-algorithms, id-CryptoPro-encrypts,
           ALGORITHM-IDENTIFIER,
           cryptographic-Gost-Useful-Definitions
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
       ;
     -- ГОСТ 28147-89 OID
       id-Gost28147-89 OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms gost28147-89(21) }
       id-Gost28147-89-MAC OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms gost28147-89-MAC(22) }
     -- Значения OID для наборов криптографических параметров ГОСТ 28147-89
       id-Gost28147-89-TestParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-encrypts test(0) }
       id-Gost28147-89-CryptoPro-A-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-encrypts cryptopro-A(1) }
       id-Gost28147-89-CryptoPro-B-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-encrypts cryptopro-B(2) }
       id-Gost28147-89-CryptoPro-C-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-encrypts cryptopro-C(3) }
       id-Gost28147-89-CryptoPro-D-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-encrypts cryptopro-D(4) }
       id-Gost28147-89-CryptoPro-Oscar-1-1-ParamSet
         OBJECT IDENTIFIER ::= { id-CryptoPro-encrypts cryptopro-Oscar-1-1(5) }
       id-Gost28147-89-CryptoPro-Oscar-1-0-ParamSet
         OBJECT IDENTIFIER ::= { id-CryptoPro-encrypts cryptopro-Oscar-1-0(6) }
       id-Gost28147-89-CryptoPro-RIC-1-ParamSet
         OBJECT IDENTIFIER ::= { id-CryptoPro-encrypts cryptopro-RIC-1(7) }
     -- Типы ГОСТ 28147-89
       Gost28147-89-UZ ::= OCTET STRING (SIZE (64))
       Gost28147-89-IV ::= OCTET STRING (SIZE (8))
       Gost28147-89-Key ::= OCTET STRING (SIZE (32))
       Gost28147-89-MAC ::= OCTET STRING (SIZE (1..4))
       Gost28147-89-EncryptedKey ::=
           SEQUENCE {
               encryptedKey Gost28147-89-Key,
               maskKey      [0] IMPLICIT Gost28147-89-Key OPTIONAL,
               macKey       Gost28147-89-MAC (SIZE (4))
           }
       Gost28147-89-ParamSet ::=
           OBJECT IDENTIFIER (
               id-Gost28147-89-TestParamSet |
                   -- Только для тестирования
               id-Gost28147-89-CryptoPro-A-ParamSet |
               id-Gost28147-89-CryptoPro-B-ParamSet |
               id-Gost28147-89-CryptoPro-C-ParamSet |
               id-Gost28147-89-CryptoPro-D-ParamSet |
               id-Gost28147-89-CryptoPro-Oscar-1-1-ParamSet |
               id-Gost28147-89-CryptoPro-Oscar-1-0-ParamSet |
               id-Gost28147-89-CryptoPro-RIC-1-ParamSet
           )
       Gost28147-89-BlobParameters ::=
           SEQUENCE {
               encryptionParamSet Gost28147-89-ParamSet,
               ...
           }
     -- Параметры алгоритма шифрования ГОСТ 28147-89 
       Gost28147-89-Parameters ::=
           SEQUENCE {
               iv                   Gost28147-89-IV,
               encryptionParamSet   Gost28147-89-ParamSet
           }
       Gost28147-89-Algorithms ALGORITHM-IDENTIFIER ::= {
           { Gost28147-89-Parameters IDENTIFIED BY
                           id-Gost28147-89 }
       }
   END -- Gost28147-89-EncryptionSyntax

10.3. Gost28147-89-ParamSetSyntax

   Gost28147-89-ParamSetSyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gost28147-89-ParamSetSyntax(6) 1 }
   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           id-CryptoPro-algorithms, id-CryptoPro-encrypts,
           gost28147-89-EncryptionSyntax, ALGORITHM-IDENTIFIER,
           cryptographic-Gost-Useful-Definitions
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
           Gost28147-89-UZ,
           Gost28147-89-ParamSet,
           id-Gost28147-89-TestParamSet,
           id-Gost28147-89-CryptoPro-A-ParamSet,
           id-Gost28147-89-CryptoPro-B-ParamSet,
           id-Gost28147-89-CryptoPro-C-ParamSet,
           id-Gost28147-89-CryptoPro-D-ParamSet
           FROM Gost28147-89-EncryptionSyntax
                gost28147-89-EncryptionSyntax
           AlgorithmIdentifier
           FROM PKIX1Explicit88 {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-explicit-88(1)}
       ;
     -- Наборы криптографических параметров ГОСТ 28147-89:
     -- Значения OID для параметров импортированы из Gost28147-89-EncryptionSyntax
     Gost28147-89-ParamSetParameters ::=
       SEQUENCE {
           eUZ             Gost28147-89-UZ,
           mode            INTEGER {
                               gost28147-89-CNT(0),
                               gost28147-89-CFB(1),
                               cryptoPro-CBC(2)
                           },
           shiftBits       INTEGER { gost28147-89-block(64) },
           keyMeshing      AlgorithmIdentifier
       }
     Gost28147-89-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= {
       { Gost28147-89-ParamSetParameters IDENTIFIED BY
                   id-Gost28147-89-TestParamSet  } |
       { Gost28147-89-ParamSetParameters IDENTIFIED BY
                   id-Gost28147-89-CryptoPro-A-ParamSet  } |
       { Gost28147-89-ParamSetParameters IDENTIFIED BY
                   id-Gost28147-89-CryptoPro-B-ParamSet  } |
       { Gost28147-89-ParamSetParameters IDENTIFIED BY
                   id-Gost28147-89-CryptoPro-C-ParamSet  } |
       { Gost28147-89-ParamSetParameters IDENTIFIED BY
                   id-Gost28147-89-CryptoPro-D-ParamSet  }
     }
     id-Gost28147-89-CryptoPro-KeyMeshing  OBJECT IDENTIFIER ::=
       { id-CryptoPro-algorithms keyMeshing(14) cryptoPro(1) }
     id-Gost28147-89-None-KeyMeshing OBJECT IDENTIFIER ::=
       { id-CryptoPro-algorithms keyMeshing(14) none(0) }
     Gost28147-89-KeyMeshingAlgorithms  ALGORITHM-IDENTIFIER ::= {
       { NULL IDENTIFIED BY id-Gost28147-89-CryptoPro-KeyMeshing } |
       { NULL IDENTIFIED BY id-Gost28147-89-None-KeyMeshing }
     }
   END -- Gost28147-89-ParamSetSyntax

10.4. GostR3411-94-DigestSyntax

   GostR3411-94-DigestSyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gostR3411-94-DigestSyntax(1) 1 }
   DEFINITIONS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           id-CryptoPro-algorithms, id-CryptoPro-hashes,
           ALGORITHM-IDENTIFIER,
           cryptographic-Gost-Useful-Definitions
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
       ;
     -- ГОСТ Р 34.11-94 OID
       id-GostR3411-94 OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms gostR3411-94(9) }
     -- Значения OID набора криптографических параметров ГОСТ Р 34.11-94
       id-GostR3411-94-TestParamSet OBJECT IDENTIFIER ::= { id-CryptoPro-hashes test(0) }
       id-GostR3411-94-CryptoProParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-hashes cryptopro(1) }
     -- Типы данных ГОСТ Р 34.11-94 
       GostR3411-94-Digest ::= OCTET STRING (SIZE (32))
     -- Алгоритм цифровой подписи ГОСТ Р 34.11-94 и его параметры
       GostR3411-94-DigestParameters ::=
           OBJECT IDENTIFIER (
                   id-GostR3411-94-TestParamSet |
                       -- Только для целей тестирования
                   id-GostR3411-94-CryptoProParamSet
           )
       GostR3411-94-DigestAlgorithms ALGORITHM-IDENTIFIER ::= {
           { NULL IDENTIFIED BY id-GostR3411-94 } |
                   -- Предполагается id-GostR3411-94-CryptoProParamSet
           { GostR3411-94-DigestParameters IDENTIFIED BY id-GostR3411-94 }
       }
   END -- GostR3411-94-DigestSyntax

10.5. GostR3411-94-ParamSetSyntax

   GostR3411-94-ParamSetSyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gostR3411-94-ParamSetSyntax(7) 1 }
   DEFINITIONS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           gost28147-89-EncryptionSyntax,
           gostR3411-94-DigestSyntax,
           ALGORITHM-IDENTIFIER
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
           Gost28147-89-UZ
           FROM Gost28147-89-EncryptionSyntax
                gost28147-89-EncryptionSyntax
           id-GostR3411-94-TestParamSet,
           id-GostR3411-94-CryptoProParamSet,
           GostR3411-94-Digest
           FROM GostR3411-94-DigestSyntax
                gostR3411-94-DigestSyntax
       ;
     -- Наборы криптографических параметров ГОСТ Р 34.11-94:
     -- Значения OID для наборов параметров импортированы из GostR3411-94-DigestSyntax
       GostR3411-94-ParamSetParameters ::=
           SEQUENCE {
               hUZ Gost28147-89-UZ,    -- S-блок для подписи
               h0  GostR3411-94-Digest -- начальное значение подписи
           }
       GostR3411-94-ParamSetAlgorithms ALGORITHM-IDENTIFIER ::= {
           { GostR3411-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3411-94-TestParamSet
           } |
           { GostR3411-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3411-94-CryptoProParamSet
           }
       }
   END -- GostR3411-94-ParamSetSyntax

10.6. GostR3410-94-PKISyntax

   GostR3410-94-PKISyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gostR3410-94-PKISyntax(2) 1 }
   DEFINITIONS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           id-CryptoPro-algorithms,
           id-CryptoPro-signs, id-CryptoPro-exchanges,
           gost28147-89-EncryptionSyntax,
           gostR3411-94-DigestSyntax, ALGORITHM-IDENTIFIER,
           cryptographic-Gost-Useful-Definitions
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
           Gost28147-89-ParamSet
           FROM Gost28147-89-EncryptionSyntax
                gost28147-89-EncryptionSyntax
           id-GostR3411-94-TestParamSet,
           id-GostR3411-94-CryptoProParamSet
           FROM GostR3411-94-DigestSyntax gostR3411-94-DigestSyntax
       ;
     -- Значения OID для ГОСТ Р 34.10-94 
       id-GostR3410-94 OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms gostR3410-94(20) }
       id-GostR3410-94DH OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms gostR3410-94DH(99) }
       id-GostR3411-94-with-GostR3410-94 OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms
             gostR3411-94-with-gostR3410-94(4) }
     -- Значения OID для набора параметров открытого ключа ГОСТ Р 34.10-94
       id-GostR3410-94-TestParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-signs test(0) }
       id-GostR3410-94-CryptoPro-A-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-signs cryptopro-A(2) }
       id-GostR3410-94-CryptoPro-B-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-signs cryptopro-B(3) }
       id-GostR3410-94-CryptoPro-C-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-signs cryptopro-C(4) }
       id-GostR3410-94-CryptoPro-D-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-signs cryptopro-D(5) }
       id-GostR3410-94-CryptoPro-XchA-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-exchanges cryptopro-XchA(1) }
       id-GostR3410-94-CryptoPro-XchB-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-exchanges cryptopro-XchB(2) }
       id-GostR3410-94-CryptoPro-XchC-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-exchanges cryptopro-XchC(3) }
     -- Типы данных ГОСТ Р 34.10-94
       GostR3410-94-CertificateSignature ::=
           BIT STRING ( SIZE(256..512) )
       GostR3410-94-PublicKey ::=
           OCTET STRING ( SIZE(
                           64 |    -- Только для целей тестирования
                           128
                           ) )
       GostR3410-94-PublicKeyParameters ::=
           SEQUENCE {
               publicKeyParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3410-94-TestParamSet |
                           -- Только для тестирования
                       id-GostR3410-94-CryptoPro-A-ParamSet |
                       id-GostR3410-94-CryptoPro-B-ParamSet |
                       id-GostR3410-94-CryptoPro-C-ParamSet |
                       id-GostR3410-94-CryptoPro-D-ParamSet |
                       id-GostR3410-94-CryptoPro-XchA-ParamSet |
                       id-GostR3410-94-CryptoPro-XchB-ParamSet |
                       id-GostR3410-94-CryptoPro-XchC-ParamSet
                   ),
               digestParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3411-94-TestParamSet |
                           -- Только для целей тестирования
                       id-GostR3411-94-CryptoProParamSet
                   ),
               encryptionParamSet Gost28147-89-ParamSet OPTIONAL
           }
       GostR3410-94-PublicKeyAlgorithms  ALGORITHM-IDENTIFIER ::= {
           { GostR3410-94-PublicKeyParameters IDENTIFIED BY
                           id-GostR3410-94 }
       }
   END -- GostR3410-94-PKISyntax

10.7. GostR3410-94-ParamSetSyntax

   GostR3410-94-ParamSetSyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gostR3410-94-ParamSetSyntax(8) 1 }
   DEFINITIONS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           id-CryptoPro-algorithms,
           id-CryptoPro-signs, id-CryptoPro-exchanges,
           gostR3410-94-PKISyntax, ALGORITHM-IDENTIFIER,
           cryptographic-Gost-Useful-Definitions
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
           id-GostR3410-94,
           id-GostR3410-94-TestParamSet,
           id-GostR3410-94-CryptoPro-A-ParamSet,
           id-GostR3410-94-CryptoPro-B-ParamSet,
           id-GostR3410-94-CryptoPro-C-ParamSet,
           id-GostR3410-94-CryptoPro-D-ParamSet,
           id-GostR3410-94-CryptoPro-XchA-ParamSet,
           id-GostR3410-94-CryptoPro-XchB-ParamSet,
           id-GostR3410-94-CryptoPro-XchC-ParamSet
           FROM GostR3410-94-PKISyntax gostR3410-94-PKISyntax
           AlgorithmIdentifier
           FROM PKIX1Explicit88 {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-pkix1-explicit-88(1)}
       ;
     -- Наборы параметров открытых ключей ГОСТ Р 34.10-94:
     -- Значения OID для наборов параметров импортированы из GostR3410-94-PKISyntax
       GostR3410-94-ParamSetParameters-t ::= INTEGER (512 | 1024)
                   -- 512 - только для целей тестирования
       GostR3410-94-ParamSetParameters ::=
           SEQUENCE {
               t GostR3410-94-ParamSetParameters-t,
               p INTEGER,  -- 2^1020 < p < 2^1024 or 2^509 < p < 2^512
               q INTEGER,  --  2^254 < q < 2^256
               a INTEGER,  --      1 < a < p-1 < 2^1024-1
               validationAlgorithm
                   AlgorithmIdentifier OPTIONAL
                   -- {{ GostR3410-94-ValidationAlgorithms }}
           }
       GostR3410-94-ParamSetAlgorithm ALGORITHM-IDENTIFIER ::= {
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-TestParamSet } |
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-CryptoPro-A-ParamSet  } |
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-CryptoPro-B-ParamSet  } |
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-CryptoPro-C-ParamSet  } |
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-CryptoPro-D-ParamSet  } |
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-CryptoPro-XchA-ParamSet  } |
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-CryptoPro-XchB-ParamSet  } |
           { GostR3410-94-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-94-CryptoPro-XchC-ParamSet  }
       }
     -- ГОСТ Р 34.10-94 проверка/создание
       id-GostR3410-94-a           OBJECT IDENTIFIER ::=
           { id-GostR3410-94 a(1) }
       id-GostR3410-94-aBis        OBJECT IDENTIFIER ::=
           { id-GostR3410-94 aBis(2) }
       id-GostR3410-94-b           OBJECT IDENTIFIER ::=
           { id-GostR3410-94 b(3) }
       id-GostR3410-94-bBis        OBJECT IDENTIFIER ::=
           { id-GostR3410-94 bBis(4) }
       GostR3410-94-ValidationParameters-c ::=
           INTEGER (0 ..  65535)
       GostR3410-94-ValidationParameters ::=
           SEQUENCE {
               x0   GostR3410-94-ValidationParameters-c,
               c    GostR3410-94-ValidationParameters-c,
               d    INTEGER OPTIONAL -- 1 < d < p-1 < 2^1024-1

           }
       GostR3410-94-ValidationBisParameters-c ::=
           INTEGER (0 ..  4294967295)
       GostR3410-94-ValidationBisParameters ::=
           SEQUENCE {
               x0   GostR3410-94-ValidationBisParameters-c,
               c    GostR3410-94-ValidationBisParameters-c,
               d    INTEGER OPTIONAL -- 1 < d < p-1 < 2^1024-1

           }
       GostR3410-94-ValidationAlgorithms  ALGORITHM-IDENTIFIER ::= {
           { GostR3410-94-ValidationParameters IDENTIFIED BY
                 id-GostR3410-94-a } |
           { GostR3410-94-ValidationBisParameters IDENTIFIED BY
                           id-GostR3410-94-aBis } |
           { GostR3410-94-ValidationParameters IDENTIFIED BY
                           id-GostR3410-94-b } |
           { GostR3410-94-ValidationBisParameters IDENTIFIED BY
                           id-GostR3410-94-bBis }
       }
   END -- GostR3410-94-ParamSetSyntax

10.8. GostR3410-2001-PKISyntax

   GostR3410-2001-PKISyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gostR3410-2001-PKISyntax(9) 1 }
   DEFINITIONS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           id-CryptoPro-algorithms,
           id-CryptoPro-ecc-signs, id-CryptoPro-ecc-exchanges,
           gost28147-89-EncryptionSyntax,
           gostR3411-94-DigestSyntax, ALGORITHM-IDENTIFIER,
           cryptographic-Gost-Useful-Definitions
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
           Gost28147-89-ParamSet
           FROM Gost28147-89-EncryptionSyntax
                gost28147-89-EncryptionSyntax
           id-GostR3411-94-TestParamSet,
           id-GostR3411-94-CryptoProParamSet
           FROM GostR3411-94-DigestSyntax gostR3411-94-DigestSyntax
       ;
     -- Значения OID для ГОСТ Р 34.10-2001 
       id-GostR3410-2001 OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms gostR3410-2001(19) }
       id-GostR3410-2001DH OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms gostR3410-2001DH(98) }
       id-GostR3411-94-with-GostR3410-2001 OBJECT IDENTIFIER ::=
           { id-CryptoPro-algorithms
             gostR3411-94-with-gostR3410-2001(3) }
     -- Значения OID для набора параметров открытых ключей ГОСТ Р 34.10-2001
       id-GostR3410-2001-TestParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-ecc-signs test(0) }
       id-GostR3410-2001-CryptoPro-A-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-ecc-signs cryptopro-A(1) }
       id-GostR3410-2001-CryptoPro-B-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-ecc-signs cryptopro-B(2) }
       id-GostR3410-2001-CryptoPro-C-ParamSet OBJECT IDENTIFIER ::=
           { id-CryptoPro-ecc-signs cryptopro-C(3) }
       id-GostR3410-2001-CryptoPro-XchA-ParamSet
           OBJECT IDENTIFIER ::=
                   { id-CryptoPro-ecc-exchanges cryptopro-XchA(0) }
       id-GostR3410-2001-CryptoPro-XchB-ParamSet
           OBJECT IDENTIFIER ::=
                   { id-CryptoPro-ecc-exchanges cryptopro-XchB(1) }
     -- Типы данных ГОСТ Р 34.10-2001
       GostR3410-2001-CertificateSignature ::= BIT STRING ( SIZE(256..512) )
       GostR3410-2001-PublicKey ::= OCTET STRING ( SIZE(64) )
       GostR3410-2001-PublicKeyParameters ::=
           SEQUENCE {
               publicKeyParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3410-2001-TestParamSet |
                           -- Только для тестирования
                       id-GostR3410-2001-CryptoPro-A-ParamSet |
                       id-GostR3410-2001-CryptoPro-B-ParamSet |
                       id-GostR3410-2001-CryptoPro-C-ParamSet |
                       id-GostR3410-2001-CryptoPro-XchA-ParamSet |
                       id-GostR3410-2001-CryptoPro-XchB-ParamSet
                   ),
               digestParamSet
                   OBJECT IDENTIFIER (
                       id-GostR3411-94-TestParamSet |
                           -- Only for testing purposes
                       id-GostR3411-94-CryptoProParamSet
                   ),
               encryptionParamSet Gost28147-89-ParamSet OPTIONAL
           }
       GostR3410-2001-PublicKeyAlgorithms  ALGORITHM-IDENTIFIER ::= {
           { GostR3410-2001-PublicKeyParameters IDENTIFIED BY
                           id-GostR3410-2001 }
       }
   END -- GostR3410-2001-PKISyntax

10.9. GostR3410-2001-ParamSetSyntax

   GostR3410-2001-ParamSetSyntax
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2)
         other(1) modules(1) gostR3410-2001-ParamSetSyntax(12) 1 }
   DEFINITIONS ::=
   BEGIN
   -- EXPORTS All --
   -- Типы и значения, определенные в этом модуле, экспортируются для использования
   -- в других модулях ASN.1, содержащихся в спецификациях российской криптографии
   -- ГОСТ и ГОСТ Р, а также для использования в других приложениях для доступа
   -- к службам российской криптографии. Другие приложения могут использовать их
   -- для своих целей, но это не ограничивает расширения и изменения, которые могут
   -- потребоваться для поддержки и развития российских криптографических служб.
       IMPORTS
           gostR3410-2001-PKISyntax, ALGORITHM-IDENTIFIER,
           cryptographic-Gost-Useful-Definitions
           FROM Cryptographic-Gost-Useful-Definitions
               { iso(1) member-body(2) ru(643) rans(2)
                 cryptopro(2) other(1) modules(1)
                 cryptographic-Gost-Useful-Definitions(0) 1 }
           id-GostR3410-2001,
           id-GostR3410-2001-TestParamSet,
           id-GostR3410-2001-CryptoPro-A-ParamSet,
           id-GostR3410-2001-CryptoPro-B-ParamSet,
           id-GostR3410-2001-CryptoPro-C-ParamSet,
           id-GostR3410-2001-CryptoPro-XchA-ParamSet,
           id-GostR3410-2001-CryptoPro-XchB-ParamSet
           FROM GostR3410-2001-PKISyntax gostR3410-2001-PKISyntax
       ;
       GostR3410-2001-ParamSetParameters ::=
           SEQUENCE {
               a INTEGER,  -- 0 < a < p < 2^256
               b INTEGER,  -- 0 < b < p < 2^256
               p INTEGER,  -- 2^254 < p < 2^256
               q INTEGER,  -- 2^254 < q < 2^256
               x INTEGER,  -- 0 < x < p < 2^256
               y INTEGER   -- 0 < y < p < 2^256
           }
     -- Набор параметров открытых ключей ГОСТ Р 34.10-2001:
     -- Значения OID для наборов параметров импортированы из GostR3410-2001-PKISyntax
       GostR3410-2001-ParamSetAlgorithm ALGORITHM-IDENTIFIER ::= {
           { GostR3410-2001-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-2001-TestParamSet } |
           { GostR3410-2001-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-2001-CryptoPro-A-ParamSet  } |
           { GostR3410-2001-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-2001-CryptoPro-B-ParamSet  } |
           { GostR3410-2001-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-2001-CryptoPro-C-ParamSet  } |
           { GostR3410-2001-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-2001-CryptoPro-XchA-ParamSet  } |
           { GostR3410-2001-ParamSetParameters IDENTIFIED BY
                   id-GostR3410-2001-CryptoPro-XchB-ParamSet  }
       }
   END -- GostR3410-2001-ParamSetSyntax

11. Параметры

Параметры в этом разделе приведены, как SEQUENCE OF AlgorithmIdentifier в представлении ASN.1 DER [X.660], совпадающем с форматом примеров в [RFC4134], и могут быть извлечены с использованием той же программы.

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

11.1. Параметры алгоритма шифрования

Для каждого AlgorithmIdentifier в этой последовательности поле параметров содержит Gost28147-89-ParamSetParameters.

       0 30  480: SEQUENCE {
       4 30   94:  SEQUENCE {
       6 06    7:   OBJECT IDENTIFIER
                :    id-Gost28147-89-TestParamSet
      15 30   83:   SEQUENCE {
      17 04   64:    OCTET STRING
                :     4C DE 38 9C 29 89 EF B6 FF EB 56 C5 5E C2 9B 02
                :     98 75 61 3B 11 3F 89 60 03 97 0C 79 8A A1 D5 5D
                :     E2 10 AD 43 37 5D B3 8E B4 2C 77 E7 CD 46 CA FA
                :     D6 6A 20 1F 70 F4 1E A4 AB 03 F2 21 65 B8 44 D8
      83 02    1:    INTEGER 0
      86 02    1:    INTEGER 64
      89 30    9:    SEQUENCE {
      91 06    7:     OBJECT IDENTIFIER
                :      id-Gost28147-89-None-KeyMeshing
                :     }
                :    }
                :   }
     100 30   94:  SEQUENCE {
     102 06    7:   OBJECT IDENTIFIER
                :    id-Gost28147-89-CryptoPro-A-ParamSet
     111 30   83:   SEQUENCE {
     113 04   64:    OCTET STRING

                      --  K1 K2 K3 K4 K5 K6 K7 K8
                      --  9  3  E  E  B  3  1  B
                      --  6  7  4  7  5  A  D  A
                      --  3  E  6  A  1  D  2  F
                      --  2  9  2  C  9  C  9  5
                      --  8  8  B  D  8  1  7  0
                      --  B  A  3  1  D  2  A  C
                      --  1  F  D  3  F  0  6  E
                      --  7  0  8  9  0  B  0  8
                      --  A  5  C  0  E  7  8  6
                      --  4  2  F  2  4  5  C  2
                      --  E  6  5  B  2  9  4  3
                      --  F  C  A  4  3  4  5  9
                      --  C  B  0  F  C  8  F  1
                      --  0  4  7  8  7  F  3  7
                      --  D  D  1  5  A  E  B  D
                      --  5  1  9  6  6  6  E  4

                :     93 EE B3 1B 67 47 5A DA 3E 6A 1D 2F 29 2C 9C 95
                :     88 BD 81 70 BA 31 D2 AC 1F D3 F0 6E 70 89 0B 08
                :     A5 C0 E7 86 42 F2 45 C2 E6 5B 29 43 FC A4 34 59
                :     CB 0F C8 F1 04 78 7F 37 DD 15 AE BD 51 96 66 E4
     179 02    1:    INTEGER 1
     182 02    1:    INTEGER 64
     185 30    9:    SEQUENCE {
     187 06    7:     OBJECT IDENTIFIER
                :      id-Gost28147-89-CryptoPro-KeyMeshing
                :     }
                :    }
                :   }
     196 30   94:  SEQUENCE {
     198 06    7:   OBJECT IDENTIFIER
                :    id-Gost28147-89-CryptoPro-B-ParamSet
     207 30   83:   SEQUENCE {
     209 04   64:    OCTET STRING
                :     80 E7 28 50 41 C5 73 24 B2 00 C2 AB 1A AD F6 BE
                :     34 9B 94 98 5D 26 5D 13 05 D1 AE C7 9C B2 BB 31
                :     29 73 1C 7A E7 5A 41 42 A3 8C 07 D9 CF FF DF 06
                :     DB 34 6A 6F 68 6E 80 FD 76 19 E9 85 FE 48 35 EC
     275 02    1:    INTEGER 1
     278 02    1:    INTEGER 64
     281 30    9:    SEQUENCE {
     283 06    7:     OBJECT IDENTIFIER
                :      id-Gost28147-89-CryptoPro-KeyMeshing
                :     }
                :    }
                :   }
     292 30   94:  SEQUENCE {
     294 06    7:   OBJECT IDENTIFIER
                :    id-Gost28147-89-CryptoPro-C-ParamSet
     303 30   83:   SEQUENCE {
     305 04   64:    OCTET STRING
                :     10 83 8C A7 B1 26 D9 94 C7 50 BB 60 2D 01 01 85
                :     9B 45 48 DA D4 9D 5E E2 05 FA 12 2F F2 A8 24 0E
                :     48 3B 97 FC 5E 72 33 36 8F C9 C6 51 EC D7 E5 BB
                :     A9 6E 6A 4D 7A EF F0 19 66 1C AF C3 33 B4 7D 78
     371 02    1:    INTEGER 1
     374 02    1:    INTEGER 64
     377 30    9:    SEQUENCE {
     379 06    7:     OBJECT IDENTIFIER
                :      id-Gost28147-89-CryptoPro-KeyMeshing
                :     }
                :    }
                :   }
     388 30   94:  SEQUENCE {
     390 06    7:   OBJECT IDENTIFIER
                :    id-Gost28147-89-CryptoPro-D-ParamSet
     399 30   83:   SEQUENCE {
     401 04   64:    OCTET STRING
                :     FB 11 08 31 C6 C5 C0 0A 23 BE 8F 66 A4 0C 93 F8
                :     6C FA D2 1F 4F E7 25 EB 5E 60 AE 90 02 5D BB 24
                :     77 A6 71 DC 9D D2 3A 83 E8 4B 64 C5 D0 84 57 49
                :     15 99 4C B7 BA 33 E9 AD 89 7F FD 52 31 28 16 7E
     467 02    1:    INTEGER 1
     470 02    1:    INTEGER 64
     473 30    9:    SEQUENCE {
     475 06    7:     OBJECT IDENTIFIER
                :      id-Gost28147-89-CryptoPro-KeyMeshing
                :     }
                :    }
                :   }
                :  }
   |>Gost28147-89-ParamSetParameters.bin
   |MIIB4DBeBgcqhQMCAh8AMFMEQEzeOJwpie+2/+tWxV7CmwKYdWE7ET+JYAOXDHmK
   |odVd4hCtQzdds460LHfnzUbK+tZqIB9w9B6kqwPyIWW4RNgCAQACAUAwCQYHKoUD
   |AgIOADBeBgcqhQMCAh8BMFMEQJPusxtnR1raPmodLyksnJWIvYFwujHSrB/T8G5w
   |iQsIpcDnhkLyRcLmWylD/KQ0WcsPyPEEeH833RWuvVGWZuQCAQECAUAwCQYHKoUD
   |AgIOATBeBgcqhQMCAh8CMFMEQIDnKFBBxXMksgDCqxqt9r40m5SYXSZdEwXRrsec
   |srsxKXMceudaQUKjjAfZz//fBts0am9oboD9dhnphf5INewCAQECAUAwCQYHKoUD
   |AgIOATBeBgcqhQMCAh8DMFMEQBCDjKexJtmUx1C7YC0BAYWbRUja1J1e4gX6Ei/y
   |qCQOSDuX/F5yMzaPycZR7Nflu6luak167/AZZhyvwzO0fXgCAQECAUAwCQYHKoUD
   |AgIOATBeBgcqhQMCAh8EMFMEQPsRCDHGxcAKI76PZqQMk/hs+tIfT+cl615grpAC
   |Xbskd6Zx3J3SOoPoS2TF0IRXSRWZTLe6M+mtiX/9UjEoFn4CAQECAUAwCQYHKoUD
   |AgIOAQ==
   |<Gost28147-89-ParamSetParameters.bin

11.2. Параметры алгоритма подписи

Для каждого AlgorithmIdentifier в этой последовательности поле параметров содержит GostR3411-94-ParamSetParameters.

       0 30  226: SEQUENCE {
       3 30  111:  SEQUENCE {
       5 06    7:   OBJECT IDENTIFIER
                :    id-GostR3411-94-TestParamSet
      14 30  100:   SEQUENCE {
      16 04   64:    OCTET STRING

                      --    pi1 pi2 pi3 pi4 pi5 pi6 pi7 pi8
                      --     4   E   5   7   6   4   D   1
                      --     A   B   8   D   C   B   B   F
                      --     9   4   1   A   7   A   4   D
                      --     2   C   D   1   1   0   1   0
                      --     D   6   A   0   5   7   3   5
                      --     8   D   3   8   F   2   F   7
                      --     0   F   4   9   D   1   5   A
                      --     E   A   2   F   8   D   9   4
                      --     6   2   E   E   4   3   0   9
                      --     B   3   F   4   A   6   A   2
                      --     1   8   C   6   9   8   E   3
                      --     C   1   7   C   E   5   7   E
                      --     7   0   6   B   0   9   6   6
                      --     F   7   0   2   3   C   8   B
                      --     5   5   9   5   B   F   2   8
                      --     3   9   B   3   2   E   C   C

                :     4E 57 64 D1 AB 8D CB BF 94 1A 7A 4D 2C D1 10 10
                :     D6 A0 57 35 8D 38 F2 F7 0F 49 D1 5A EA 2F 8D 94
                :     62 EE 43 09 B3 F4 A6 A2 18 C6 98 E3 C1 7C E5 7E
                :     70 6B 09 66 F7 02 3C 8B 55 95 BF 28 39 B3 2E CC
      82 04   32:    OCTET STRING
                :     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :    }
                :   }
     116 30  111:  SEQUENCE {
     118 06    7:   OBJECT IDENTIFIER
                :    id-GostR3411-94-CryptoProParamSet
     127 30  100:   SEQUENCE {
     129 04   64:    OCTET STRING
                :     A5 74 77 D1 4F FA 66 E3 54 C7 42 4A 60 EC B4 19
                :     82 90 9D 75 1D 4F C9 0B 3B 12 2F 54 79 08 A0 AF
                :     D1 3E 1A 38 C7 B1 81 C6 E6 56 05 87 03 25 EB FE
                :     9C 6D F8 6D 2E AB DE 20 BA 89 3C 92 F8 D3 53 BC
     195 04   32:    OCTET STRING
                :     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :    }
                :   }
                :  }

   |>GostR3411-94-ParamSetParameters.bin
   |MIHiMG8GByqFAwICHgAwZARATldk0auNy7+UGnpNLNEQENagVzWNOPL3D0nRWuov
   |jZRi7kMJs/SmohjGmOPBfOV+cGsJZvcCPItVlb8oObMuzAQgAAAAAAAAAAAAAAAA
   |AAAAAAAAAAAAAAAAAAAAAAAAAAAwbwYHKoUDAgIeATBkBECldHfRT/pm41THQkpg
   |7LQZgpCddR1PyQs7Ei9UeQigr9E+GjjHsYHG5lYFhwMl6/6cbfhtLqveILqJPJL4
   |01O8BCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
   |<GostR3411-94-ParamSetParameters.bin

11.3. Параметры алгоритма с открытым ключом ГОСТ Р 34.10-94

Для каждого AlgorithmIdentifier в этой последовательности поле параметров содержит GostR3410-94-ParamSetParameters.

       0 30 2882: SEQUENCE {
       4 30  209:  SEQUENCE {
       7 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-TestParamSet
      16 30  197:   SEQUENCE {
      19 02    2:    INTEGER 512
      23 02   65:    INTEGER
                :     00 EE 81 72 AE 89 96 60 8F B6 93 59 B8 9E B8 2A
                :     69 85 45 10 E2 97 7A 4D 63 BC 97 32 2C E5 DC 33
                :     86 EA 0A 12 B3 43 E9 19 0F 23 17 75 39 84 58 39
                :     78 6B B0 C3 45 D1 65 97 6E F2 19 5E C9 B1 C3 79
                :     E3
      90 02   33:    INTEGER
                :     00 98 91 5E 7E C8 26 5E DF CD A3 1E 88 F2 48 09
                :     DD B0 64 BD C7 28 5D D5 0D 72 89 F0 AC 6F 49 DD
                :     2D
     125 02   65:    INTEGER
                :     00 9E 96 03 15 00 C8 77 4A 86 95 82 D4 AF DE 21
                :     27 AF AD 25 38 B4 B6 27 0A 6F 7C 88 37 B5 0D 50
                :     F2 06 75 59 84 A4 9E 50 93 04 D6 48 BE 2A B5 AA
                :     B1 8E BE 2C D4 6A C3 D8 49 5B 14 2A A6 CE 23 E2
                :     1C
     192 30   22:    SEQUENCE {
     194 06    7:     OBJECT IDENTIFIER id-GostR3410-94-a
     203 30   11:     SEQUENCE {
     205 02    2:      INTEGER 24265
     209 02    2:      INTEGER 29505
     213 02    1:      INTEGER 2
                :      }
                :     }
                :    }
                :   }
     216 30  342:  SEQUENCE {
     220 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-CryptoPro-A-ParamSet
     229 30  329:   SEQUENCE {
     233 02    2:    INTEGER 1024
     237 02  129:    INTEGER
                :     00 B4 E2 5E FB 01 8E 3C 8B 87 50 5E 2A 67 55 3C
                :     5E DC 56 C2 91 4B 7E 4F 89 D2 3F 03 F0 33 77 E7
                :     0A 29 03 48 9D D6 0E 78 41 8D 3D 85 1E DB 53 17
                :     C4 87 1E 40 B0 42 28 C3 B7 90 29 63 C4 B7 D8 5D
                :     52 B9 AA 88 F2 AF DB EB 28 DA 88 69 D6 DF 84 6A
                :     1D 98 92 4E 92 55 61 BD 69 30 0B 9D DD 05 D2 47
                :     B5 92 2D 96 7C BB 02 67 18 81 C5 7D 10 E5 EF 72
                :     D3 E6 DA D4 22 3D C8 2A A1 F7 D0 29 46 51 A4 80
                :     DF
     369 02   33:    INTEGER
                :     00 97 24 32 A4 37 17 8B 30 BD 96 19 5B 77 37 89
                :     AB 2F FF 15 59 4B 17 6D D1 75 B6 32 56 EE 5A F2
                :     CF
     404 02  129:    INTEGER
                :     00 8F D3 67 31 23 76 54 BB E4 1F 5F 1F 84 53 E7
                :     1C A4 14 FF C2 2C 25 D9 15 30 9E 5D 2E 62 A2 A2
                :     6C 71 11 F3 FC 79 56 8D AF A0 28 04 2F E1 A5 2A
                :     04 89 80 5C 0D E9 A1 A4 69 C8 44 C7 CA BB EE 62
                :     5C 30 78 88 8C 1D 85 EE A8 83 F1 AD 5B C4 E6 77
                :     6E 8E 1A 07 50 91 2D F6 4F 79 95 64 99 F1 E1 82
                :     47 5B 0B 60 E2 63 2A DC D8 CF 94 E9 C5 4F D1 F3
                :     B1 09 D8 1F 00 BF 2A B8 CB 86 2A DF 7D 40 B9 36
                :     9A
     536 30   24:    SEQUENCE {
     538 06    7:     OBJECT IDENTIFIER id-GostR3410-94-bBis
     547 30   13:     SEQUENCE {
     549 02    4:      INTEGER 1376285941
     555 02    5:      INTEGER
                :       00 EE 39 AD B3
                :      }
                :     }
                :    }
                :   }
     562 30  427:  SEQUENCE {
     566 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-CryptoPro-B-ParamSet
     575 30  414:   SEQUENCE {
     579 02    2:    INTEGER 1024
     583 02  129:    INTEGER
                :     00 C6 97 1F C5 75 24 B3 0C 90 18 C5 E6 21 DE 15
                :     49 97 36 85 4F 56 A6 F8 AE E6 5A 7A 40 46 32 B1
                :     BC F0 34 9F FC AF CB 0A 10 31 77 97 1F C1 61 2A
                :     DC DB 8C 8C C9 38 C7 02 25 C8 FD 12 AF F0 1B 1D
                :     06 4E 0A D6 FD E6 AB 91 59 16 6C B9 F2 FC 17 1D
                :     92 F0 CC 7B 6A 6B 2C D7 FA 34 2A CB E2 C9 31 5A
                :     42 D5 76 B1 EC CE 77 A9 63 15 7F 3D 0B D9 6A 8E
                :     B0 B0 F3 50 2A D2 38 10 1B 05 11 63 34 F1 E5 B7
                :     AB
     715 02   33:    INTEGER
                :     00 B0 9D 63 4C 10 89 9C D7 D4 C3 A7 65 74 03 E0
                :     58 10 B0 7C 61 A6 88 BA B2 C3 7F 47 5E 30 8B 06
                :     07
     750 02  128:    INTEGER
                :     3D 26 B4 67 D9 4A 3F FC 9D 71 BF 8D B8 93 40 84
                :     13 72 64 F3 C2 E9 EB 16 DC A2 14 B8 BC 7C 87 24
                :     85 33 67 44 93 4F D2 EF 59 43 F9 ED 0B 74 5B 90
                :     AA 3E C8 D7 0C DC 91 68 24 78 B6 64 A2 E1 F8 FB
                :     56 CE F2 97 2F EE 7E DB 08 4A F7 46 41 9B 85 4F
                :     AD 02 CC 3E 36 46 FF 2E 1A 18 DD 4B EB 3C 44 F7
                :     F2 74 55 88 02 96 49 67 45 46 CC 91 87 C2 07 FB
                :     8F 2C EC E8 E2 29 3F 68 39 5C 47 04 AF 04 BA B5
     881 30  110:    SEQUENCE {
     883 06    7:     OBJECT IDENTIFIER id-GostR3410-94-bBis
     892 30   99:     SEQUENCE {
     894 02    4:      INTEGER 1536654555
     900 02    4:      INTEGER 1855361757
     906 02   85:      INTEGER
                :       00 BC 3C BB DB 7E 6F 84 82 86 E1 9A D9 A2 7A 8E
                :       29 7E 5B 71 C5 3D D9 74 CD F6 0F 93 73 56 DF 69
                :       CB C9 7A 30 0C CC 71 68 5C 55 30 46 14 7F 11 56
                :       8C 4F DD F3 63 D9 D8 86 43 83 45 A6 2C 3B 75 96
                :       3D 65 46 AD FA BF 31 B3 12 90 D1 2C AE 65 EC B8
                :       30 9E F6 67 82
                :      }
                :     }
                :    }
                :   }
     993 30  351:  SEQUENCE {
     997 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-CryptoPro-C-ParamSet
    1006 30  338:   SEQUENCE {
    1010 02    2:    INTEGER 1024
    1014 02  129:    INTEGER
                :     00 9D 88 E6 D7 FE 33 13 BD 2E 74 5C 7C DD 2A B9
                :     EE 4A F3 C8 89 9E 84 7D E7 4A 33 78 3E A6 8B C3
                :     05 88 BA 1F 73 8C 6A AF 8A B3 50 53 1F 18 54 C3
                :     83 7C C3 C8 60 FF D7 E2 E1 06 C3 F6 3B 3D 8A 4C
                :     03 4C E7 39 42 A6 C3 D5 85 B5 99 CF 69 5E D7 A3
                :     C4 A9 3B 2B 94 7B 71 57 BB 1A 1C 04 3A B4 1E C8
                :     56 6C 61 45 E9 38 A6 11 90 6D E0 D3 2E 56 24 94
                :     56 9D 7E 99 9A 0D DA 5C 87 9B DD 91 FE 12 4D F1
                :     E9
    1146 02   33:    INTEGER
                :     00 FA DD 19 7A BD 19 A1 B4 65 3E EC F7 EC A4 D6
                :     A2 2B 1F 7F 89 3B 64 1F 90 16 41 FB B5 55 35 4F
                :     AF
    1181 02  128:    INTEGER
                :     74 47 ED 71 56 31 05 99 07 0B 12 60 99 47 A5 C8
                :     C8 A8 62 5C F1 CF 25 2B 40 7B 33 1F 93 D6 39 DD
                :     D1 BA 39 26 56 DE CA 99 2D D0 35 35 43 29 A1 E9
                :     5A 6E 32 D6 F4 78 82 D9 60 B8 F1 0A CA FF 79 6D
                :     13 CD 96 11 F8 53 DA B6 D2 62 34 83 E4 67 88 70
                :     84 93 93 7A 1A 29 44 25 98 AE C2 E0 74 20 22 56
                :     34 40 FE 9C 18 74 0E CE 67 65 AC 05 FA F0 24 A6
                :     4B 02 6E 7E 40 88 40 81 9E 96 2E 7E 5F 40 1A E3
    1312 30   34:    SEQUENCE {
    1314 06    7:     OBJECT IDENTIFIER id-GostR3410-94-bBis
    1323 30   23:     SEQUENCE {
    1325 02    4:      INTEGER 1132758852
    1331 02    5:      INTEGER
                :       00 B5 0A 82 6D
    1338 02    8:      INTEGER
                :       7F 57 5E 81 94 BC 5B DF
                :      }
                :     }
                :    }
                :   }
    1348 30  371:  SEQUENCE {
    1352 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-CryptoPro-D-ParamSet
    1361 30  358:   SEQUENCE {
    1365 02    2:    INTEGER 1024
    1369 02  129:    INTEGER
                :     00 80 F1 02 D3 2B 0F D1 67 D0 69 C2 7A 30 7A DA
                :     D2 C4 66 09 19 04 DB AA 55 D5 B8 CC 70 26 F2 F7
                :     A1 91 9B 89 0C B6 52 C4 0E 05 4E 1E 93 06 73 5B
                :     43 D7 B2 79 ED DF 91 02 00 1C D9 E1 A8 31 FE 8A
                :     16 3E ED 89 AB 07 CF 2A BE 82 42 AC 9D ED DD BF
                :     98 D6 2C DD D1 EA 4F 5F 15 D3 A4 2A 66 77 BD D2
                :     93 B2 42 60 C0 F2 7C 0F 1D 15 94 86 14 D5 67 B6
                :     6F A9 02 BA A1 1A 69 AE 3B CE AD BB 83 E3 99 C9
                :     B5
    1501 02   33:    INTEGER
                :     00 F0 F5 44 C4 18 AA C2 34 F6 83 F0 33 51 1B 65
                :     C2 16 51 A6 07 8B DA 2D 69 BB 9F 73 28 67 50 21
                :     49
    1536 02  128:    INTEGER
                :     6B CC 0B 4F AD B3 88 9C 1E 06 AD D2 3C C0 9B 8A
                :     B6 EC DE DF 73 F0 46 32 59 5E E4 25 00 05 D6 AF
                :     5F 5A DE 44 CB 1E 26 E6 26 3C 67 23 47 CF A2 6F
                :     9E 93 93 68 1E 6B 75 97 33 78 4C DE 5D BD 9A 14
                :     A3 93 69 DF D9 9F A8 5C C0 D1 02 41 C4 01 03 43
                :     F3 4A 91 39 3A 70 6C F1 26 77 CB FA 1F 57 8D 6B
                :     6C FB E8 A1 24 2C FC C9 4B 3B 65 3A 47 6E 14 5E
                :     38 62 C1 8C C3 FE D8 25 7C FE F7 4C DB 20 5B F1
    1667 30   54:    SEQUENCE {
    1669 06    7:     OBJECT IDENTIFIER id-GostR3410-94-bBis
    1678 30   43:     SEQUENCE {
    1680 02    4:      INTEGER 333089693
    1686 02    5:      INTEGER
                :       00 A0 E9 DE 4B
    1693 02   28:      INTEGER
                :       41 AB 97 85 7F 42 61 43 55 D3 2D B0 B1 06 9F 10
                :       9A 4D A2 83 67 6C 7C 53 A6 81 85 B4
                :      }
                :     }
                :    }
                :   }
    1723 30  396:  SEQUENCE {
    1727 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-CryptoPro-XchA-ParamSet
    1736 30  383:   SEQUENCE {
    1740 02    2:    INTEGER 1024
    1744 02  129:    INTEGER
                :     00 CA 3B 3F 2E EE 9F D4 63 17 D4 95 95 A9 E7 51
                :     8E 6C 63 D8 F4 EB 4D 22 D1 0D 28 AF 0B 88 39 F0
                :     79 F8 28 9E 60 3B 03 53 07 84 B9 BB 5A 1E 76 85
                :     9E 48 50 C6 70 C7 B7 1C 0D F8 4C A3 E0 D6 C1 77
                :     FE 9F 78 A9 D8 43 32 30 A8 83 CD 82 A2 B2 B5 C7
                :     A3 30 69 80 27 85 70 CD B7 9B F0 10 74 A6 9C 96
                :     23 34 88 24 B0 C5 37 91 D5 3C 6A 78 CA B6 9E 1C
                :     FB 28 36 86 11 A3 97 F5 0F 54 1E 16 DB 34 8D BE
                :     5F
    1876 02   33:    INTEGER
                :     00 CA E4 D8 5F 80 C1 47 70 4B 0C A4 8E 85 FB 00
                :     A9 05 7A A4 AC C4 46 68 E1 7F 19 96 D7 15 26 90
                :     D9
    1911 02  129:    INTEGER
                :     00 BE 27 D6 52 F2 F1 E3 39 DA 73 42 11 B8 5B 06
                :     AE 4D E2 36 AA 8F BE EB 3F 1A DC C5 2C D4 38 53
                :     77 7E 83 4A 6A 51 81 38 67 8A 8A DB D3 A5 5C 70
                :     A7 EA B1 BA 7A 07 19 54 86 77 AA F4 E6 09 FF B4
                :     7F 6B 9D 7E 45 B0 D0 6D 83 D7 AD C5 33 10 AB D8
                :     57 83 E7 31 7F 7E C7 32 68 B6 A9 C0 8D 26 0B 85
                :     D8 48 56 96 CA 39 C1 7B 17 F0 44 D1 E0 50 48 90
                :     36 AB D3 81 C5 E6 BF 82 BA 35 2A 1A FF 13 66 01
                :     AF
    2043 30   78:    SEQUENCE {
    2045 06    7:     OBJECT IDENTIFIER id-GostR3410-94-bBis
    2054 30   67:     SEQUENCE {
    2056 02    5:      INTEGER
                :       00 D0 5E 9F 14
    2063 02    4:      INTEGER 1177570399
    2069 02   52:      INTEGER
                :       35 AB 87 53 99 CD A3 3C 14 6C A6 29 66 0E 5A 5E
                :       5C 07 71 4C A3 26 DB 03 2D D6 75 19 95 CD B9 0A
                :       61 2B 92 28 93 2D 83 02 70 4E C2 4A 5D EF 77 39
                :       C5 81 3D 83
                :      }
                :     }
                :    }
                :   }
    2123 30  375:  SEQUENCE {
    2127 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-CryptoPro-XchB-ParamSet
    2136 30  362:   SEQUENCE {
    2140 02    2:    INTEGER 1024
    2144 02  129:    INTEGER
                :     00 92 86 DB DA 91 EC CF C3 06 0A A5 59 83 18 E2
                :     A6 39 F5 BA 90 A4 CA 65 61 57 B2 67 3F B1 91 CD
                :     05 89 EE 05 F4 CE F1 BD 13 50 84 08 27 14 58 C3
                :     08 51 CE 7A 4E F5 34 74 2B FB 11 F4 74 3C 8F 78
                :     7B 11 19 3B A3 04 C0 E6 BC A2 57 01 BF 88 AF 1C
                :     B9 B8 FD 47 11 D8 9F 88 E3 2B 37 D9 53 16 54 1B
                :     F1 E5 DB B4 98 9B 3D F1 36 59 B8 8C 0F 97 A3 C1
                :     08 7B 9F 2D 53 17 D5 57 DC D4 AF C6 D0 A7 54 E2
                :     79
    2276 02   33:    INTEGER
                :     00 C9 66 E9 B3 B8 B7 CD D8 2F F0 F8 3A F8 70 36
                :     C3 8F 42 23 8E C5 0A 87 6C D3 90 E4 3D 67 B6 01
                :     3F
    2311 02  128:    INTEGER
                :     7E 9C 30 96 67 6F 51 E3 B2 F9 88 4C F0 AC 21 56
                :     77 94 96 F4 10 E0 49 CE D7 E5 3D 8B 7B 5B 36 6B
                :     1A 60 08 E5 19 66 05 A5 5E 89 C3 19 0D AB F8 0B
                :     9F 11 63 C9 79 FC D1 83 28 DA E5 E9 04 88 11 B3
                :     70 10 7B B7 71 5F 82 09 1B B9 DE 0E 33 EE 2F ED
                :     62 55 47 4F 87 69 FC E5 EA FA EE F1 CB 5A 32 E0
                :     D5 C6 C2 F0 FC 0B 34 47 07 29 47 F5 B4 C3 87 66
                :     69 93 A3 33 FC 06 56 8E 53 4A D5 6D 23 38 D7 29
    2442 30   58:    SEQUENCE {
    2444 06    7:     OBJECT IDENTIFIER id-GostR3410-94-bBis
    2453 30   47:     SEQUENCE {
    2455 02    4:      INTEGER 2046851076
    2461 02    5:      INTEGER
                :       00 D3 1A 4F F7
    2468 02   32:      INTEGER
                :       7E C1 23 D1 61 47 77 62 83 8C 2B EA 9D BD F3 30
                :       74 AF 6D 41 D1 08 A0 66 A1 E7 A0 7A B3 04 8D E2
                :      }
                :     }
                :    }
                :   }
    2502 30  380:  SEQUENCE {
    2506 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-94-CryptoPro-XchC-ParamSet
    2515 30  367:   SEQUENCE {
    2519 02    2:    INTEGER 1024
    2523 02  129:    INTEGER
                :     00 B1 94 03 6A CE 14 13 9D 36 D6 42 95 AE 6C 50
                :     FC 4B 7D 65 D8 B3 40 71 13 66 CA 93 F3 83 65 39
                :     08 EE 63 7B E4 28 05 1D 86 61 26 70 AD 7B 40 2C
                :     09 B8 20 FA 77 D9 DA 29 C8 11 1A 84 96 DA 6C 26
                :     1A 53 ED 25 2E 4D 8A 69 A2 03 76 E6 AD DB 3B DC
                :     D3 31 74 9A 49 1A 18 4B 8F DA 6D 84 C3 1C F0 5F
                :     91 19 B5 ED 35 24 6E A4 56 2D 85 92 8B A1 13 6A
                :     8D 0E 5A 7E 5C 76 4B A8 90 20 29 A1 33 6C 63 1A
                :     1D
    2655 02   33:    INTEGER
                :     00 96 12 04 77 DF 0F 38 96 62 8E 6F 4A 88 D8 3C
                :     93 20 4C 21 0F F2 62 BC CB 7D AE 45 03 55 12 52
                :     59
    2690 02  128:    INTEGER
                :     3F 18 17 05 2B AA 75 98 FE 3E 4F 4F C5 C5 F6 16
                :     E1 22 CF F9 EB D8 9E F8 1D C7 CE 8B F5 6C C6 4B
                :     43 58 6C 80 F1 C4 F5 6D D5 71 8F DD 76 30 0B E3
                :     36 78 42 59 CA 25 AA DE 5A 48 3F 64 C0 2A 20 CF
                :     4A 10 F9 C1 89 C4 33 DE FE 31 D2 63 E6 C9 76 46
                :     60 A7 31 EC CA EC B7 4C 82 79 30 37 31 E8 CF 69
                :     20 5B C7 3E 5A 70 BD F9 3E 5B B6 81 DA B4 EE B9
                :     C7 33 CA AB 2F 67 3C 47 5E 0E CA 92 1D 29 78 2E
    2821 30   63:    SEQUENCE {
    2823 06    7:     OBJECT IDENTIFIER id-GostR3410-94-bBis
    2832 30   52:     SEQUENCE {
    2834 02    4:      INTEGER 371898640
    2840 02    5:      INTEGER
                :       00 93 F8 28 D3
    2847 02   37:      INTEGER
                :       00 CA 82 CC E7 8A 73 8B C4 6F 10 3D 53 B9 BF 80
                :       97 45 EC 84 5E 4F 6D A4 62 60 6C 51 F6 0E CF 30
                :       2E 31 20 4B 81
                :      }
                :     }
                :    }
                :   }
                :  }

   |>GostR3410-94-ParamSetParameters.bin
   |MIILQjCB0QYHKoUDAgIgADCBxQICAgACQQDugXKuiZZgj7aTWbieuCpphUUQ4pd6
   |TWO8lzIs5dwzhuoKErND6RkPIxd1OYRYOXhrsMNF0WWXbvIZXsmxw3njAiEAmJFe
   |fsgmXt/Nox6I8kgJ3bBkvccoXdUNconwrG9J3S0CQQCelgMVAMh3SoaVgtSv3iEn
   |r60lOLS2JwpvfIg3tQ1Q8gZ1WYSknlCTBNZIviq1qrGOvizUasPYSVsUKqbOI+Ic
   |MBYGByqFAwICFAEwCwICXskCAnNBAgECMIIBVgYHKoUDAgIgAjCCAUkCAgQAAoGB
   |ALTiXvsBjjyLh1BeKmdVPF7cVsKRS35PidI/A/Azd+cKKQNIndYOeEGNPYUe21MX
   |xIceQLBCKMO3kCljxLfYXVK5qojyr9vrKNqIadbfhGodmJJOklVhvWkwC53dBdJH
   |tZItlny7AmcYgcV9EOXvctPm2tQiPcgqoffQKUZRpIDfAiEAlyQypDcXizC9lhlb
   |dzeJqy//FVlLF23RdbYyVu5a8s8CgYEAj9NnMSN2VLvkH18fhFPnHKQU/8IsJdkV
   |MJ5dLmKiomxxEfP8eVaNr6AoBC/hpSoEiYBcDemhpGnIRMfKu+5iXDB4iIwdhe6o
   |g/GtW8Tmd26OGgdQkS32T3mVZJnx4YJHWwtg4mMq3NjPlOnFT9HzsQnYHwC/KrjL
   |hirffUC5NpowGAYHKoUDAgIUBDANAgRSCHT1AgUA7jmtszCCAasGByqFAwICIAMw
   |ggGeAgIEAAKBgQDGlx/FdSSzDJAYxeYh3hVJlzaFT1am+K7mWnpARjKxvPA0n/yv
   |ywoQMXeXH8FhKtzbjIzJOMcCJcj9Eq/wGx0GTgrW/earkVkWbLny/BcdkvDMe2pr
   |LNf6NCrL4skxWkLVdrHsznepYxV/PQvZao6wsPNQKtI4EBsFEWM08eW3qwIhALCd
   |Y0wQiZzX1MOnZXQD4FgQsHxhpoi6ssN/R14wiwYHAoGAPSa0Z9lKP/ydcb+NuJNA
   |hBNyZPPC6esW3KIUuLx8hySFM2dEk0/S71lD+e0LdFuQqj7I1wzckWgkeLZkouH4
   |+1bO8pcv7n7bCEr3RkGbhU+tAsw+Nkb/LhoY3UvrPET38nRViAKWSWdFRsyRh8IH
   |+48s7OjiKT9oOVxHBK8EurUwbgYHKoUDAgIUBDBjAgRbl3zbAgRulpLdAlUAvDy7
   |235vhIKG4ZrZonqOKX5bccU92XTN9g+Tc1bfacvJejAMzHFoXFUwRhR/EVaMT93z
   |Y9nYhkODRaYsO3WWPWVGrfq/MbMSkNEsrmXsuDCe9meCMIIBXwYHKoUDAgIgBDCC
   |AVICAgQAAoGBAJ2I5tf+MxO9LnRcfN0que5K88iJnoR950ozeD6mi8MFiLofc4xq
   |r4qzUFMfGFTDg3zDyGD/1+LhBsP2Oz2KTANM5zlCpsPVhbWZz2le16PEqTsrlHtx
   |V7saHAQ6tB7IVmxhRek4phGQbeDTLlYklFadfpmaDdpch5vdkf4STfHpAiEA+t0Z
   |er0ZobRlPuz37KTWoisff4k7ZB+QFkH7tVU1T68CgYB0R+1xVjEFmQcLEmCZR6XI
   |yKhiXPHPJStAezMfk9Y53dG6OSZW3sqZLdA1NUMpoelabjLW9HiC2WC48QrK/3lt
   |E82WEfhT2rbSYjSD5GeIcISTk3oaKUQlmK7C4HQgIlY0QP6cGHQOzmdlrAX68CSm
   |SwJufkCIQIGeli5+X0Aa4zAiBgcqhQMCAhQEMBcCBEOEh0QCBQC1CoJtAgh/V16B
   |lLxb3zCCAXMGByqFAwICIAUwggFmAgIEAAKBgQCA8QLTKw/RZ9BpwnowetrSxGYJ
   |GQTbqlXVuMxwJvL3oZGbiQy2UsQOBU4ekwZzW0PXsnnt35ECABzZ4agx/ooWPu2J
   |qwfPKr6CQqyd7d2/mNYs3dHqT18V06QqZne90pOyQmDA8nwPHRWUhhTVZ7ZvqQK6
   |oRpprjvOrbuD45nJtQIhAPD1RMQYqsI09oPwM1EbZcIWUaYHi9otabufcyhnUCFJ
   |AoGAa8wLT62ziJweBq3SPMCbirbs3t9z8EYyWV7kJQAF1q9fWt5Eyx4m5iY8ZyNH
   |z6JvnpOTaB5rdZczeEzeXb2aFKOTad/Zn6hcwNECQcQBA0PzSpE5OnBs8SZ3y/of
   |V41rbPvooSQs/MlLO2U6R24UXjhiwYzD/tglfP73TNsgW/EwNgYHKoUDAgIUBDAr
   |AgQT2oudAgUAoOneSwIcQauXhX9CYUNV0y2wsQafEJpNooNnbHxTpoGFtDCCAYwG
   |ByqFAwICIQEwggF/AgIEAAKBgQDKOz8u7p/UYxfUlZWp51GObGPY9OtNItENKK8L
   |iDnwefgonmA7A1MHhLm7Wh52hZ5IUMZwx7ccDfhMo+DWwXf+n3ip2EMyMKiDzYKi
   |srXHozBpgCeFcM23m/AQdKacliM0iCSwxTeR1TxqeMq2nhz7KDaGEaOX9Q9UHhbb
   |NI2+XwIhAMrk2F+AwUdwSwykjoX7AKkFeqSsxEZo4X8ZltcVJpDZAoGBAL4n1lLy
   |8eM52nNCEbhbBq5N4jaqj77rPxrcxSzUOFN3foNKalGBOGeKitvTpVxwp+qxunoH
   |GVSGd6r05gn/tH9rnX5FsNBtg9etxTMQq9hXg+cxf37HMmi2qcCNJguF2EhWlso5
   |wXsX8ETR4FBIkDar04HF5r+CujUqGv8TZgGvME4GByqFAwICFAQwQwIFANBenxQC
   |BEYwTF8CNDWrh1OZzaM8FGymKWYOWl5cB3FMoybbAy3WdRmVzbkKYSuSKJMtgwJw
   |TsJKXe93OcWBPYMwggF3BgcqhQMCAiECMIIBagICBAACgYEAkobb2pHsz8MGCqVZ
   |gxjipjn1upCkymVhV7JnP7GRzQWJ7gX0zvG9E1CECCcUWMMIUc56TvU0dCv7EfR0
   |PI94exEZO6MEwOa8olcBv4ivHLm4/UcR2J+I4ys32VMWVBvx5du0mJs98TZZuIwP
   |l6PBCHufLVMX1Vfc1K/G0KdU4nkCIQDJZumzuLfN2C/w+Dr4cDbDj0IjjsUKh2zT
   |kOQ9Z7YBPwKBgH6cMJZnb1HjsvmITPCsIVZ3lJb0EOBJztflPYt7WzZrGmAI5Rlm
   |BaVeicMZDav4C58RY8l5/NGDKNrl6QSIEbNwEHu3cV+CCRu53g4z7i/tYlVHT4dp
   |/OXq+u7xy1oy4NXGwvD8CzRHBylH9bTDh2Zpk6Mz/AZWjlNK1W0jONcpMDoGByqF
   |AwICFAQwLwIEegB4BAIFANMaT/cCIH7BI9FhR3dig4wr6p298zB0r21B0QigZqHn
   |oHqzBI3iMIIBfAYHKoUDAgIhAzCCAW8CAgQAAoGBALGUA2rOFBOdNtZCla5sUPxL
   |fWXYs0BxE2bKk/ODZTkI7mN75CgFHYZhJnCte0AsCbgg+nfZ2inIERqEltpsJhpT
   |7SUuTYppogN25q3bO9zTMXSaSRoYS4/abYTDHPBfkRm17TUkbqRWLYWSi6ETao0O
   |Wn5cdkuokCApoTNsYxodAiEAlhIEd98POJZijm9KiNg8kyBMIQ/yYrzLfa5FA1US
   |UlkCgYA/GBcFK6p1mP4+T0/FxfYW4SLP+evYnvgdx86L9WzGS0NYbIDxxPVt1XGP
   |3XYwC+M2eEJZyiWq3lpIP2TAKiDPShD5wYnEM97+MdJj5sl2RmCnMezK7LdMgnkw
   |NzHoz2kgW8c+WnC9+T5btoHatO65xzPKqy9nPEdeDsqSHSl4LjA/BgcqhQMCAhQE
   |MDQCBBYquRACBQCT+CjTAiUAyoLM54pzi8RvED1Tub+Al0XshF5PbaRiYGxR9g7P
   |MC4xIEuB
   |<GostR3410-94-ParamSetParameters.bin

11.4. Параметры алгоритма с открытым ключом ГОСТ Р 34.10-2001

Для каждого AlgorithmIdentifier в этой последовательности поле параметров содержит GostR3410-2001-ParamSetParameters.

       0 30  998: SEQUENCE {
       4 30  156:  SEQUENCE {
       7 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-2001-TestParamSet
      16 30  144:   SEQUENCE {
      19 02    1:    INTEGER 7
      22 02   32:    INTEGER
                :     5F BF F4 98 AA 93 8C E7 39 B8 E0 22 FB AF EF 40
                :     56 3F 6E 6A 34 72 FC 2A 51 4C 0C E9 DA E2 3B 7E
      56 02   33:    INTEGER
                :     00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
                :     31
      91 02   33:    INTEGER
                :     00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :     01 50 FE 8A 18 92 97 61 54 C5 9C FC 19 3A CC F5
                :     B3
     126 02    1:    INTEGER 2
     129 02   32:    INTEGER
                :     08 E2 A8 A0 E6 51 47 D4 BD 63 16 03 0E 16 D1 9C
                :     85 C9 7F 0A 9C A2 67 12 2B 96 AB BC EA 7E 8F C8
                :    }
                :   }
     163 30  159:  SEQUENCE {
     166 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-2001-CryptoPro-A-ParamSet
     175 30  147:   SEQUENCE {
     178 02   33:    INTEGER
                :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
                :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
                :     94
     213 02    2:    INTEGER 166
     217 02   33:    INTEGER
                :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
                :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
                :     97
     252 02   33:    INTEGER
                :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
                :     FF 6C 61 10 70 99 5A D1 00 45 84 1B 09 B7 61 B8
                :     93
     287 02    1:    INTEGER 1
     290 02   33:    INTEGER
                :     00 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B
                :     76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E
                :     14
                :    }
                :   }
     325 30  188:  SEQUENCE {
     328 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-2001-CryptoPro-B-ParamSet
     337 30  176:   SEQUENCE {
     340 02   33:    INTEGER
                :     00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0C
                :     96
     375 02   32:    INTEGER
                :     3E 1A F4 19 A2 69 A5 F8 66 A7 D3 C2 5C 3D F8 0A
                :     E9 79 25 93 73 FF 2B 18 2F 49 D4 CE 7E 1B BC 8B
     409 02   33:    INTEGER
                :     00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0C
                :     99
     444 02   33:    INTEGER
                :     00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                :     01 5F 70 0C FF F1 A6 24 E5 E4 97 16 1B CC 8A 19
                :     8F
     479 02    1:    INTEGER 1
     482 02   32:    INTEGER
                :     3F A8 12 43 59 F9 66 80 B8 3D 1C 3E B2 C0 70 E5
                :     C5 45 C9 85 8D 03 EC FB 74 4B F8 D7 17 71 7E FC
                :    }
                :   }
     516 30  159:  SEQUENCE {
     519 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-2001-CryptoPro-C-ParamSet
     528 30  147:   SEQUENCE {
     531 02   33:    INTEGER
                :     00 9B 9F 60 5F 5A 85 81 07 AB 1E C8 5E 6B 41 C8
                :     AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75
                :     98
     566 02    3:    INTEGER 32858
     571 02   33:    INTEGER
                :     00 9B 9F 60 5F 5A 85 81 07 AB 1E C8 5E 6B 41 C8
                :     AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75
                :     9B
     606 02   33:    INTEGER
                :     00 9B 9F 60 5F 5A 85 81 07 AB 1E C8 5E 6B 41 C8
                :     AA 58 2C A3 51 1E DD FB 74 F0 2F 3A 65 98 98 0B
                :     B9
     641 02    1:    INTEGER 0
     644 02   32:    INTEGER
                :     41 EC E5 57 43 71 1A 8C 3C BF 37 83 CD 08 C0 EE
                :     4D 4D C4 40 D4 64 1A 8F 36 6E 55 0D FD B3 BB 67
                :    }
                :   }
     678 30  159:  SEQUENCE {
     681 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-2001-CryptoPro-XchA-ParamSet
     690 30  147:   SEQUENCE {
     693 02   33:    INTEGER
                :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
                :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
                :     94
     728 02    2:    INTEGER 166
     732 02   33:    INTEGER
                :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
                :     FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD
                :     97
     767 02   33:    INTEGER
                :     00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
                :     FF 6C 61 10 70 99 5A D1 00 45 84 1B 09 B7 61 B8
                :     93
     802 02    1:    INTEGER 1
     805 02   33:    INTEGER
                :     00 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B
                :     76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E
                :     14
                :    }
                :   }
     840 30  159:  SEQUENCE {
     843 06    7:   OBJECT IDENTIFIER
                :    id-GostR3410-2001-CryptoPro-XchB-ParamSet
     852 30  147:   SEQUENCE {
     855 02   33:    INTEGER
                :     00 9B 9F 60 5F 5A 85 81 07 AB 1E C8 5E 6B 41 C8
                :     AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75
                :     98
     890 02    3:    INTEGER 32858
     895 02   33:    INTEGER
                :     00 9B 9F 60 5F 5A 85 81 07 AB 1E C8 5E 6B 41 C8
                :     AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75
                :     9B
     930 02   33:    INTEGER
                :     00 9B 9F 60 5F 5A 85 81 07 AB 1E C8 5E 6B 41 C8
                :     AA 58 2C A3 51 1E DD FB 74 F0 2F 3A 65 98 98 0B
                :     B9
     965 02    1:    INTEGER 0
     968 02   32:    INTEGER
                :     41 EC E5 57 43 71 1A 8C 3C BF 37 83 CD 08 C0 EE
                :     4D 4D C4 40 D4 64 1A 8F 36 6E 55 0D FD B3 BB 67
                :    }
                :   }
                :  }

   |>GostR3410-2001-ParamSetParameters.bin
   |MIID5jCBnAYHKoUDAgIjADCBkAIBBwIgX7/0mKqTjOc5uOAi+6/vQFY/bmo0cvwq
   |UUwM6driO34CIQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMQIhAIAA
   |AAAAAAAAAAAAAAAAAAFQ/ooYkpdhVMWc/Bk6zPWzAgECAiAI4qig5lFH1L1jFgMO
   |FtGchcl/CpyiZxIrlqu86n6PyDCBnwYHKoUDAgIjATCBkwIhAP//////////////
   |//////////////////////////2UAgIApgIhAP//////////////////////////
   |//////////////2XAiEA/////////////////////2xhEHCZWtEARYQbCbdhuJMC
   |AQECIQCNkeRx4Jic2iffUFpFPyt2NSlPLd8j47EirMmcnp8eFDCBvAYHKoUDAgIj
   |AjCBsAIhAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyWAiA+GvQZomml
   |+Gan08JcPfgK6Xklk3P/KxgvSdTOfhu8iwIhAIAAAAAAAAAAAAAAAAAAAAAAAAAA
   |AAAAAAAAAAAAAAyZAiEAgAAAAAAAAAAAAAAAAAAAAV9wDP/xpiTl5JcWG8yKGY8C
   |AQECID+oEkNZ+WaAuD0cPrLAcOXFRcmFjQPs+3RL+NcXcX78MIGfBgcqhQMCAiMD
   |MIGTAiEAm59gX1qFgQerHshea0HIqs+EboZ4kFHTeZj3uQItdZgCAwCAWgIhAJuf
   |YF9ahYEHqx7IXmtByKrPhG6GeJBR03mY97kCLXWbAiEAm59gX1qFgQerHshea0HI
   |qlgso1Ee3ft08C86ZZiYC7kCAQACIEHs5VdDcRqMPL83g80IwO5NTcRA1GQajzZu
   |VQ39s7tnMIGfBgcqhQMCAiQAMIGTAiEA////////////////////////////////
   |/////////ZQCAgCmAiEA/////////////////////////////////////////ZcC
   |IQD/////////////////////bGEQcJla0QBFhBsJt2G4kwIBAQIhAI2R5HHgmJza
   |J99QWkU/K3Y1KU8t3yPjsSKsyZyenx4UMIGfBgcqhQMCAiQBMIGTAiEAm59gX1qF
   |gQerHshea0HIqs+EboZ4kFHTeZj3uQItdZgCAwCAWgIhAJufYF9ahYEHqx7IXmtB
   |yKrPhG6GeJBR03mY97kCLXWbAiEAm59gX1qFgQerHshea0HIqlgso1Ee3ft08C86
   |ZZiYC7kCAQACIEHs5VdDcRqMPL83g80IwO5NTcRA1GQajzZuVQ39s7tn
   |<GostR3410-2001-ParamSetParameters.bin

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

Этот документ создан с соответствии с «Соглашением о совместимости СКЗИ», подписанным ФГУП НТЦ «Атлас», КриптоПро, Фактор-ТС, МО ПНИЭИ, Инфотекс, СпбРЦЗИ, Криптоком и Р-Альфа. Целью этого соглашения является обеспечение совместимости продукции и решений разных производителей.

Авторы выражают свою признательность

Компании Microsoft Corporation Russia за предоставление информации о продукции и решениях компании, а также технические консультации в части PKI.

Компаниям RSA Security Russia и Демос за активное сотрудничество и помощь при создании этого документа.

Peter Gutmann за полезную программу dumpasn1.

Russ Hously (Vigil Security, LLC, housley@vigilsec.com) и Василию Сахарову (Демос, svp@dol.ru), побудившим авторов на создание этого документа.

Derek Atkins (IHTFP Consulting, derek@ihtfp.com) и его супруге, Heather Anne Harrison, за то, что сделали документ читаемым.

Григорию Чудову за прохождение процесса IETF для этого документа.

Документ основан на результатах компании КриптоПро. Любое существенное использование этого документа должно отмечать компанию КриптоПро. Компания просит при цитировании или упоминании этого документа, обозначать его CRYPTO-PRO CPALGS.

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

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

[GOST28147] «Система обработки информации. Защита криптографическая. Алгоритм криптографического преобразования», ГОСТ 28147-89, Государственный стандарт Союза ССР, Издательство стандартов, 1989.

[GOSTR341094] «Информационная технология. Криптографическая защита информации. Процедура выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма.», ГОСТ Р 34.10-94, Государственный стандарт Российской Федерации, Госстандарт России, 1994.

[GOSTR341001] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.», ГОСТ Р 34.10-2001, Государственный стандарт Российской Федерации, Госстандарт России, 2001.

[GOSTR341194] «Информационная технология. Криптографическая защита информации. Функция хеширования.», ГОСТ Р 34.11-94, Государственный стандарт Российской Федерации, Госстандарт России, 1994.

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

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

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

[Schneier95] B. Schneier, Applied cryptography, second edition, John Wiley & Sons, Inc., 1995.

[RFDSL] «Об электронной цифровой подписи»¹⁰, 10 января 2002 г., №1-ФЗ¹¹

[RFLLIC] «О лицензировании отдельных видов деятельности», 8 августа 2001 г., №128-ФЗ¹²

[CRYPTOLIC] «Об утверждении положений о лицензировании отдельных видов деятельности, связанных с шифровальными (криптографическими) средствами», 23 сентября 2002 г., Постановление правительства РФ №691¹³

[X.660] ITU-T Recommendation X.660 Information Technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997.

[RFC4134] Hoffman, P., «Examples of S/MIME Messages», RFC 4134, July 2005.

[TLS] Dierks, T. and C. Allen, «The TLS Protocol Version 1.0», RFC 2246, January 1999.

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

Vladimir Popov

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: vpopov@cryptopro.ru

Igor Kurepkin

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: kure@cryptopro.ru

Serguei Leontiev

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: lse@cryptopro.ru

Grigorij Chudov

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: chudov@cryptopro.ru

Alexandr Afanasiev

Factor-TS

office 711, 14, Presnenskij val,

Moscow, 123557, Russian Federation

EMail: afa1@factor-ts.ru

Nikolaj Nikishin

Infotecs GmbH

p/b 35, 80-5, Leningradskij prospekt,

Moscow, 125315, Russian Federation

EMail: nikishin@infotecs.ru

Boleslav Izotov

FGUE STC «Atlas»

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: izotov@nii.voskhod.ru

Elena Minaeva

MD PREI

build 3, 6A, Vtoroj Troitskij per.,

Moscow, Russian Federation

EMail: evminaeva@mail.ru

Serguei Murugov

R-Alpha

4/1, Raspletina,

Moscow, 123060, Russian Federation

EMail: msm@top-cross.ru

Igor Ovcharenko

MD PREI

Office 600, 14, B.Novodmitrovskaya,

Moscow, Russian Federation

EMail: igori@mo.msk.ru

Igor Ustinov

Cryptocom

office 239, 51, Leninskij prospekt,

Moscow, 119991, Russian Federation

EMail: igus@cryptocom.ru

Anatolij Erkin

SPRCIS (SPbRCZI)

1, Obrucheva,

St.Petersburg, 195220, Russian Federation

EMail: erkin@nevsky.net

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

Network Working Group                                            D. Levi
Request for Comments: 4363                               Nortel Networks
Obsoletes: 2674                                            D. Harrington
Category: Standards Track                             Effective Software
                                                            January 2006

Определения управляемых объектов для мостов с классами трафика, фильтрацией групповых пакетов и виртуальными ЛВС

Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

Документ определяет часть MIB¹ для использования с протоколами сетевого управления в сетях TCP/IP. В частности, определены два модуля MIB для управления возможностями мостов MAC, определенных стандартами IEEE 802.1D-1998 (TM) MAC Bridges и IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) для мостов между сегментами локальных сетей (ЛВС или LAN²). Один модуль MIB определяет объекты для управления компонентами Traffic Classes и Enhanced Multicast Filtering стандартов IEEE 802.1D-1998 и P802.1t-2001 (TM). Другой модуль MIB определяет объекты для управления виртуальными ЛВС (VLAN) в соответствии с IEEE 802.1Q-2003, P802.1u (TM) и P802.1v (TM).

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

Этот документ дополняет RFC 4188 и заменяет RFC 2674.

1. Стандартная модель сетевого управления Internet

Подробный обзор документов, описывающих стандартную схему управления Internet, приведен в разделе 7 RFC 3410 [RFC3410].

Доступ к объектам управления осуществляется через виртуальное хранилище, называемое MIB. Для работы с объектами MIB обычно используется простой протокол сетевого управления (SNMP³). Объекты MIB определяются с использованием механизмов, описанных в SMI⁴. Этот документ задает модуль MIB, соответствующий спецификации SMIv2, которая описана в STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] и STD 58, RFC 2580 [RFC2580].

2. Обзор

Базовым устройством многих сетей является мост (Bridge). Такие устройства используются для соединения ЛВС ниже сетевого уровня и часто их называют коммутаторами уровня 2 (layer 2 switch).

В стандарте IEEE 802.1D-1998 [802.1D] определен метод организации прозрачных мостов, а управляемые объекты для таких мостов определены в BRIDGE-MIB [BRIDGE-MIB].

Исходный стандарт IEEE 802.1D был дополнен IEEE 802.1Q-2003 [802.1Q] для поддержки виртуальных ЛВС на бахе мостов, где одна физическая ЛВС, построенная на основе мостов, может использоваться для поддержки множества логических ЛВС на базе мостов, каждая из которых предоставляет примерно такой же сервис как определено в IEEE 802.1D. Такие виртуальные ЛВС (VLAN⁵) являются составной частью коммутируемых ЛВС. Можно рассматривать как группу конечных станций в разных сегментах ЛВС, которые могут взаимодействовать, как будто они расположены в одной ЛВС. Стандарт IEEE 802.1Q определяет виртуальные ЛВС на базе портов (port-based VLAN), где принадлежность определяется портом моста, через который принимаются кадры данных, и виртуальные ЛВС на базе порта и протокола (port-and-protocol-based VLAN), где принадлежность определяется принявшим кадр данных портом моста и идентификатором протокола в кадре. Этот документ определяет объекты, требуемые для управления port-based VLAN в мостах.

Документ дополняет RFC 4188 [BRIDGE-MIB] и заменяет собой RFC 2674 [RFC2674].

2.1. Область действия

Определенный в этом документе модуль MIB включает полнофункциональный набор управляемых объектов, который пытается соответствовать набору управляемых объектов определенному в IEEE 802.1D и IEEE 802.1Q. Однако в соответствии с духом модели SNMP принято субъективное решение опустить объекты, реализация которых слишком «дорога» и не так «существенна» для обработки отказов и управления конфигурацией. Опущенные объекты перечислены в разделе 3.

Отметим, что в исходном модуле BRIDGE-MIB [RFC1493] использовались перечисленные ниже принципы включения объектов в модуль BRIDGE-MIB.

1. Начинать с небольшого набора объектов и дополнять его лишь по необходимости.

2. Каждый объект должен быть важен для настройки или контроля отказов.

3. Учет текущего использования и полезности.

4. Ограничение общего числа объектов.

5. Исключение объектов, которые выводятся из других объектов этого или других модулей MIB.

6. Сокращение числа критических сессий. Рекомендуется использовать один счетчик на критическую секцию уровня.

3. Структура MIB

Этот документ определяет объекты, дополняющие модуль BRIDGE-MIB [BRIDGE-MIB]. В параграфе 3.4.3 приведены некоторые рекомендации по использованию объектов BRIDGE-MIB на устройствах, реализующих определенные здесь расширения.

Расширенный модуль P-BRIDGE-MIB определяет объекты управления для расширений, связанных с классами трафика и фильтрацией группового трафика, которые определены в IEEE 802.1D-1998 [802.1D], включая элемент управления Restricted Group Registration, определенный в IEEE P802.1t [802.1t].

Модуль для виртуального моста Q-BRIDGE-MIB определяет объекты для расширений VLAN, определенных в IEEE 802.1Q-2003 [802.1Q], включая элемент управления Restricted VLAN Registration, определенный в IEEE P802.1u [802.1u], и расширение VLAN Classification by Protocol and Port, определенное в IEEE P802.1v [802.1v].

3.1. Структура модуля Extended Bridge MIB

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

3.1.1. Связь с управляемыми объектами IEEE 802.1D-1998

В этом параграфе рассмотрены связи с объектами, определенными в IEEE 802.1D-1998 [802.1D]. Отмечены также объекты, которые не были включены в этот модуль MIB.

Некоторые объекты, определенные в IEEE 802.1D-1998, были включены в модуль MIB виртуального моста без включения в этот модуль — записи в dot1qTpGroupTable, dot1qForwardAllTable и dot1qForwardUnregisteredTable требуются для виртуальных ЛВС на базе мостов с дополнительным индексированием (например, по VLAN или FDB⁶). Устройствам, не реализующим виртуальных ЛВС на базе мостов, но реализующим службы Extended Forwarding, определенные в IEEE 802.1D (т. е. динамическое определение групповых адресов и требований по обслуживанию групп в базе данных фильтрации), следует реализовать эти таблицы с фиксированным значением dot1qFdbId (рекомендуется 1) или dot1qVlanIndex (рекомендуется 1). Устройствам, поддерживающим службы Extended Filtering, следует поддерживать таблицы dot1qTpGroupTable, dot1qForwardAllTable и dot1qForwardUnregisteredTable.

dot1dExtBase

Bridge

  dot1dDeviceCapabilities
    dot1dExtendedFilteringServices
    dot1dTrafficClasses
  dot1dTrafficClassesEnabled

  dot1dGmrpStatus
dot1dPriority
  dot1dPortPriorityTable

  .ApplicantAdministrativeControl

    dot1dPortDefaultUserPriority
    dot1dPortNumTrafficClasses

  .UserPriority

  dot1dUserPriorityRegenTable        
    dot1dUserPriority
    dot1dRegenUserPriority

  .UserPriorityRegenerationTable

  dot1dTrafficClassTable
    dot1dTrafficClassPriority
    dot1dTrafficClass

  .TrafficClassTable

  dot1dPortOutboundAccessPriorityTable
dot1dPortOutboundAccessPriority
dot1dGarp
  dot1dPortGarpTable

  .OutboundAccessPriorityTable

    dot1dPortGarpJoinTime

  .JoinTime

    dot1dPortGarpLeaveTime

  .LeaveTime

    dot1dPortGarpLeaveAllTime
dot1dGmrp
  dot1dPortGmrpTable

  .LeaveAllTime

    dot1dPortGmrpStatus

  .ApplicantAdministrativeControl

    dot1dPortGmrpFailedRegistrations

  .FailedRegistrations

    dot1dPortGmrpLastPduOrigin

  .OriginatorOfLastPDU

    dot1dPortRestrictedGroupRegistration

Restricted Group Registration (Ref. IEEE 802.1t 10.3.2.3)

dot1dTp
  dot1dTpHCPortTable

     dot1dTpHCPortInFrames

  .BridgePort.FramesReceived

     dot1dTpHCPortOutFrames

    .ForwardOutBound

     dot1dTpHCPortInDiscards          
  dot1dTpPortOverflowTable

    .DiscardInbound

    dot1dTpPortInOverflowFrames

  .BridgePort.FramesReceived

    dot1dTpPortOutOverflowFrames

    .ForwardOutBound

    dot1dTpPortInOverflowDiscards

    .DiscardInbound

Ниже перечислены объекты управления IEEE 802.1D-1998, не включенные в Bridge MIB, с указанием причин.

3.1.2. Связь с управляемыми объектами IEEE 802.1Q

В этом параграфе указаны связи с управляемыми объектами, определенными в IEEE 802.1Q-2003 [802.1Q]. Эти объекты включены в данный модуль MIB, поскольку они обеспечивают естественную совместимость с соответствующими объектами IEEE 802.1D.

dot1dExtBase

Bridge

  dot1dDeviceCapabilities
    dot1qStaticEntryIndividualPort  
    dot1qIVLCapable
    dot1qSVLCapable
    dot1qHybridCapable

  5.2 implementation options

    dot1qConfigurablePvidTagging
    dot1dLocalVlanCapable
  dot1dPortCapabilitiesTable
    dot1dPortCapabilities

  12.10.1.1 read bridge vlan config

       dot1qDot1qTagging

5.2 implementation options

       dot1qConfigurableAcceptableFrameTypes

5.2 implementation options

        dot1qIngressFiltering

5.2 implementation options

3.1.3. Субдерево dot1dExtBase

Это субдерево содержит объекты, применимые для всех мостов, которые поддерживают классы трафика и групповую фильтрацию IEEE 802.1D-1998 [802.1D]. Оно включает настройку конфигурации протоколов GARP⁷ и GMRP⁸.

3.1.4. Субдерево dot1dPriority

Это субдерево содержит объекты для настройки и отчетности о состоянии основанных на приоритете механизмов очередей в мосту. Это включает трактовку user_priority на уровне порта, отображение user_priority в кадрах на внутренние классы трафика, а также выходные user_priority и access_priority.

3.1.5. Субдерево dot1dGarp

Это субдерево содержит объекты для настройки и отчетности протокола GARP.

3.1.6. Субдерево dot1dGmrp

Это субдерево содержит объекты для настройки и отчетности протокола GMRP.

3.1.7. Таблица dot1dTpHCPortTable

Эта таблица расширяет субдерево dot1dTp из BRIDGE-MIB [BRIDGE-MIB] и содержит объекты статистики на уровне портов для высокоскоростных интерфейсов.

3.1.8. Таблица dot1dTpPortOverflowTable

Эта таблица расширяет субдерево dot1dTp из BRIDGE-MIB [BRIDGE-MIB] и содержит объекты статистики старших битов счетчиков на уровне портов для высокоскоростных интерфейсов, когда 32-битовые счетчики переполняются.

3.2. Структура модуля Virtual Bridge MIB

Объекты этого модуля MIB собраны в субдеревья, каждое из которых представляет набор связанных между собой объектов. Общая структура и объекты показаны ниже. Некоторые управляемые объекты из BRIDGE-MIB [BRIDGE-MIB] требуют специального индексирования при использовании в среде с VLAN, поэтому они, по сути, дублируются объектами Virtual Bridge MIB с другими индексами.

3.2.1. Связь с управляемыми объектами IEEE 802.1Q

В этом параграфе показаны связи между управляемыми объектами, определенными а разделе 12 стандарта IEEE 802.1Q-2003 [802.1Q] со ссылками на параграфы стандарта. Указаны также объекты, не включенные в этот модуль MIB.

Примечание. В отличие от IEEE 802.1D-1998 стандарт IEEE 802.1Q-2003 [802.1Q] не задает точного синтаксиса для набора управляемых объектов. В приведенной ниже таблице указаны номера параграфов с описаниями операций управления в разделе 12 упомянутого стандарта.

dot1qBase

  dot1qVlanVersionNumber

  dot1qMaxVlanId

  dot1qMaxSupportedVlans

  dot1qNumVlans

  dot1qGvrpStatus

dot1qTp
  dot1qFdbTable
    dot1qFdbId

    dot1qFdbDynamicCount
  dot1qTpFdbTable
    dot1qTpFdbAddress
    dot1qTpFdbPort
    dot1qTpFdbStatus

  dot1qTpGroupTable                
    dot1qTpGroupAddress
    dot1qTpGroupEgressPorts
    dot1qTpGroupLearnt

  dot1qForwardAllTable             
    dot1qForwardAllPorts
    dot1qForwardAllStaticPorts
    dot1qForwardAllForbiddenPorts

  dot1qForwardUnregisteredTable    
    dot1qForwardUnregisteredPorts
    dot1qForwardUnregisteredStaticPorts
    dot1qForwardUnregisteredForbiddenPorts
dot1qStatic

  dot1qStaticUnicastTable

    dot1qStaticUnicastAddress
    dot1qStaticUnicastReceivePort
    dot1qStaticUnicastAllowedToGoTo
    dot1qStaticUnicastStatus

  dot1qStaticMulticastTable

    dot1qStaticMulticastAddress
    dot1qStaticMulticastReceivePort
    dot1qStaticMulticastStaticEgressPorts
    dot1qStaticMulticastForbiddenEgressPorts
    dot1qStaticMulticastStatus
dot1qVlan
  dot1qVlanNumDeletes

dot1qVlanCurrentTable

    dot1qVlanTimeMark
    dot1qVlanIndex
    dot1qVlanFdbId
    dot1qVlanCurrentEgressPorts
    dot1qVlanCurrentUntaggedPorts
    dot1qVlanStatus
    dot1qVlanCreationTime

  dot1qVlanStaticTable

    dot1qVlanStaticName            
    dot1qVlanStaticEgressPorts
    dot1qVlanForbiddenEgressPorts
    dot1qVlanStaticUntaggedPorts
    dot1qVlanStaticRowStatus
  dot1qNextFreeLocalVlanIndex

  dot1qPortVlanTable

    dot1qPvid

    dot1qPortAcceptableFrameTypes

    dot1qPortIngressFiltering

    dot1qPortGvrpStatus            
    dot1qPortGvrpFailedRegistrations
    dot1qPortGvrpLastPduOrigin

    dot1qPortRestrictedVlanRegistration

  dot1qPortVlanStatisticsTable     
    dot1qTpVlanPortInFrames
    dot1qTpVlanPortOutFrames
    dot1qTpVlanPortInDiscards
    dot1qTpVlanPortInOverflowFrames
    dot1qTpVlanPortOutOverflowFrames
    dot1qTpVlanPortInOverflowDiscards

  dot1qPortVlanHCStatisticsTable   
    dot1qTpVlanPortHCInFrames
    dot1qTpVlanPortHCOutFrames
    dot1qTpVlanPortHCInDiscards

  dot1qLearningConstraintsTable

    dot1qConstraintVlan
    dot1qConstraintSet
    dot1qConstraintType
    dot1qConstraintStatus
  dot1qConstraintSetDefault
  dot1qConstraintTypeDefault

dot1vProtocol

  dot1vProtocolGroupTable

    dot1vProtocolTemplateFrameType
    dot1vProtocolTemplateProtocolValue

    dot1vProtocolGroupId             
    dot1vProtocolGroupRowStatus

  dot1vProtocolPortTable             
    dot1vProtocolPortGroupId
    dot1vProtocolGroupVid
    dot1vProtocolPortRowStatus

Ниже перечислены объекты управления IEEE 802.1Q, которые не были включены в Bridge MIB, с указанием причин.

3.2.2. Субдерево dot1qBase

Это субдерево содержит объекты, применимые ко всем мостам, реализующим IEEE 802.1Q VLAN.

3.2.3. Субдерево dot1qTp

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

3.2.4. Субдерево dot1qStatic

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

3.2.5. Субдерево dot1qVlan

Это субдерево содержит объекты для управления работой и отчетов о состоянии VLAN, известных мосту. Это включает управление статически настроенными VLAN, а также информирование о VLAN, обнаруженных другими способами (например, GVRP⁹). Субдерево также управляет настройкой и отчетами о состоянии на уровне портов относящихся к VLAN объектов. Обеспечивается также управление ограничениями при обнаружении VLAN.

3.3. Текстовые соглашения

Различные рабочие группы подготовили документы проектами стандартных MIB (например, [RFC2613] и [RFC3318]), которые содержат объекты и текстовые соглашения для представления идентификаторов VLAN-ID¹⁰ [802.1Q]. Новые определения появляются в разных документах (например, [RFC4323] и [RFC4149]). К сожалению в результате этого возникло множество разных определений для одних и тех же частей информации управления. Это может приводить к путанице и ненужному усложнению. Для решения этой проблемы в Q-BRIDGE-MIB определены три новых текстовых соглашения — VlanIdOrAny, VlanIdOrNone и VlanIdOrAnyOrNone. Эти соглашения следует использовать в модулях MIB для одинакового представления VLAN-ID.

Эти текстовые соглашения обеспечивают способ указать для объекта MIB привязку к конкретной, любой или никакой VLAN. В качестве примера использования текстовых сообщений рассмотри объект MIB с SYNTAX VlanIdOrAnyOrNone, задающий VLAN, для которой воспринимаются входные пакеты определенного протокола. Такой объект позволяет настроить устройство на восприятие пакетов этого протокола, полученных с конкретным тегом 802.1q, любым тегом или без тега 802.1q. Отметим, что для объектов MIB, определенных с помощью одного из этих текстовых соглашений, следует разъяснять значение «любая VLAN» и/или «без VLAN» в описании (DESCRIPTION).

3.4. Связь с другими MIB

Как было отмечено выше, некоторые объекты управления IEEE 802.1D не включены этот модуль MIB, по причине перекрытия с объектами MIB, применимых к мостам, реализующим этот модуль MIB.

3.4.1. Связь с SNMPv2-MIB

SNMPv2-MIB [RFC3418] определяет объекты, которые в общем случае применимы к управляемым устройствам. Эти объекты применимы к устройству в целом, независимо от того, является ли функциональность моста единственной или лишь частью полной функциональности.

Полная поддержка объектов управления 802.1D требует реализации объектов sysDescr и sysUpTime модуля SNMPv2-MIB. Отметим, что соответствие текущему модулю SNMPv2-MIB требует реализации дополнительных объектов и уведомлений, как указано в RFC 3418 [RFC3418].

3.4.2. Связь с IF-MIB

IF-MIB [RFC2863] требует от любого модуля MIB, дополняющего IF-MIB, прояснять конкретные области в IF-MIB. Эти области намеренно оставлены в IF-MIB не определенными, чтобы избежать ненужных ограничений MIB, исключающих управления некоторыми типами сред.

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

IF-MIB [RFC2863] определяет объекты для управления сетевыми интерфейсами. Сетевой интерфейс рассматривается как подключенный к «подсети» (subnetwork). Отметим, что термин «подсеть» в данном случае имеет иное значение, нежели подсеть в смысле схем адресации, используемых в стеке протоколов IP. В этом документе для таких подсетей используется термин «сегмент», независимо от того, является подсеть сегментом Ethernet, кольцом, каналом WAN или виртуальным устройством X.25.

Полная поддержка управляемых объектов 802.1D требует реализации объектов IF-MIB ifIndex, ifType, ifDescr, ifPhysAddress и ifLastChange. Отметим, что для совместимости с текущим модулем IF-MIB требуется реализация дополнительных объектов и уведомлений, как указано в RFC 2863 [RFC2863].

Неявным в этом модуле BRIDGE-MIB является обозначение портов моста. Каждый порт связывается с одним из интерфейсов в субдереве interfaces и в большинстве случаев каждый порт связан со своим интерфейсом. Однако в некоторых случаях с одним интерфейсом может быть связано множество портов. Примером может служить ситуация, когда несколько портов, связанных взаимно-однозначно с виртуальными устройствами X.25, относятся к одному интерфейсу.

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

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

Таким образом, BRIDGE-MIB (и, в частности, счетчики модуля) применимы лишь к подмножеству данных на интерфейсах устройства, которые принимаются или передаются с использованием функций моста. Все такие данные принимаются и передаются через порты моста.

3.4.2.1. Многоуровневая модель

В этом документе предполагается интерпретация субдерева Interfaces в соответствии с IF-MIB [RFC2863], где сказано, что таблица интерфейсов (ifTable) содержит информацию об управляемых интерфейсных ресурсах и каждый уровень ниже уровня межсетевого взаимодействия на сетевом интерфейсе рассматривается как интерфейс.

В этом документе не принимается каких-либо допущений о том, что внутри объекта VLAN, созданные как элементы dot1qVlanCurrentTable путем настройки через систему управления с помощью dot1qVlanStaticTable или динамическим способом (например, с помощью GVRP), представлены также записями в ifTable.

Когда запись содержит элементы вышележащего протокола (например, интерфейсы уровня IP, передающие и принимающие трафик VLAN), их следует представлять в ifTable как интерфейсы типа propVirtual(53). Определяемые протоколом типы вроде l3ipxvlan(137) не следует применять здесь, поскольку нет возможности выполнения мостом какой-либо фильтрации протоколов до доставки этим виртуальным интерфейсам.

3.4.2.2. Таблица ifStackTable

Кроме того, IF-MIB [RFC2863] определяет таблицу ifStackTable для описания связей между логическими интерфейсами внутри элемента. Предполагается, что разработчики будут применять эту таблицу для описания привязки (например) интерфейсов IP к физическим портам, хотя присутствие VLAN делает представление менее совершенным в плане показа связности. Таблица ifStackTable не может представлять все возможности стандарта IEEE 802.1Q для мостов VLAN, поскольку различает привязки VLAN на входных и выходных портах — эти отношения могут быть или не быть симметричными, тогда как Interface MIB Evolution предполагает симметрию привязок для передачи и приема. Это требует определения других управляемых объектов для настройки принадлежности портов к VLAN.

3.4.2.3. Таблица ifRcvAddressTable

Эта таблица содержит все MAC-адреса (индивидуальные, групповые, широковещательные), для которых интерфейс будет принимать пакеты и передавать на вышележащий уровень для локального потребления. Отметим, что в это число не включаются адреса для протоколов канального уровня типа STP, GMRP, GVRP. Формат адресов в ifRcvAddressAddress совпадает с форматом для ifPhysAddress.

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

3.4.3. Связь с BRIDGE-MIB

В этом параграфе определено как следует представлять объекты, определенные в модуле BRIDGE-MIB [BRIDGE-MIB], для устройств, реализующих расширение. Некоторые из старых объектов мало полезны в таких устройствах, но должны быть реализованы для совместимости со старыми версиями.

3.4.3.1. Субдерево dot1dBase

Это субдерево содержит объекты, применимые ко всем типам мостов. Интерпретация субдерева не изменена.

3.4.3.2. Субдерево dot1dStp

Это субдерево содержит объекты, которые показывают состояние моста применительно к протоколу STP. Интерпретация субдерева не изменена.

3.4.3.3. Субдерево dot1dTp

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

В устройстве, работающем с одной Filtering Database, интерпретация этого субдерева не изменена.

Для устройств, поддерживающих множество Filtering Database, интерпретация субдерева описана ниже.

dot1dTpLearnedEntryDiscards

Число случаев переполнения любой FDB.

dot1dTpAgingTime

Применимо ко всем Filtering Database.

dot1dTpFdbTable

MAC-адреса, определенные на каждом порту, независимо от Filtering Database, определившей адрес. Если адрес определен несколькими базами фильтров на одном порту, он учитывается лишь один раз. Если адрес определен несколькими базами на разных портах, он учитывается на одном (любом) из подходящих портов.

dot1dTpPortTable

Это таблица относится к одному порту и не подвержена влиянию множества Filtering Database или VLAN. Счетчикам следует учитывать кадры, принятые или переданные для всех VLAN. Отметим, что в этом документе для высокоскоростных портов определены эквиваленты 64-битовых счетчиков и других объектов, представляющие старшие 32 бита. Имеются операторы соответствия для указания применимых скоростей интерфейсов.

3.4.3.4. Субдерево dot1dStatic

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

В устройстве, работающем с одной Filtering Database, интерпретация этого субдерева не изменена.

Для устройств, поддерживающих множество Filtering Database, интерпретация субдерева описана ниже.

dot1dStaticTable

Записи, считываемые из этой таблицы, включают все статические записи всех Filtering Database. Записи для одного MAC-адреса и приемного порта из нескольких Filtering Database должны включаться лишь один раз, поскольку они служат индексом таблицы. На устройствах с множеством Forwarding Database таблица должна быть доступна лишь для чтения. Доступ для записи следует обеспечивать через dot1qStaticUnicastTable и dot1qStaticMulticastTable, как определено в этом документе.

3.4.3.5. Дополнения к BRIDGE-MIB

В дополнение к BRIDGE-MIB [BRIDGE-MIB] данный модуль включает:

1. поддержку множества классов трафика и динамической фильтрации по групповым адресам в соответствии с IEEE 802.1D-1998 [802.1D];

2. поддержку VLAN на основе мостов в соответствии с IEEE 802.1Q-2003 [802.1Q];

3. поддержку 64-битовых вариантов счетчиков BRIDGE-MIB [BRIDGE-MIB] для портов.

4. Определения Extended Bridge MIB

P-BRIDGE-MIB DEFINITIONS ::= BEGIN

-- -------------------------------------------------------------
-- MIB for IEEE 802.1p devices
-- -------------------------------------------------------------

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Counter64
        FROM SNMPv2-SMI
    TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF
    dot1dTp, dot1dTpPort, dot1dBridge,
    dot1dBasePortEntry, dot1dBasePort
        FROM BRIDGE-MIB;

pBridgeMIB MODULE-IDENTITY
    LAST-UPDATED "200601090000Z"
    ORGANIZATION "IETF Bridge MIB Working Group"
    CONTACT-INFO
        "Email:  bridge-mib@ietf.org
                 ietfmibs@ops.ietf.org

                 David Levi
         Postal: Nortel Networks
                 4655 Great America Parkway
                 Santa Clara, CA 95054
                 USA
                 Phone: +1 865 686 0432
                 Email: dlevi@nortel.com

                 David Harrington
         Postal: Effective Software
                 50 Harding Rd.
                 Portsmouth, NH 03801
                 USA
                 Phone: +1 603 436 8634
                 Email: ietfdbh@comcast.net

                 Les Bell
         Postal: Hemel Hempstead, Herts. HP2 7YU
                 UK
          Email: elbell@ntlworld.com

                 Vivian Ngai
          Email: vivian_ngai@acm.org

                 Andrew Smith
         Postal: Beijing Harbour Networks
                 Jiuling Building
                 21 North Xisanhuan Ave.
                 Beijing, 100089
                 PRC
            Fax: +1 415 345 1827
          Email: ah_smith@acm.org

                 Paul Langille
         Postal: Newbridge Networks
                 5 Corporate Drive
                 Andover, MA 01810
                 USA
          Phone: +1 978 691 4665
          Email: langille@newbridge.com

                 Anil Rijhsinghani
         Postal: Accton Technology Corporation
                 5 Mount Royal Ave
                 Marlboro, MA 01752
                 USA
          Phone:
          Email: anil@accton.com

                 Keith McCloghrie
         Postal: Cisco Systems, Inc.
                 170 West Tasman Drive
                 San Jose, CA 95134-1706
                 USA
          Phone: +1 408 526 5260
          Email: kzm@cisco.com"
    DESCRIPTION
        "Модуль Bridge MIB Extension для управления Priority
        and Multicast Filtering в соответствии с IEEE 802.1D-1998,
        включая Restricted Group Registration из IEEE 802.1t-2001.

        Copyright (C) The Internet Society (2006). Эта версия модуля
        MIB является частью RFC 4363, где правовые аспекты описаны
        полностью."
    REVISION     "200601090000Z"
    DESCRIPTION
         "Добавлен объект dot1dPortRestrictedGroupRegistration.
          Отменены объекты pBridgePortGmrpGroup и pBridgeCompliance,
          добавлены pBridgePortGmrpGroup2 и pBridgeCompliance2."
    REVISION     "199908250000Z"
    DESCRIPTION
         "Модуль Bridge MIB Extension для управления Priority
          and Multicast Filtering в соответствии с IEEE 802.1D-1998.

          Первая версия, опубликованная в RFC 2674."
    ::= { dot1dBridge 6 }

pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 }

-- -------------------------------------------------------------
-- Текстовые соглашения
-- -------------------------------------------------------------

EnabledStatus ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Простое значение статуса для объекта."
    SYNTAX      INTEGER { enabled(1), disabled(2) }

-- -------------------------------------------------------------
-- subtrees in the P-BRIDGE MIB
-- -------------------------------------------------------------

dot1dExtBase    OBJECT IDENTIFIER ::= { pBridgeMIBObjects 1 }
dot1dPriority   OBJECT IDENTIFIER ::= { pBridgeMIBObjects 2 }
dot1dGarp       OBJECT IDENTIFIER ::= { pBridgeMIBObjects 3 }
dot1dGmrp       OBJECT IDENTIFIER ::= { pBridgeMIBObjects 4 }

-- -------------------------------------------------------------
-- Субдерево dot1dExtBase 
-- -------------------------------------------------------------

dot1dDeviceCapabilities OBJECT-TYPE
    SYNTAX      BITS {
        dot1dExtendedFilteringServices(0),
        dot1dTrafficClasses(1),
        dot1qStaticEntryIndividualPort(2),
        dot1qIVLCapable(3),
        dot1qSVLCapable(4),
        dot1qHybridCapable(5),
        dot1qConfigurablePvidTagging(6),
        dot1dLocalVlanCapable(7)
    }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Указывает дополнительные части IEEE 802.1D и 802.1Q,
        реализованные устройством и управляемые через эту MIB.
        Возможности, разрешаемые на уровне порта, указываются
        в dot1dPortCapabilities.

        dot1dExtendedFilteringServices(0),
                              -- можно фильтровать отдельные
                              -- групповые адреса, контролируемые 
                              -- GMRP.
        dot1dTrafficClasses(1),
                              -- можно сопоставить приоритет 
                              -- пользователя с множество классов
                              -- трафика.
        dot1qStaticEntryIndividualPort(2),
                              -- dot1qStaticUnicastReceivePort и
                              -- dot1qStaticMulticastReceivePort
                              -- могут представлять отличные от 0
                              -- записи.
        dot1qIVLCapable(3),   -- Independent VLAN Learning (IVL).
        dot1qSVLCapable(4),   -- Shared VLAN Learning (SVL).
        dot1qHybridCapable(5),-- одновременно IVL и SVL.
        dot1qConfigurablePvidTagging(6),
                              -- возможность поддержки реализацией
                              -- переписывать принятые по умолчанию
                              -- настройки PVID и выходной статус
                              -- (VLAN-Tagged или Untagged) на
                              -- каждом порту.
        dot1dLocalVlanCapable(7)
                              -- можно поддерживать множество локальных
                              -- мостов за пределами 802.1Q VLAN."
    REFERENCE
        "ISO/IEC 15802-3 Section 5.2,
        IEEE 802.1Q/D11 Section 5.2, 12.10.1.1.3/b/2"
    ::= { dot1dExtBase 1 }

dot1dTrafficClassesEnabled OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Значение true(1) показывает что классы трафика разрешены на
        этом мосту. Значение false(2) говорит, что мост использует
        один уровень приоритета для всех классов трафика.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    DEFVAL      { true }
    ::= { dot1dExtBase 2 }

dot1dGmrpStatus OBJECT-TYPE
    SYNTAX      EnabledStatus
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Административный статус, запрошенный системой управления
        для GMRP. Значение enabled(1) указывает, что GMRP следует
        включить на устройстве во всех VLAN и для всех портов,
        где это не отключено специально. При значении disabled(2)
        GMRP отключен во всех VLAN и на всех портах, а все пакеты
        GMRP будут пересылаться без обработки. Этот объект влияет
        на машины состояний Applicant и Registrar. Переход от 
        disabled(2) к enabled(1) будут сбрасывать машины состояний 
        GMRP на всех портах.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    DEFVAL      { enabled }
    ::= { dot1dExtBase 3 }

-- -------------------------------------------------------------
-- Таблица возможностей порта
-- -------------------------------------------------------------

dot1dPortCapabilitiesTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dPortCapabilitiesEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица, содержащая информацию о возможностях 
        для каждого порта, связанного с этим мостом."
    ::= { dot1dExtBase 4 }

dot1dPortCapabilitiesEntry OBJECT-TYPE
    SYNTAX      Dot1dPortCapabilitiesEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация о возможностях порта, заданного 
        индексом dot1dBasePort."
    AUGMENTS { dot1dBasePortEntry }
    ::= { dot1dPortCapabilitiesTable 1 }

Dot1dPortCapabilitiesEntry ::=
    SEQUENCE {
        dot1dPortCapabilities
            BITS
    }

dot1dPortCapabilities OBJECT-TYPE
    SYNTAX      BITS {
        dot1qDot1qTagging(0),
        dot1qConfigurableAcceptableFrameTypes(1),
        dot1qIngressFiltering(2)
    }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Указывает части IEEE 802.1D и 802.1Q (необязательные
        на уровне порта), которые реализованы данным устройством
        и управляются через этот модуль MIB.

        dot1qDot1qTagging(0), -- поддержка тегов 802.1Q VLAN для
                              -- кадров и GVRP.
        dot1qConfigurableAcceptableFrameTypes(1),
                              -- разрешает менять значения
                              -- dot1qPortAcceptableFrameTypes.
        dot1qIngressFiltering(2)
                              -- поддержка отбрасывания принятых
                              -- портом кадров, для которых 
                              -- классификация VLAN не включает
                              -- данный порт Port в набор Member."
    REFERENCE
        "ISO/IEC 15802-3 Section 5.2,
        IEEE 802.1Q/D11 Section 5.2"
    ::= { dot1dPortCapabilitiesEntry 1 }

-- -------------------------------------------------------------
-- Субдерево dot1dPriority 
-- -------------------------------------------------------------

-- -------------------------------------------------------------
-- Таблица приоритетов
-- -------------------------------------------------------------

dot1dPortPriorityTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dPortPriorityEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с информацией для каждого порта, связанного с
        данным прозрачным мостом."
    ::= { dot1dPriority 1 }

dot1dPortPriorityEntry OBJECT-TYPE
    SYNTAX      Dot1dPortPriorityEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Список принятых по умолчанию приоритетов пользователей на
        каждом порту прозрачного моста. Индексируется dot1dBasePort."
    AUGMENTS { dot1dBasePortEntry }
    ::= { dot1dPortPriorityTable 1 }

Dot1dPortPriorityEntry ::=
    SEQUENCE {
        dot1dPortDefaultUserPriority
            Integer32,
        dot1dPortNumTrafficClasses
            Integer32
    }

dot1dPortDefaultUserPriority OBJECT-TYPE
    SYNTAX      Integer32 (0..7)
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Принятый по умолчанию входной User Priority для порта.
        Влияет лишь на среды (типа Ethernet) без естественного
        User Priority.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    ::= { dot1dPortPriorityEntry 1 }

dot1dPortNumTrafficClasses OBJECT-TYPE
    SYNTAX      Integer32 (1..8)
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Число выходных классов трафика, поддерживаемых портом.
        Объект может быть сделан доступным лишь для чтения.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    ::= { dot1dPortPriorityEntry 2 }

-- -------------------------------------------------------------
-- Таблица регенерации приоритетов пользователей
-- -------------------------------------------------------------

dot1dUserPriorityRegenTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dUserPriorityRegenEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Список Regenerated User Priority для каждого User
        Priority на каждом порту моста. Значение Regenerated
        User Priority может служить индексом таблицы Traffic
        Class для каждого входного порта. Влияет лишь на среды,
        поддерживающие User Priority. По умолчанию значения
        Regenerated User Priority совпадают с User Priority."
    REFERENCE
        "ISO/IEC 15802-3 Section 6.4"
    ::= { dot1dPriority 2 }

dot1dUserPriorityRegenEntry OBJECT-TYPE
    SYNTAX      Dot1dUserPriorityRegenEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Отображение входящих User Priority на Regenerated
        User Priority."
    INDEX   { dot1dBasePort, dot1dUserPriority }
    ::= { dot1dUserPriorityRegenTable 1 }

Dot1dUserPriorityRegenEntry ::=
    SEQUENCE {
        dot1dUserPriority
            Integer32,
        dot1dRegenUserPriority
            Integer32
    }

dot1dUserPriority OBJECT-TYPE
    SYNTAX      Integer32 (0..7)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "User Priority для кадра, принятого на этом порту."
    ::= { dot1dUserPriorityRegenEntry 1 }

dot1dRegenUserPriority OBJECT-TYPE
    SYNTAX      Integer32 (0..7)
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Regenerated User Priority на которое User Priority
        отображено для данного порта.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    ::= { dot1dUserPriorityRegenEntry 2 }

-- -------------------------------------------------------------
-- Таблица классов трафика
-- -------------------------------------------------------------

dot1dTrafficClassTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dTrafficClassEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица отображения User Priority на Traffic Class для
        пересылки мостом. Класс трафика указывается числом от
        0 до (dot1dPortNumTrafficClasses-1)."
    REFERENCE
        "ISO/IEC 15802-3 Table 7-2"
    ::= { dot1dPriority 3 }

dot1dTrafficClassEntry OBJECT-TYPE
    SYNTAX      Dot1dTrafficClassEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Отображение User Priority на Traffic Class."
    INDEX   { dot1dBasePort, dot1dTrafficClassPriority }
    ::= { dot1dTrafficClassTable 1 }

Dot1dTrafficClassEntry ::=
    SEQUENCE {
        dot1dTrafficClassPriority
            Integer32,
        dot1dTrafficClass
            Integer32
    }

dot1dTrafficClassPriority OBJECT-TYPE
    SYNTAX      Integer32 (0..7)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Значение Priority определенное для принятого кадра. 
        Это значение эквивалентно приоритету, указанному в 
        принятом кадре с тегом или одному из вычисленных 
        в зависимости от media-type приоритетов.

        Для кадров без тега, принятых из среды Ethernet, это
        значение равно dot1dPortDefaultUserPriority входного порта.

        Для кадров без тега, принятых не из среды Ethernet это
        значение равно dot1dRegenUserPriority для входного порта
        и определяемого средой приоритета пользователя."
    ::= { dot1dTrafficClassEntry 1 }

dot1dTrafficClass OBJECT-TYPE
    SYNTAX      Integer32 (0..7)
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Traffic Class, на который отображается принятый кадр.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    ::= { dot1dTrafficClassEntry 2 }

-- -------------------------------------------------------------
-- Outbound Access Priority Table
-- -------------------------------------------------------------

dot1dPortOutboundAccessPriorityTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dPortOutboundAccessPriorityEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица отображения Regenerated User Priority на Outbound
        Access Priority. Это фиксированное отображение для всех
        типов портов с двумя опциями для 802.5 Token Ring."
    REFERENCE
        "ISO/IEC 15802-3 Table 7-3"
    ::= { dot1dPriority 4 }

dot1dPortOutboundAccessPriorityEntry OBJECT-TYPE
    SYNTAX      Dot1dPortOutboundAccessPriorityEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Отображение Regenerated User Priority на Outbound Access Priority."
    INDEX   { dot1dBasePort, dot1dRegenUserPriority }
    ::= { dot1dPortOutboundAccessPriorityTable 1 }

Dot1dPortOutboundAccessPriorityEntry ::=
    SEQUENCE {
        dot1dPortOutboundAccessPriority
            Integer32
    }

dot1dPortOutboundAccessPriority OBJECT-TYPE
    SYNTAX      Integer32 (0..7)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Outbound Access Priority, на который отображается принятый кадр."
    ::= { dot1dPortOutboundAccessPriorityEntry 1 }

-- -------------------------------------------------------------
-- субдерево dot1dGarp
-- -------------------------------------------------------------

-- -------------------------------------------------------------
-- Таблица портов GARP
-- -------------------------------------------------------------

dot1dPortGarpTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dPortGarpEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица управляющей информации GARP для каждого порта в 
        мосту. Индексом таблицы служит dot1dBasePort."
    ::= { dot1dGarp 1 }

dot1dPortGarpEntry OBJECT-TYPE
    SYNTAX      Dot1dPortGarpEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Управляющая информация GARP для порта в мосту."
    AUGMENTS { dot1dBasePortEntry }
    ::= { dot1dPortGarpTable 1 }

Dot1dPortGarpEntry ::=
    SEQUENCE {
        dot1dPortGarpJoinTime
            TimeInterval,
        dot1dPortGarpLeaveTime
            TimeInterval,
        dot1dPortGarpLeaveAllTime
            TimeInterval
    }

dot1dPortGarpJoinTime OBJECT-TYPE
    SYNTAX      TimeInterval
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Время GARP Join в сотых долях секунды.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    DEFVAL      { 20 }
    ::= { dot1dPortGarpEntry 1 }

dot1dPortGarpLeaveTime OBJECT-TYPE
    SYNTAX      TimeInterval
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        " Время GARP в сотых долях секунды.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    DEFVAL      { 60 }
    ::= { dot1dPortGarpEntry 2 }

dot1dPortGarpLeaveAllTime OBJECT-TYPE
    SYNTAX      TimeInterval
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Время GARP LeaveAll в сотых долях секунды.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    DEFVAL      { 1000 }
    ::= { dot1dPortGarpEntry 3 }

-- -------------------------------------------------------------
-- The GMRP Port Configuration and Status Table
-- -------------------------------------------------------------

dot1dPortGmrpTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dPortGmrpEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица информации GMRP для управления и контроля состояний
        каждого порта в мосту. Дополняет dot1dBasePortTable."
    ::= { dot1dGmrp 1 }

dot1dPortGmrpEntry OBJECT-TYPE
    SYNTAX      Dot1dPortGmrpEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация GMRP для управления и контроля состояния порта."
    AUGMENTS { dot1dBasePortEntry }
    ::= { dot1dPortGmrpTable 1 }

Dot1dPortGmrpEntry ::=
    SEQUENCE {
        dot1dPortGmrpStatus
            EnabledStatus,
        dot1dPortGmrpFailedRegistrations
            Counter32,
        dot1dPortGmrpLastPduOrigin
            MacAddress,
        dot1dPortRestrictedGroupRegistration
            TruthValue
    }

dot1dPortGmrpStatus OBJECT-TYPE
    SYNTAX      EnabledStatus
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Административное состояние операции GMRP на данном порту. 
        Значение enabled(1) показывает, что GMRP разрешен на порту
        во всех VLAN, если dot1dGmrpStatus имеет значение enabled(1).
        Значение disabled(2) показывает, что GMRP отключен на порту
        для всех VLAN и принятые пакеты GMRP будут отбрасываться без
        уведомления, а регистрации GMRP из других портов не будут 
        распространяться. Установка значения enabled(1) будет
        сохраняться агентом, но будет воздействовать на операции 
        протокола GMRP лишь при dot1dGmrpStatus = enabled(1). Этот
        объект влияет на все машины состояния GMRP Applicant и
        Registrar на данном порту. Переход от disabled(2) к enabled(1)
        будет сбрасывать все машины состояний GMRP на данном порту.

        Значение этого объекта ДОЛЖНО сохраняться при 
        реинициализации системы управления."
    DEFVAL      { enabled }
    ::= { dot1dPortGmrpEntry 1 }

dot1dPortGmrpFailedRegistrations OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Общее число отказов при регистрации GMRP по любым причинам
        во всех VLAN на данном порту."
    ::= { dot1dPortGmrpEntry 2 }

dot1dPortGmrpLastPduOrigin OBJECT-TYPE
    SYNTAX      MacAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "MAC-адрес отправителя последнего сообщения GMRP принятого портом."
    ::= { dot1dPortGmrpEntry 3 }

dot1dPortRestrictedGroupRegistration OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Состояние Restricted Group Registration на данном порту.
         Значение true(1) указывает, что создание новой динамической
         записи разрешено лишь при наличии Static Filtering Entry 
         для рассматриваемой VLAN, в которой Registrar Administrative 
         Control имеет значение Normal Registration.

         Значение этого объекта ДОЛЖНО сохраняться при 
         переинициализации системы управления."
    REFERENCE
        "IEEE 802.1t clause 10.3.2.3, 14.10.1.3."
    DEFVAL      { false }
    ::= { dot1dPortGmrpEntry 4 }

-- -------------------------------------------------------------
--  Таблица высокоскоростных портов для прозрачного моста
-- -------------------------------------------------------------

dot1dTpHCPortTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dTpHCPortEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с информацией для каждого высокоскоростного 
        порта, связанного с данным прозрачным мостом."
    ::= { dot1dTp 5 }

dot1dTpHCPortEntry OBJECT-TYPE
    SYNTAX      Dot1dTpHCPortEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Статистика для каждого скоростного порта в прозрачном мосту."
    INDEX   { dot1dTpPort }
    ::= { dot1dTpHCPortTable 1 }

Dot1dTpHCPortEntry ::=
    SEQUENCE {
        dot1dTpHCPortInFrames
            Counter64,
        dot1dTpHCPortOutFrames
            Counter64,
        dot1dTpHCPortInDiscards
            Counter64
    }

dot1dTpHCPortInFrames OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число кадров, полученных мостом из его сегмента. Отметим,
        что кадры, полученные на соответствующем этому порту
        интерфейсе, учитываются этим объектом лишь в том случае, 
        когда они относятся к протоколу, обрабатываемому локальной
        функцией моста (включая кадры управления мостом)."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1dTpHCPortEntry 1 }

dot1dTpHCPortOutFrames OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число кадров, переданных мостом в свой сегмент. Отметим,
        что кадры, переданные соответствующим этому порту интерфейсом,
        учитываются этим объектом лишь в том случае, 
        когда они относятся к протоколу, обрабатываемому локальной
        функцией моста (включая кадры управления мостом)."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1dTpHCPortEntry 2 }

dot1dTpHCPortInDiscards OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число принятых данным портом из своего сегмента корректных
        кадров, которые были отброшены (т. е., отфильтрованы)
        процессом пересылки (Forwarding Process)."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1dTpHCPortEntry 3 }

-- ----------------------------------------------------
--  Верхняя часть High-Capacity Port Table для прозрачных мостов
-- ----------------------------------------------------

dot1dTpPortOverflowTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1dTpPortOverflowEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица со старшими битами счетчиков статистики для портов,
        связанных с этим прозрачным мостом, которые имеют скоростные
        интерфейсы, как определено в соответствиях для данной таблицы.
        Таблица обеспечивает способ считывания значений 64-битовых
        счетчиков для агентов, поддерживающих лишь SNMPv1.

        Отметим, что разделение старших и младших битов счетчиков 
        создает риск потери информации о переполнении младших битов в
        интервале между выборками. Менеджер должен осознавать это даже
        в рамках одного varbindlist при интерпретации результатов запроса
        асинхронных уведомлений."
    ::= { dot1dTp 6 }

dot1dTpPortOverflowEntry OBJECT-TYPE
    SYNTAX      Dot1dTpPortOverflowEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Старшие биты счетчиков статистики для высокоскоростного
        интерфейса прозрачного моста. Каждый объект связывается с
        соответствующим объектом dot1dTpPortTable, содержащим
        младшие биты того же счетчика."
    INDEX   { dot1dTpPort }
    ::= { dot1dTpPortOverflowTable 1 }

Dot1dTpPortOverflowEntry ::=
    SEQUENCE {
        dot1dTpPortInOverflowFrames
            Counter32,
        dot1dTpPortOutOverflowFrames
            Counter32,
        dot1dTpPortInOverflowDiscards
            Counter32
    }

dot1dTpPortInOverflowFrames OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число случаев переполнения счетчика dot1dTpPortInFrames."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1dTpPortOverflowEntry 1 }

dot1dTpPortOutOverflowFrames OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число случаев переполнения счетчика dot1dTpPortOutFrames."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1dTpPortOverflowEntry 2 }

dot1dTpPortInOverflowDiscards OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число случаев переполнения счетчика dot1dTpPortInDiscards."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1dTpPortOverflowEntry 3 }

-- -------------------------------------------------------------
-- IEEE 802.1p MIB — информация о соответствии
-- -------------------------------------------------------------

pBridgeConformance OBJECT IDENTIFIER ::= { pBridgeMIB 2 }

pBridgeGroups OBJECT IDENTIFIER ::= { pBridgeConformance 1 }

pBridgeCompliances OBJECT IDENTIFIER
    ::= { pBridgeConformance 2 }

-- -------------------------------------------------------------
-- блоки соответствия
-- -------------------------------------------------------------

pBridgeExtCapGroup OBJECT-GROUP
    OBJECTS {
        dot1dDeviceCapabilities,
        dot1dPortCapabilities
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, показывающих дополнительные возможности
        устройства."
    ::= { pBridgeGroups 1 }

pBridgeDeviceGmrpGroup OBJECT-GROUP
    OBJECTS {
        dot1dGmrpStatus
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, обеспечивающих на уровне устройства 
        контроль для расширенных служб Multicast Filtering."
    ::= { pBridgeGroups 2 }

pBridgeDevicePriorityGroup OBJECT-GROUP
    OBJECTS {
        dot1dTrafficClassesEnabled
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, обеспечивающих на уровне устройства 
        для служб Priority."
    ::= { pBridgeGroups 3 }

pBridgeDefaultPriorityGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortDefaultUserPriority
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, определяющих User Priority, применимые
        к каждому порту для среды, не поддерживающей User Priority."
    ::= { pBridgeGroups 4 }

pBridgeRegenPriorityGroup OBJECT-GROUP
    OBJECTS {
        dot1dRegenUserPriority
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, определяющих User Priority, применимые
        к каждому порту для среды, поддерживающей User Priority."
    ::= { pBridgeGroups 5 }

pBridgePriorityGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortNumTrafficClasses,
        dot1dTrafficClass
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, определяющих классы трафика в рамках
        моста для каждого определенного User Priority."
    ::= { pBridgeGroups 6 }

pBridgeAccessPriorityGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortOutboundAccessPriority
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, определяющих зависящий от среды
        уровень доступа на выходе для каждого приоритета."
    ::= { pBridgeGroups 7 }

pBridgePortGarpGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortGarpJoinTime,
        dot1dPortGarpLeaveTime,
        dot1dPortGarpLeaveAllTime
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, определяющих на уровне порта информацию
        для управления и статуса операции GARP."
    ::= { pBridgeGroups 8 }

pBridgePortGmrpGroup OBJECT-GROUP
    OBJECTS {
        dot1dPortGmrpStatus,
        dot1dPortGmrpFailedRegistrations,
        dot1dPortGmrpLastPduOrigin
    }
    STATUS      deprecated
    DESCRIPTION
        "Набор объектов, определяющих на уровне порта информацию
        для управления и статуса операции GMRP."
    ::= { pBridgeGroups 9 }

pBridgeHCPortGroup OBJECT-GROUP
    OBJECTS {
        dot1dTpHCPortInFrames,
        dot1dTpHCPortOutFrames,
        dot1dTpHCPortInDiscards
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, обеспечивающих 64-битовые счетчики
         статистики для высокоскоростных портов моста."
    ::= { pBridgeGroups 10 }

pBridgePortOverflowGroup OBJECT-GROUP
    OBJECTS {
        dot1dTpPortInOverflowFrames,
        dot1dTpPortOutOverflowFrames,
        dot1dTpPortInOverflowDiscards
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, обеспечивающих счетчики переполнения
        статистики для высокоскоростных портов моста."
    ::= { pBridgeGroups 11 }

pBridgePortGmrpGroup2 OBJECT-GROUP
    OBJECTS {
        dot1dPortGmrpStatus,
        dot1dPortGmrpFailedRegistrations,
        dot1dPortGmrpLastPduOrigin,
        dot1dPortRestrictedGroupRegistration
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, обеспечивающих на уровне порта информацию
        для управления и статуса операции GMRP."
    ::= { pBridgeGroups 12 }

-- -------------------------------------------------------------
-- заявления о соответствии
-- -------------------------------------------------------------

pBridgeCompliance MODULE-COMPLIANCE
    STATUS  deprecated
    DESCRIPTION
        "Заявление о поддержке устройством расширенных услуг 
        Priority и Multicast Filtering."

    MODULE
        MANDATORY-GROUPS { pBridgeExtCapGroup }

        GROUP       pBridgeDeviceGmrpGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, поддерживающих 
            приложение GMRP, определенное IEEE 802.1D Extended 
            Filtering Services."

        GROUP       pBridgeDevicePriorityGroup
        DESCRIPTION
            "Эта группа обязательна только для устройств,
            поддерживающих операции приоритетной пересылки, 
            определенные IEEE 802.1D."

        GROUP       pBridgeDefaultPriorityGroup
        DESCRIPTION
            "Эта группа обязательна только для устройств,
            поддерживающих операции приоритетной пересылки,
            определенные расширенными службами мостов, для 
            сред типа Ethernet, не поддерживающих User Priority."

        GROUP       pBridgeRegenPriorityGroup
        DESCRIPTION
            "Эта группа обязательна только для устройств,
            поддерживающих операции приоритетной пересылки,
            определенные IEEE 802.1D, для сред, поддерживающих
            User Priority, например, IEEE 802.5."

        GROUP       pBridgePriorityGroup
        DESCRIPTION
            "Эта таблица требуется лишь для устройств, поддерживающих
            операции приоритетной пересылки, определенные в IEEE 802.1D."

        GROUP       pBridgeAccessPriorityGroup
        DESCRIPTION
            "Эта группа не обязательна и относится лишь к устройствам, 
            поддерживающим операции приоритетной пересылки, определенные
            в IEEE 802.1D, и имеющим интерфейсы в среды с естественной 
            поддержкой Access Priority типа IEEE 802.5."

        GROUP       pBridgePortGarpGroup
        DESCRIPTION
            "Эта группа требуется для устройств, поддерживающих любые
            приложения GARP, типа GMRP, определенного расширенными
            службами фильтрации 802.1D или GVRP, определенного 802.1Q
            (см. заявление о совместимости для GVRP в Q-BRIDGE-MIB)."

        GROUP       pBridgePortGmrpGroup
        DESCRIPTION
            "Эта группа требуется для устройств, поддерживающих
            приложение GMRP, как определено службами расширенной 
            фильтрации IEEE 802.1D."

        GROUP       pBridgeHCPortGroup
        DESCRIPTION
            "Поддержка этой группы обязательна для устройств, в которых 
            порты моста отображаются на интерфейсы, имеющие значение 
            соответствующего экземпляра ifSpeed больше 650000000 бит/с."

        GROUP       pBridgePortOverflowGroup
        DESCRIPTION
            "Поддержка этой группы в устройстве обязательна лишь для 
            портов моста, которые отображаются на интерфейсы со
            значением соответствующего экземпляра ifSpeed более 
            650000000 бит/с."

        OBJECT      dot1dPortNumTrafficClasses
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется."

        OBJECT      dot1dTrafficClass
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется."

        OBJECT      dot1dRegenUserPriority
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется."
       ::= { pBridgeCompliances 1 }

pBridgeCompliance2 MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
        "Заявление о поддержке устройством расширенных служб Priority
        и Multicast Filtering."

    MODULE
        MANDATORY-GROUPS { pBridgeExtCapGroup }

        GROUP       pBridgeDeviceGmrpGroup
        DESCRIPTION
            "Эта группа обязательна для устройство, поддерживающих 
            приложение GMRP, определенное IEEE 802.1D Extended 
            Filtering Services."

        GROUP       pBridgeDevicePriorityGroup
        DESCRIPTION
            "Эта группа обязательна лишь для устройств, поддерживающих
            операции приоритетной пересылки, определенные в IEEE 802.1D."

        GROUP       pBridgeDefaultPriorityGroup
        DESCRIPTION
            " Эта группа обязательна лишь для устройств, поддерживающих
            операции приоритетной пересылки, определенные расширенными
            службами моста с типами сред, например, Ethernet, не 
            поддерживающими User Priority."

        GROUP       pBridgeRegenPriorityGroup
        DESCRIPTION
            "Эта группа обязательна лишь для устройств, поддерживающих
            операции приоритетной пересылки, определенные в IEEE 802.1D
            и имеющих интерфейсы в среду с естественной поддержкой 
            User Priority, например, IEEE 802.5."

        GROUP       pBridgePriorityGroup
        DESCRIPTION
            "Эта группа обязательна лишь для устройств, поддерживающих
            операции приоритетной пересылки, определенные в IEEE 802.1D."

        GROUP       pBridgeAccessPriorityGroup
        DESCRIPTION
            "Эта группа не обязательна и относится лишь к устройствам,
            поддерживающим операции приоритетной пересылки, определенные
            IEEE 802.1D, и имеющим  интерфейсы в среду с естественной 
            поддержкой Access Priority, например, IEEE 802.5."

        GROUP       pBridgePortGarpGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, поддерживающих любые
            приложения GARP, например, GMRP, определенный расширенными
            службами фильтрации 802.1D, или GVRP, определенный 802.1Q
            (см. заявление о соответствии для GVRP в Q-BRIDGE-MIB)."

        GROUP       pBridgePortGmrpGroup2
        DESCRIPTION
            " Эта группа обязательна для устройств, поддерживающих
            приложение GMRP в соответствии с IEEE 802.1D Extended
            Filtering Services."

        GROUP       pBridgeHCPortGroup
        DESCRIPTION
            "Поддержка этой группы обязательна лишь для устройств, 
            порты моста в которых отображаются на интерфейсы, имеющие
            значение соответствующего экземпляра ifSpeed
            более 650000000 бит/с."

        GROUP       pBridgePortOverflowGroup
        DESCRIPTION
            "Поддержка этой группы в устройстве обязательна лишь для 
            портов моста, которые отображаются на интерфейсы со
            значением соответствующего экземпляра ifSpeed более 
            650000000 бит/с."

        OBJECT      dot1dPortNumTrafficClasses
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется."

        OBJECT      dot1dTrafficClass
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется."

        OBJECT      dot1dRegenUserPriority
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется."
       ::= { pBridgeCompliances 2 }

END

5. Определения для Virtual Bridge MIB

Q-BRIDGE-MIB DEFINITIONS ::= BEGIN

-- -------------------------------------------------------------
-- MIB для устройств IEEE 802.1Q
-- -------------------------------------------------------------

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    Counter32, Counter64, Unsigned32, TimeTicks, Integer32
        FROM SNMPv2-SMI
    RowStatus, TruthValue, TEXTUAL-CONVENTION, MacAddress
        FROM SNMPv2-TC
    SnmpAdminString
        FROM SNMP-FRAMEWORK-MIB
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF
    dot1dBridge, dot1dBasePortEntry, dot1dBasePort
        FROM BRIDGE-MIB
    EnabledStatus
        FROM P-BRIDGE-MIB
    TimeFilter
        FROM RMON2-MIB;

qBridgeMIB MODULE-IDENTITY
    LAST-UPDATED "200601090000Z"
    ORGANIZATION "IETF Bridge MIB Working Group"
    CONTACT-INFO
        "Email:  Bridge-mib@ietf.org
                 ietfmibs@ops.ietf.org

                 David Levi
         Postal: Nortel Networks
                 4655 Great America Parkway
                 Santa Clara, CA 95054
                 USA
         Phone:  +1 865 686 0432
         Email:  dlevi@nortel.com

                 David Harrington
         Postal: Effective Software
                 50 Harding Rd.
                 Portsmouth, NH 03801
                 USA
         Phone:  +1 603 436 8634
         Email:  ietfdbh@comcast.net

                 Les Bell
         Postal: Hemel Hempstead, Herts. HP2 7YU
                 UK
          Email: elbell@ntlworld.com

                 Andrew Smith
         Postal: Beijing Harbour Networks
                 Jiuling Building
                 21 North Xisanhuan Ave.
                 Beijing, 100089
                 PRC
            Fax: +1 415 345 1827
          Email: ah_smith@acm.org

                 Paul Langille
         Postal: Newbridge Networks
                 5 Corporate Drive
                 Andover, MA 01810
                 USA
          Phone: +1 978 691 4665
          Email: langille@newbridge.com

                 Anil Rijhsinghani
         Postal: Accton Technology Corporation
                 5 Mount Royal Ave
                 Marlboro, MA 01752
                 USA
          Phone:
          Email: anil@accton.com

                 Keith McCloghrie
         Postal: Cisco Systems, Inc.
                 170 West Tasman Drive
                 San Jose, CA 95134-1706
                 USA
          Phone: +1 408 526 5260
          Email: kzm@cisco.com"
    DESCRIPTION
        "Модуль VLAN Bridge MIB для управления виртуальными
        ЛВС на базе мостов, определенными в IEEE 802.1Q-2003,
        включая Restricted Vlan Registration из 
        IEEE 802.1u-2001 и Vlan Classification из
        IEEE 802.1v-2001.

        Copyright (C) The Internet Society (2006). Эта версия модуля
        MIB является частью RFC 4363, где правовая информация дана
        полностью."
    REVISION     "200601090000Z"
    DESCRIPTION
         "Добавлены TEXTUAL-CONVENTION для Vlan,
          dot1qPortRestrictedVlanRegistration, субдерево dot1vProtocol,
          qBridgeClassificationDeviceGroup, qBridgePortGroup2,
          qBridgeClassificationPortGroup, and qBridgeCompliance2.
          Разъяснены dot1qForwardAllStaticPorts,
          qPortAcceptableFrameTypes и qBridgeCompliance.
          Отменены qBridgePortGroup и qBridgeCompliance."

    REVISION     "199908250000Z"
    DESCRIPTION
         " Модуль VLAN Bridge MIB для управления виртуальными
         ЛВС на базе мостов, определенными в IEEE 802.1Q-1998.

         Первоначальная версия, опубликованная в RFC 2674."
    ::= { dot1dBridge 7 }

qBridgeMIBObjects OBJECT IDENTIFIER ::= { qBridgeMIB 1 }

-- -------------------------------------------------------------
-- Текстовые соглашения
-- -------------------------------------------------------------

PortList ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Каждый октет этого значения задает набор из 8 портов,
        где первый октет соответствует портам 1 — 8, второй - 
        портам 9 — 16 и т. д. В каждом октете старший бит 
        представляет порт с меньшим номером, а младший - с 
        большим. Таким образом, каждый порт моста представлен 
        одним битом в значении данного объекта. Установленный (1)
        бит показывает, что порт включен в набор, сброшенный (0)
        указывает исключение."
    SYNTAX      OCTET STRING

VlanIndex ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS      current
    DESCRIPTION
        "Значение, используемое для индекса таблиц на уровне VLAN,
        значения 0 и 4095 не разрешены. Значения из диапазона 1 - 
        4094, включительно представляют IEEE 802.1Q VLAN-ID с
        глобальной значимостью в данном домене мостов (см. текстовое
        соглашение VlanId). Значения больше 4095 представляют VLAN 
        с локальной по отношению к конкретному агенту значимостью
        (т. е. без назначения глобального VLAN-ID). Такие VLAN
        выходят за рамки IEEE 802.1Q, но удобны для однотипного 
        управления с использованием этого модуля MIB."
    SYNTAX      Unsigned32

VlanId ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS      current
    DESCRIPTION
        "VLAN-ID, однозначно указывающий VLAN. Это 12-битовый
        идентификатор VLAN-ID, используемый в заголовке VLAN Tag.
        Диапазон определяется спецификацией REFERENCE."
    REFERENCE
        "IEEE Std 802.1Q 2003 Edition, Virtual Bridged
        Local Area Networks."
    SYNTAX      Integer32 (1..4094)

VlanIdOrAny ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    DESCRIPTION
        "VLAN-ID, однозначно указывающий конкретную или любую 
        VLAN. Специальное значение 4095 служит шаблоном для 
        любой VLAN. Это может применяться в любой ситуации, где
        объект или запись таблицы должны указывать на конкретную
        или любую VLAN.

        Отметим, что объекту MIB, определенному с использованием
        этого TEXTUAL-CONVENTION, следует разъяснять смысл термина
        «любая VLAN» (т. е. специального значения 4095)."
    SYNTAX       Integer32 (1..4094 | 4095)

VlanIdOrNone ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    DESCRIPTION
        "VLAN-ID, однозначно указывающий конкретную или VLAN или
        отсутствие VLAN. Специальное значение 0 служит для индикации
        отсутствия (или неиспользования) VLAN-ID. Это может 
        применяться в любой ситуации, где объект или запись таблицы 
        должны указывать на конкретную VLAN или отсутствие VLAN.

        Отметим, что объекту MIB, определенному с использованием
        этого TEXTUAL-CONVENTION, следует разъяснять смысл термина
        «нет VLAN» (т. е. специального значения 0)."
    SYNTAX       Integer32 (0 | 1..4094)

VlanIdOrAnyOrNone ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS       current
    DESCRIPTION
        "VLAN-ID, однозначно указывающий конкретную или любую VLAN,
        а также отсутствие VLAN. Специальные значения 0 и 4095
        описаны выше в текстовых соглашениях VlanIdOrAny и
        VlanIdOrNone.

        Отметим, что объекту MIB, определенному с использованием
        этого TEXTUAL-CONVENTION, следует разъяснять смысл терминов
        «любая VLAN» и «нет VLAN» (т. е. специального значения 0 и 4095)."
        0 and 4095)."
    SYNTAX       Integer32 (0 | 1..4094 | 4095)

-- -------------------------------------------------------------
-- субдеревья в Q-BRIDGE MIB
-- -------------------------------------------------------------

dot1qBase       OBJECT IDENTIFIER ::= { qBridgeMIBObjects 1 }
dot1qTp         OBJECT IDENTIFIER ::= { qBridgeMIBObjects 2 }
dot1qStatic     OBJECT IDENTIFIER ::= { qBridgeMIBObjects 3 }
dot1qVlan       OBJECT IDENTIFIER ::= { qBridgeMIBObjects 4 }
dot1vProtocol   OBJECT IDENTIFIER ::= { qBridgeMIBObjects 5 }

-- -------------------------------------------------------------
-- субдерево dot1qBase 
-- -------------------------------------------------------------

dot1qVlanVersionNumber OBJECT-TYPE
    SYNTAX      INTEGER {
                    version1(1)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Номер версии IEEE 802.1Q, поддерживаемой устройством."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.1.1"
    ::= { dot1qBase 1 }

dot1qMaxVlanId OBJECT-TYPE
    SYNTAX      VlanId
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Максимальное значение IEEE 802.1Q VLAN-ID, поддерживаемое
        устройством."
    REFERENCE
        "IEEE 802.1Q/D11 Section 9.3.2.3"
    ::= { dot1qBase 2 }

dot1qMaxSupportedVlans OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Максимальное число IEEE 802.1Q VLAN, поддерживаемых устройством."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.1.1"
    ::= { dot1qBase 3 }

dot1qNumVlans OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Текущее число IEEE 802.1Q VLAN, сконфигурированных на устройстве."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.1.1"
    ::= { dot1qBase 4 }

dot1qGvrpStatus OBJECT-TYPE
    SYNTAX      EnabledStatus
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Административный статус, запрошенный системой управления
        для GVRP. Значение enabled(1) показывает, что GVRP следует
        включить на устройстве для всех портов, на которых протокол
        не отключен явно. При значении disabled(2) протокол GVRP
        отключен на всех портах и все пакеты GVRP будут пересылаться
        без обработки. Этот объект влияет на все машины состояний GVRP
        Applicant и Registrar. Переход от disabled(2) к enabled(1) будет
        сбрасывать все машины состояния GVRP на всех портах.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    DEFVAL      { enabled }
    ::= { dot1qBase 5 }

-- -------------------------------------------------------------
-- субдерево dot1qTp 
-- -------------------------------------------------------------

-- -------------------------------------------------------------
-- текущая таблица Filtering Database
-- -------------------------------------------------------------

dot1qFdbTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qFdbEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с конфигурационной и управляющей информацией для
        каждой Filtering Database, работающей в данный момент на
        устройстве. Записи в этой таблице появляются автоматически
        при назначении для VLAN идентификаторов FDB ID в таблице
        dot1qVlanCurrentTable."
    ::= { dot1qTp 1 }

dot1qFdbEntry OBJECT-TYPE
    SYNTAX      Dot1qFdbEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация о конкретной Filtering Database."
    INDEX   { dot1qFdbId }
    ::= { dot1qFdbTable 1 }

Dot1qFdbEntry ::=
    SEQUENCE {
        dot1qFdbId
            Unsigned32,
        dot1qFdbDynamicCount
            Counter32
    }

dot1qFdbId OBJECT-TYPE
    SYNTAX       Unsigned32
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
        "Отождествление данной Filtering Database."
    ::= { dot1qFdbEntry 1 }

dot1qFdbDynamicCount OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
        "Текущее число динамических записей в этой Filtering Database."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.1.1.3"
    ::= { dot1qFdbEntry 2 }

-- -------------------------------------------------------------
-- Множество Forwarding Database для прозрачных устройств 802.1Q 
-- Эта таблица дополняет dot1dTpFdbTable, определенную ранее для
-- устройств 802.1D, поддерживающих лишь одну Forwarding Database.
-- -------------------------------------------------------------

dot1qTpFdbTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qTpFdbEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с информацией об индивидуальных записях, для
        которых устройство имеет информацию о пересылке/фильтрации.
        Эта информация применяется прозрачным мостом для определения
        дальнейшей судьбы принятого кадра."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.7"
    ::= { dot1qTp 2 }

dot1qTpFdbEntry OBJECT-TYPE
    SYNTAX      Dot1qTpFdbEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация о конкретном индивидуальном MAC-адресе, для
        которого устройство имеет информацию о фильтрации или
        пересылке."
    INDEX   { dot1qFdbId, dot1qTpFdbAddress }
    ::= { dot1qTpFdbTable 1 }

Dot1qTpFdbEntry ::=
    SEQUENCE {
        dot1qTpFdbAddress
            MacAddress,
        dot1qTpFdbPort
            Integer32,
        dot1qTpFdbStatus
            INTEGER
    }

dot1qTpFdbAddress OBJECT-TYPE
    SYNTAX      MacAddress
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Индивидуальный MAC-адрес, для которого устройство имеет
        информацию о фильтрации и/или пересылке."
    ::= { dot1qTpFdbEntry 1 }

dot1qTpFdbPort OBJECT-TYPE
    SYNTAX      Integer32 (0..65535)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "0 или номер порта, на котором был обнаружен кадр с адресом
        отправителя, совпадающим с соответствующим экземпляром 
        dot1qTpFdbAddress. Значение 0, показывает, что номер порта
        не был определен, но устройство имеет какую-либо информацию
        о фильтрации/пересылке для этого адреса, например в
        dot1qStaticUnicastTable). Разработчикам рекомендуется
        задавать для этого объекта номер порта при его определении, 
        даже для адресов, у которых соответствующее значение 
        dot1qTpFdbStatus отличается от learned(3)."
    ::= { dot1qTpFdbEntry 2 }

dot1qTpFdbStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    other(1),
                    invalid(2),
                    learned(3),
                    self(4),
                    mgmt(5)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Статус данной записи, который может принимать значения:
            other(1) — ни одно из перечисленных ниже. Это может
                включать случай, когда объект другой MIB (не
                соответствующий экземпляр dot1qTpFdbPort и не
                запись dot1qStaticUnicastTable) будет служить
                для определения пересылки кадров, адресованных по
                соответствующему экземпляру dot1qTpFdbAddress.
            invalid(2) — запись больше не действует (устарела),
                но еще не удалена из таблицы.
            learned(3) — значение соответствующего экземпляра
                dot1qTpFdbPort было определено и используется.
            self(4) - значение соответствующего экземпляра
                dot1qTpFdbAddress представляет один из адресов 
                устройства. Соответствующий экземпляр
                dot1qTpFdbPort показывает порт устройства.
            mgmt(5) - значение соответствующего экземпляра
                dot1qTpFdbAddress является также значением
                имеющегося экземпляра dot1qStaticAddress."
    ::= { dot1qTpFdbEntry 3 }

-- -------------------------------------------------------------
-- таблица Dynamic Group Registration 
-- -------------------------------------------------------------

dot1qTpGroupTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qTpGroupEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с информацией о фильтрах для VLAN, настроенных на
        мосту (локальной или сетевой) системой управления или
        определенных динамически, которая задает набор портов, куда
        разрешено пересылать кадры, полученные VLAN для данной FDB
        и содержащие конкретный групповой адрес получателей."
    ::= { dot1qTp 3 }

dot1qTpGroupEntry OBJECT-TYPE
    SYNTAX      Dot1qTpGroupEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Данные фильтрации, настроенные для моста системой управления
        или определенные динамически, которые задают набор портов, 
        куда разрешено пересылать кадры, принятые в VLAN по адресу
        конкретной группы. Поддерживается также подмножество
        динамически определенных портов."
    INDEX   { dot1qVlanIndex, dot1qTpGroupAddress }
    ::= { dot1qTpGroupTable 1 }

Dot1qTpGroupEntry ::=
    SEQUENCE {
        dot1qTpGroupAddress
            MacAddress,
        dot1qTpGroupEgressPorts
            PortList,
        dot1qTpGroupLearnt
            PortList
    }

dot1qTpGroupAddress OBJECT-TYPE
    SYNTAX      MacAddress
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Групповой MAC-адрес получателя в кадре, к которому применяется
        данная информация о фильтрах."
    ::= { dot1qTpGroupEntry 1 }

dot1qTpGroupEgressPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Полный набор портов в данной VLAN, в которые кадры, 
        направленные по данному групповому MAC-адресу получателя,
        будут явно пересылаться. Этот набор не включает портов, 
        в которые пересылка для этого адреса происходит неявно,
        из списка dot1qForwardAllPorts."
    ::= { dot1qTpGroupEntry 2 }

dot1qTpGroupLearnt OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Подмножество портов dot1qTpGroupEgressPorts, которые
        были определены GMRP или иным динамическим механизмом, 
        в данной базе фильтрации."
    ::= { dot1qTpGroupEntry 3 }

-- -------------------------------------------------------------
-- субдерево Service Requirements 
-- -------------------------------------------------------------

dot1qForwardAllTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qForwardAllEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с информацией о пересылке для каждой VLAN,
        указывающая набор портов, к которым применима пересылка
        всех групповых кадров, заданной статически системой 
        управления или динамически определенной GMRP. В эту
        таблицу включается информация для всех созданных VLAN."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.2, 12.7.7"
    ::= { dot1qTp 4 }

dot1qForwardAllEntry OBJECT-TYPE
    SYNTAX      Dot1qForwardAllEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация о пересылке для VLAN, указывающая набор
        портов, в которые следует пересылать все групповые кадры,
        заданная статически или динамически определенная GMRP."
    INDEX   { dot1qVlanIndex }
    ::= { dot1qForwardAllTable 1 }

Dot1qForwardAllEntry ::=
    SEQUENCE {
        dot1qForwardAllPorts
            PortList,
        dot1qForwardAllStaticPorts
            PortList,
        dot1qForwardAllForbiddenPorts
            PortList
    }

dot1qForwardAllPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Полный набор портов данной VLAN, куда пересылаются все
        кадры с групповыми адресами. Учитываются порты, для 
        которых такая пересылка задана статически системой 
        управления или динамически определена протоколом GMRP."
    ::= { dot1qForwardAllEntry 1 }

dot1qForwardAllStaticPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Набор портов данной VLAN, в который пересылка кадров
        с групповыми адресами получателя задана системой управления.
        Порты из этого списка будут также присутствовать в списке 
        dot1qForwardAllPorts. Значение этого списка сохраняется
        после сброса устройства. Список применим лишь к портам,
        которые являются членами VLAN в соответствии со списком
        dot1qVlanCurrentEgressPorts. Порт может быть добавлен 
        в этот список, если он уже входит в набор портов 
        dot1qForwardAllForbiddenPorts. По умолчанию значением 
        списка служит строка единиц соответствующего размера для
        индикации стандартного поведения базовой фильтрации
        (т. е. все групповые кадры пересылаются во все порты).

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qForwardAllEntry 2 }

dot1qForwardAllForbiddenPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Набор заданных системой управления портов в данной VLAN,
        Для которых атрибут Service Requirement со значением 
        Forward All Multicast Groups не может динамически 
        регистрироваться GMRP. Это значение будет сохраняться при
        сбросе устройства. Порт может быть добавлен в этот список,
        если он уже включен в dot1qForwardAllStaticPorts. По 
        умолчанию значением является строка нулей подходящего размера.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qForwardAllEntry 3 }

dot1qForwardUnregisteredTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qForwardUnregisteredEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с информацией о пересылке для каждой VLAN,
        задающая набор портов, к которым применима пересылка 
        групповых кадров при отсутствии более конкретной
        информации. Этот список задается статически системой
        управления и динамически дополняется протоколом GMRP.
        Записи этого списка относятся ко всем созданным VLAN."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.2, 12.7.7"
    ::= { dot1qTp 5 }

dot1qForwardUnregisteredEntry OBJECT-TYPE
    SYNTAX      Dot1qForwardUnregisteredEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация о пересылке для VLAN, задающая набор портов,
        куда следует пересылать все групповые кадры при отсутствии
        более конкретной информации. Таблица задается статически 
        системой управления или динамически протоколом GMRP."
    INDEX   { dot1qVlanIndex }
    ::= { dot1qForwardUnregisteredTable 1 }

Dot1qForwardUnregisteredEntry ::=
    SEQUENCE {
        dot1qForwardUnregisteredPorts
            PortList,
        dot1qForwardUnregisteredStaticPorts
            PortList,
        dot1qForwardUnregisteredForbiddenPorts
            PortList
    }

dot1qForwardUnregisteredPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Полный набор портов данной VLAN, куда пересылаются
        групповые кадры при отсутствии более конкретной информации.
        Таблица включает порты, определенные динамически протоколом
        GMRP или статически заданные системой управления."
    ::= { dot1qForwardUnregisteredEntry 1 }

dot1qForwardUnregisteredStaticPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Заданный системой управления набор портов данной VLAN,
        куда пересылаются групповые кадры при отсутствии более
        конкретной информации. Порты этого списка будут также
        присутствовать в полном наборе dot1qForwardUnregisteredPorts.
        Список будет восстанавливаться при сбросе устройства. Порт
        нельзя добавить в этот список, если он уже включен в 
        dot1qForwardUnregisteredForbiddenPorts. По умолчанию список
        представляет собой строку нулей соответствующего размера,
        хотя это не влияет на установленное по умолчанию значение
        dot1qForwardAllStaticPorts.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qForwardUnregisteredEntry 2 }

dot1qForwardUnregisteredForbiddenPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Заданный системой управления набор портов данной VLAN,
        для которых атрибут Service Requirement в Forward
        Unregistered Multicast Groups не может быть динамически
        зарегистрирован GMRP. Значение будет восстанавливаться
        при сбросе устройства. Порт не может быть добавлен в этот
        список, если он уже включен в 
        dot1qForwardUnregisteredStaticPorts. По умолчанию значение
        представляет собой строку нулей соответствующего размера.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qForwardUnregisteredEntry 3 }

-- -------------------------------------------------------------
-- Статическая база фильтров по адресам получателей
-- -------------------------------------------------------------

dot1qStaticUnicastTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qStaticUnicastEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица, содержащая данные фильтрации индивидуальных
        MAC-адресов для каждой Filtering Database, настроенной
        в устройстве (локальной или сетевой) системой управления,
        и задающая набор портов, в которые разрешено пересылать
        кадры, принятые из конкретных портов для конкретных
        адресатов. Нулевое значение в этой таблице (в качестве 
        номера порта, принявшего кадры для конкретного адреса
        получателя) служит для обозначения всех портов, не 
        имеющих в таблице конкретной записи для этого адреса
        получателя. Записи относятся лишь к индивидуальным адресам."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.7,
        ISO/IEC 15802-3 Section 7.9.1"
    ::= { dot1qStatic 1 }

dot1qStaticUnicastEntry OBJECT-TYPE
    SYNTAX      Dot1qStaticUnicastEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Данные фильтрации, заданные в устройстве (локальной или
        сетевой) системой управления и указывающие набор портов,
        в которые разрешено пересылать кадры, полученные из конкретного
        порта для конкретного индивидуального адреса получателя."
    INDEX   {
        dot1qFdbId,
        dot1qStaticUnicastAddress,
        dot1qStaticUnicastReceivePort
    }
    ::= { dot1qStaticUnicastTable 1 }

Dot1qStaticUnicastEntry ::=
    SEQUENCE {
        dot1qStaticUnicastAddress
            MacAddress,
        dot1qStaticUnicastReceivePort
            Integer32,
        dot1qStaticUnicastAllowedToGoTo
            PortList,
        dot1qStaticUnicastStatus
            INTEGER
    }

dot1qStaticUnicastAddress OBJECT-TYPE
    SYNTAX      MacAddress
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "MAC-адрес получателя в кадре, к которому применяется 
        данный фильтр. Значением этого объекта должен быть
        индивидуальный адрес."
    ::= { dot1qStaticUnicastEntry 1 }

dot1qStaticUnicastReceivePort OBJECT-TYPE
    SYNTAX      Integer32 (0..65535)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "0 или номер порта, из которого должен быть принят кадр
        для применения данного фильтра. Нулевое значение указывает,
        что запись применима ко всем портам устройства, не имеющим
        другой применимой записи."
    ::= { dot1qStaticUnicastEntry 2 }

dot1qStaticUnicastAllowedToGoTo OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Набор портов, в которые будет пересылаться кадр с конкретным
        индивидуальным адресом, когда порт для этого получателя еще не
        определен. Задает также набор портов, на которых конкретный
        индивидуальный адрес может быть определен динамически. 
        dot1qTpFdbTable будет иметь эквивалентную запись с
        dot1qTpFdbPort = 0, пока это адрес не будет определен. При
        определении запись обновляется с указанием номера порта, где
        был замечен адрес. Это применимо лишь к портам, являющимся 
        членами VLAN, определенным в dot1qVlanCurrentEgressPorts. По
        умолчанию значением объекта является строка единиц
        подходящего размера.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    REFERENCE
        "IEEE 802.1Q/D11 Table 8-5, ISO/IEC 15802-3 Table 7-5"
    ::= { dot1qStaticUnicastEntry 3 }

dot1qStaticUnicastStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    other(1),
                    invalid(2),
                    permanent(3),
                    deleteOnReset(4),
                    deleteOnTimeout(5)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Статус данной записи, который может принимать значения:
            other(1) — запись продолжает использоваться, но условия,
                при которых она будет сохраняться, отличаются 
                от перечисленных ниже.
            invalid(2) — запись этого значения в объект будет заменять
                имеющееся значение.
            permanent(3) — запись используется в настоящее время и
                сохранится при следующей перезагрузке моста.
            deleteOnReset(4) - запись используется в настоящее время и
                будет сохраняться до следующей перезагрузки моста.
            deleteOnTimeout(5) - запись используется в настоящее время и
                будет сохраняться, пока не устареет.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    DEFVAL      { permanent }
    ::= { dot1qStaticUnicastEntry 4 }

dot1qStaticMulticastTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qStaticMulticastEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица, содержащая данные фильтрации для широковещательных
        и групповых MAC-адресов каждой VLAN, заданной в устройстве
        (локальной или сетевой) системой управления, в виде набора
        портов, куда разрешено пересылать кадры, принятые конкретными 
        портами для конкретного широковещательного или группового 
        адреса получателя. Нулевое значение (в качестве номера 
        приемного порта) служит для указания всех портов, которые не
        имеют в этой таблице более конкретной записи с для данного
        адреса получателя. Записи применимы лишь для широковещательных
        и групповых адресов."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.7, ISO/IEC 15802-3 Section 7.9.1"
    ::= { dot1qStatic 2 }

dot1qStaticMulticastEntry OBJECT-TYPE
    SYNTAX      Dot1qStaticMulticastEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Данные фильтрации, заданные в устройстве (локальной или
        сетевой) системой управления и представляющие набор портов,
        куда разрешено пересылать кадры, принятые конкретным портом для 
        данной VLAN с широковещательным или групповым адресом получателя."
    INDEX   {
        dot1qVlanIndex,
        dot1qStaticMulticastAddress,
        dot1qStaticMulticastReceivePort
    }
    ::= { dot1qStaticMulticastTable 1 }

Dot1qStaticMulticastEntry ::=
    SEQUENCE {
        dot1qStaticMulticastAddress
            MacAddress,
        dot1qStaticMulticastReceivePort
            Integer32,
        dot1qStaticMulticastStaticEgressPorts
            PortList,
        dot1qStaticMulticastForbiddenEgressPorts
            PortList,
        dot1qStaticMulticastStatus
            INTEGER
    }

dot1qStaticMulticastAddress OBJECT-TYPE
    SYNTAX      MacAddress
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "MAC-адрес получателя в кадре, к которому применяется этот
        фильтр. Адрес должен быть групповым или широковещательным."
    ::= { dot1qStaticMulticastEntry 1 }

dot1qStaticMulticastReceivePort OBJECT-TYPE
    SYNTAX      Integer32 (0..65535)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "0 или номер порта, принявшего кадр, к которому применяется
        этот фильтр. Нулевое значение указывает, что запись относится
        ко всем портам устройства, не имеющим другой применимой записи."
    ::= { dot1qStaticMulticastEntry 2 }

dot1qStaticMulticastStaticEgressPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Набор портов, в которые должны пересылаться кадры, принятые
        конкретным портом по конкретному широковещательному или
        групповому MAC-адресу, независимо от какой-либо динамической
        информации типа GMRP. Порт не может добавляться в этот набор,
        если он уже включен в dot1qStaticMulticastForbiddenEgressPorts.
        По умолчанию значением объекта является строка единиц 
        подходящего размера.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qStaticMulticastEntry 3 }

dot1qStaticMulticastForbiddenEgressPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Набор портов, в которые недопустимо пересылать кадры, принятые
        конкретным портом по конкретному широковещательному или
        групповому MAC-адресу, независимо от какой-либо динамической
        информации типа GMRP. Порт не может добавляться в этот набор,
        если он уже включен в dot1qStaticMulticastStaticEgressPorts.
        По умолчанию значением объекта является строка нулей 
        подходящего размера.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qStaticMulticastEntry 4 }

dot1qStaticMulticastStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    other(1),
                    invalid(2),
                    permanent(3),
                    deleteOnReset(4),
                    deleteOnTimeout(5)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Статус данной записи, который может принимать значения:
            other(1) — запись продолжает использоваться, но условия,
                при которых она будет сохраняться, отличаются 
                от перечисленных ниже.
            invalid(2) — запись этого значения в объект будет заменять
                имеющееся значение.
            permanent(3) — запись используется в настоящее время и
                сохранится при следующей перезагрузке моста.
            deleteOnReset(4) - запись используется в настоящее время и
                будет сохраняться до следующей перезагрузки моста.
            deleteOnTimeout(5) - запись используется в настоящее время и
                будет сохраняться, пока не устареет.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    DEFVAL      { permanent }
    ::= { dot1qStaticMulticastEntry 5 }

-- -------------------------------------------------------------
-- Текущая база данных VLAN
-- -------------------------------------------------------------

dot1qVlanNumDeletes OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "Число случаев удаления VLAN из  dot1qVlanCurrentTable
        (по любой причине). Если запись удаляется, восстанавливается
        и снова удаляется, счетчик увеличится на 2."
    ::= { dot1qVlan 1 }

dot1qVlanCurrentTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qVlanCurrentEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с текущей конфигурацией каждой VLAN, созданной в
        устройстве (локальной или сетевой) системой управления или
        динамически по запросу GVRP."
    ::= { dot1qVlan 2 }

dot1qVlanCurrentEntry OBJECT-TYPE
    SYNTAX      Dot1qVlanCurrentEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация для VLAN, созданной в устройстве (локальной или
        сетевой) системой управления или динамически по запросу GVRP."
    INDEX   { dot1qVlanTimeMark, dot1qVlanIndex }
    ::= { dot1qVlanCurrentTable 1 }

Dot1qVlanCurrentEntry ::=
    SEQUENCE {
        dot1qVlanTimeMark
            TimeFilter,
        dot1qVlanIndex
            VlanIndex,
        dot1qVlanFdbId
            Unsigned32,
        dot1qVlanCurrentEgressPorts
            PortList,
        dot1qVlanCurrentUntaggedPorts
            PortList,
        dot1qVlanStatus
            INTEGER,
        dot1qVlanCreationTime
            TimeTicks
    }

dot1qVlanTimeMark OBJECT-TYPE
    SYNTAX      TimeFilter
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "TimeFilter для данной записи. См. текстовое соглашение 
        TimeFilter, где описано как это работает."
    ::= { dot1qVlanCurrentEntry 1 }

dot1qVlanIndex OBJECT-TYPE
    SYNTAX      VlanIndex
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "VLAN-ID или другой идентификатор, относящийся к этой VLAN."
    ::= { dot1qVlanCurrentEntry 2 }

dot1qVlanFdbId OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Filtering Database, используемая данной VLAN. Это одно из
        значений dot1qFdbId в dot1qFdbTable, выделяемое устройством
        автоматически при создании VLAN — динамически с помощью GVRP
        или системой управления в dot1qVlanStaticTable. При выделении
        значений применяются ограничения, заданные для этой VLAN в
        dot1qLearningConstraintsTable."
    ::= { dot1qVlanCurrentEntry 3 }

dot1qVlanCurrentEgressPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Набор портов, передающих трафик для этой VLAN в кадрах
        с тегами или без тегов."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.2.1"
    ::= { dot1qVlanCurrentEntry 4 }

dot1qVlanCurrentUntaggedPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Набор портов, передающих трафик для этой VLAN в кадрах
        без тегов."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.2.1"
    ::= { dot1qVlanCurrentEntry 5 }

dot1qVlanStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    other(1),
                    permanent(2),
                    dynamicGvrp(3)
                }
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Статус данной записи, который может принимать значения:
            other(1) — запись продолжает использоваться, но условия,
                при которых она будет сохраняться, отличаются 
                от перечисленных ниже.
            permanent(2) — эта запись, соответствующая записи в
                dot1qVlanStaticTable, в данный момент используется и
                будет сохраняться после сброса устройства. Порты,
                перечисленные для этой записи, включают порты из 
                эквивалентной записи dot1qVlanStaticTable и определенные
                динамически порты.
            dynamicGvrp(3) — запись в данный момент используется и будет
                сохраняться, пока ее не удалит GVRP. Для этой VLAN нет
                статической записи и она будет удалена после выхода из 
                VLAN последнего порта."
    ::= { dot1qVlanCurrentEntry 6 }

dot1qVlanCreationTime OBJECT-TYPE
    SYNTAX      TimeTicks
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Значение sysUpTime в момент создания VLAN."
    ::= { dot1qVlanCurrentEntry 7 }

-- -------------------------------------------------------------
-- База статических VLAN 
-- -------------------------------------------------------------

dot1qVlanStaticTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qVlanStaticEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица со статической конфигурацией для каждой VLAN,
        созданной в устройстве (локальной или сетевой) системой
        управления. Все записи являются постоянными и будут
        восстанавливаться после перезагрузки устройства."
    ::= { dot1qVlan 3 }

dot1qVlanStaticEntry OBJECT-TYPE
    SYNTAX      Dot1qVlanStaticEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Статическая информация для VLAN, заданная в устройстве 
        (локальной или сетевой) системой управления."
    INDEX   { dot1qVlanIndex }
    ::= { dot1qVlanStaticTable 1 }

Dot1qVlanStaticEntry ::=
    SEQUENCE {
        dot1qVlanStaticName
            SnmpAdminString,
        dot1qVlanStaticEgressPorts
            PortList,
        dot1qVlanForbiddenEgressPorts
            PortList,
        dot1qVlanStaticUntaggedPorts
            PortList,
        dot1qVlanStaticRowStatus
            RowStatus
    }

dot1qVlanStaticName OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE (0..32))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Административно заданная строка, которая может служить
        для идентификации VLAN."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.2.1"
    ::= { dot1qVlanStaticEntry 1 }

dot1qVlanStaticEgressPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Набор портов, постоянно назначенных выходными для данной
        VLAN системой управления. Изменения битов этого объекта
        влияют на управление регистратором и фиксацию регистрации 
        для соответствующей машины состояний GVRP на уровне порта
        и VLAN. Порт не может быть добавлен в этот набор, если он
        уже включен в dot1qVlanForbiddenEgressPorts. По умолчанию
        значением этого объекта является строка нулей подходящего
        размера, указывающая отсутствие фиксации."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.7.3, 11.2.3.2.3"
    ::= { dot1qVlanStaticEntry 2 }

dot1qVlanForbiddenEgressPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Набор портов, для которых системой управления запрещено
        включение в выходной список для данной VLAN. Изменения этого
        объекта, вызывающие включение или исключение порта, влияют на
        на управление регистратором и фиксацию регистрации 
        для соответствующей машины состояний GVRP на уровне порта
        и VLAN. Порт не может быть добавлен в этот набор, если он
        уже включен в dot1qVlanStaticEgressPorts. По умолчанию
        значением этого объекта является строка нулей подходящего
        размера, исключающая все порты из числа запрещенных."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.7.7.3, 11.2.3.2.3"
    ::= { dot1qVlanStaticEntry 3 }

dot1qVlanStaticUntaggedPorts OBJECT-TYPE
    SYNTAX      PortList
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Набор портов, в которые следует передавать исходящие пакеты
        данной VLAN без тегов. Принятым по умолчанию значением этого
        объекта для установленной по умолчанию VLAN (dot1qVlanIndex = 1)
        является строка подходящего размера, включающая все порты. Для
        других VLAN значения по умолчанию нет. Если агент устройства не
        поддерживает устанавливаемый набор портов, он будет отвергать
        операцию с возвратом ошибки. Например, менеджер может попытаться
        установить отсутствие тегов на выходе для нескольких VLAN на 
        устройстве, которое не поддерживает эту опцию IEEE 802.1Q."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.2.1"
    ::= { dot1qVlanStaticEntry 4 }

dot1qVlanStaticRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Объект, показывающий статус данной записи."
    ::= { dot1qVlanStaticEntry 5 }

dot1qNextFreeLocalVlanIndex OBJECT-TYPE
    SYNTAX      Integer32 (0|4096..2147483647)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Следующее доступное значение для dot1qVlanIndex локальной
        записи VLAN в dot1qVlanStaticTable. Это будет давать значения
        >=4096, если может быть создана новая Local VLAN или 0, если
        это невозможно.

        Операция создания строки в этой таблице для записи с локальным
        VlanIndex может завершаться отказом, если текущее значение этого
        объекта не используется в качестве индекса. Даже если прочитанное
        значение используется, нет гарантии, что оно будет пригодным 
        индексом для операции создания, поскольку другой менеджер уже мог
        взять его в промежуточный интервал времени. В этом случае следует
        заново прочитать dot1qNextFreeLocalVlanIndex и повторить создание
        с новым значением.

        Это значение будет меняться автоматически, когда текущее значение 
        используется для создания новой строки."
    ::= { dot1qVlan 4 }

-- -------------------------------------------------------------
-- Таблица VLAN Port Configuration 
-- -------------------------------------------------------------

dot1qPortVlanTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qPortVlanEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с информацией управления и состояния на уровне порта для
        конфигурации VLAN в устройстве."
    ::= { dot1qVlan 5 }

dot1qPortVlanEntry OBJECT-TYPE
    SYNTAX      Dot1qPortVlanEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Информация для управления конфигурацией VLAN для порта устройства.
        Индексируется с помощью dot1dBasePort."
    AUGMENTS { dot1dBasePortEntry }
    ::= { dot1qPortVlanTable 1 }

Dot1qPortVlanEntry ::=
    SEQUENCE {
        dot1qPvid
            VlanIndex,
        dot1qPortAcceptableFrameTypes
            INTEGER,
        dot1qPortIngressFiltering
            TruthValue,
        dot1qPortGvrpStatus
            EnabledStatus,
        dot1qPortGvrpFailedRegistrations
            Counter32,
        dot1qPortGvrpLastPduOrigin
            MacAddress,
        dot1qPortRestrictedVlanRegistration
            TruthValue
    }

dot1qPvid OBJECT-TYPE
    SYNTAX      VlanIndex
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "PVID — идентификатор VLAN-ID, назначенный для кадров 
        без тега или с тегом Priority, принятым данным портом.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.1.1"
    DEFVAL      { 1 }
    ::= { dot1qPortVlanEntry 1 }

dot1qPortAcceptableFrameTypes OBJECT-TYPE
    SYNTAX      INTEGER {
                    admitAll(1),
                    admitOnlyVlanTagged(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "При admitOnlyVlanTagged(2) устройство будет отбрасывать
        кадры без тега или с тегом Priority, принятые этим портом.
        При admitAll(1) такие кадры будут восприниматься и им
        будет назначаться VID на базе PVID и VID Set для этого порта.

        Этот объект не влияет на независимые от VLAN кадры BPDU типа
        GVRP и STP, но явно зависимые от VLAN кадры BPDU типа GMRP.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.1.3"
    DEFVAL      { admitAll }
    ::= { dot1qPortVlanEntry 2 }

dot1qPortIngressFiltering OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "При значении true(1) устройство будет отбрасывать входящие
        кадры для VLAN, не включающих данный порт в свой набор 
        Member. При false(2) порт будет воспринимать все входящие кадры.

        Этот объект не влияет на независимые от VLAN кадры BPDU типа
        GVRP и STP, но явно зависимые от VLAN кадры BPDU типа GMRP.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.1.4"
    DEFVAL      { false }
    ::= { dot1qPortVlanEntry 3 }

dot1qPortGvrpStatus OBJECT-TYPE
    SYNTAX      EnabledStatus
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Состояние операции GVRP на данном порту. Значение
        enabled(1) показывает, что протокол GVRP включен на порту,
        если dot1qGvrpStatus также включено для этого устройства.
        Если объект имеет значение disabled(2), но dot1qGvrpStatus 
        включено для устройства, GVRP отключен на этом порту и все 
        принятые пакеты GVRP будут отбрасываться без уведомления,
        а регистрации GVRP не будут распространяться из других портов.
        Этот объект влияет на все машины состояний GVRP Applicant и
        Registrar на этом порту. Переход от disabled(2) к enabled(1) 
        будет приводить к сбросу всех машин состояния GVRP на этом порту.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    DEFVAL      { enabled }
    ::= { dot1qPortVlanEntry 4 }

dot1qPortGvrpFailedRegistrations OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Общее число регистраций GVRP с отказом по любой причине для 
        этого порта."
    ::= { dot1qPortVlanEntry 5 }

dot1qPortGvrpLastPduOrigin OBJECT-TYPE
    SYNTAX      MacAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "MAC-адрес отправителя последнего сообщения GVRP принятого
        этим портом."
    ::= { dot1qPortVlanEntry 6 }

dot1qPortRestrictedVlanRegistration OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Состояние Restricted VLAN Registration на этом порту. Если
         этот объект имеет значение true(1), создание новой динамической
         записи VLAN разрешено лишь при наличии записи Static VLAN
         Registration для данной VLAN, в которой  Registrar Administrative
         Control для этого порта имеет значение Normal Registration.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    REFERENCE
        "IEEE 802.1u clause 11.2.3.2.3, 12.10.1.7."
    DEFVAL      { false }
    ::= { dot1qPortVlanEntry 7 }

-- -------------------------------------------------------------
-- Таблица статистики VLAN для порта
-- -------------------------------------------------------------

dot1qPortVlanStatisticsTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qPortVlanStatisticsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица статистики принятого трафика по портам и VLAN.
        Предоставляются отдельные объекты для старших и младших битов 
        счетчиков статистики для портов, связанных с этим прозрачным
        мостом. Объекты старших битов нужны лишь для высокоскоростных
        интерфейсов, указанных заявлениями о соответствии для этих
        объектов. Этот механизм позволяет считывать значения 64-битовых
        счетчиков агентам, поддерживающим лишь SNMPv1.

        Отметим, что разделение старших и младших битов счетчиков связано
        с риском переполнения младших битов в интервале между выборками.
        Менеджер должен осознавать это даже  в рамках одного varbindlist
        при интерпретации результатов запроса асинхронных уведомлений."
    ::= { dot1qVlan 6 }

dot1qPortVlanStatisticsEntry OBJECT-TYPE
    SYNTAX      Dot1qPortVlanStatisticsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Статистика трафика для VLAN на интерфейсе."
    INDEX   { dot1dBasePort, dot1qVlanIndex }
    ::= { dot1qPortVlanStatisticsTable 1 }

Dot1qPortVlanStatisticsEntry ::=
    SEQUENCE {
        dot1qTpVlanPortInFrames
            Counter32,
        dot1qTpVlanPortOutFrames
            Counter32,
        dot1qTpVlanPortInDiscards
            Counter32,
        dot1qTpVlanPortInOverflowFrames
            Counter32,
        dot1qTpVlanPortOutOverflowFrames
            Counter32,
        dot1qTpVlanPortInOverflowDiscards
            Counter32
    }

dot1qTpVlanPortInFrames OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число корректных кадров, принятых этим портом из своего
        сегмента, которые были отнесены к данной VLAN. Отметим,
        что принятый портом кадр учитывается лишь в том случае,
        когда он относится к протоколу, обрабатываемому локальным
        процессом пересылки для этой VLAN. Это включает принятые
        мостом кадры управления, относящиеся к этой VLAN (например,
        GMRP, но GVRP или STP)."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.6.1.1.3(a)"
    ::= { dot1qPortVlanStatisticsEntry 1 }

dot1qTpVlanPortOutFrames OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число корректных кадров, переданных этим портом в свой
        сегмент от локального процесса пересылки для данной VLAN. 
        Это включает созданные устройством кадры управления мостом,
        относящиеся к данной VLAN (например, GMRP, но не GVRP или STP)."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.6.1.1.3(d)"
    ::= { dot1qPortVlanStatisticsEntry 2 }

dot1qTpVlanPortInDiscards OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число корректных кадров, принятых этим портом из своего
        сегмента, которые были отнесены к данной VLAN, но отброшены
        по связанным с VLAN причинам (в частности, счетчики IEEE 802.1Q 
        для Discard Inbound и Discard on Ingress Filtering.)"
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.6.1.1.3"
    ::= { dot1qPortVlanStatisticsEntry 3 }

dot1qTpVlanPortInOverflowFrames OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число случаев переполнения счетчика 
        dot1qTpVlanPortInFrames."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1qPortVlanStatisticsEntry 4 }

dot1qTpVlanPortOutOverflowFrames OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число случаев переполнения счетчика 
        dot1qTpVlanPortOutFrames."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1qPortVlanStatisticsEntry 5 }

dot1qTpVlanPortInOverflowDiscards OBJECT-TYPE
    SYNTAX      Counter32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число случаев переполнения счетчика 
        dot1qTpVlanPortInDiscards."
    REFERENCE
        "ISO/IEC 15802-3 Section 14.6.1.1.3"
    ::= { dot1qPortVlanStatisticsEntry 6 }

dot1qPortVlanHCStatisticsTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qPortVlanHCStatisticsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица статистики трафика на высокоскоростных
        интерфейсах по портам и VLAN."
    ::= { dot1qVlan 7 }

dot1qPortVlanHCStatisticsEntry OBJECT-TYPE
    SYNTAX      Dot1qPortVlanHCStatisticsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Статистика для VLAN на высокоскоростном интерфейсе."
    INDEX   { dot1dBasePort, dot1qVlanIndex }
    ::= { dot1qPortVlanHCStatisticsTable 1 }

Dot1qPortVlanHCStatisticsEntry ::=
    SEQUENCE {
        dot1qTpVlanPortHCInFrames
            Counter64,
        dot1qTpVlanPortHCOutFrames
            Counter64,
        dot1qTpVlanPortHCInDiscards
            Counter64
    }

dot1qTpVlanPortHCInFrames OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число корректных кадров, принятых этим портом из своего
        сегмента, которые были отнесены к данной VLAN. Отметим,
        что принятый портом кадр учитывается лишь в том случае,
        когда он относится к протоколу, обрабатываемому локальным
        процессом пересылки для этой VLAN. Это включает принятые
        мостом кадры управления, относящиеся к этой VLAN (например,
        GMRP, но GVRP или STP)."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.6.1.1.3(a)"
    ::= { dot1qPortVlanHCStatisticsEntry 1 }

dot1qTpVlanPortHCOutFrames OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число корректных кадров, переданных этим портом в свой
        сегмент от локального процесса пересылки для данной VLAN. 
        Это включает созданные устройством кадры управления мостом,
        относящиеся к данной VLAN (например, GMRP, но не GVRP или STP)."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.6.1.1.3(d)"
    ::= { dot1qPortVlanHCStatisticsEntry 2 }

dot1qTpVlanPortHCInDiscards OBJECT-TYPE
    SYNTAX      Counter64
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "Число корректных кадров, принятых этим портом из своего
        сегмента, которые были отнесены к данной VLAN, но отброшены
        по связанным с VLAN причинам (в частности, счетчики IEEE 802.1Q 
        для Discard Inbound и Discard on Ingress Filtering.)"
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.6.1.1.3"
    ::= { dot1qPortVlanHCStatisticsEntry 3 }

-- -------------------------------------------------------------
-- Таблица ограничений VLAN Learning
-- -------------------------------------------------------------

dot1qLearningConstraintsTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1qLearningConstraintsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица ограничений при обучении для наборов общих 
        и независимых VLAN."
    REFERENCE
        "IEEE 802.1Q/D11 Section 12.10.3.1"
    ::= { dot1qVlan 8 }

dot1qLearningConstraintsEntry OBJECT-TYPE
    SYNTAX      Dot1qLearningConstraintsEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Ограничения по обучению для VLAN."
    INDEX   { dot1qConstraintVlan, dot1qConstraintSet }
    ::= { dot1qLearningConstraintsTable 1 }

Dot1qLearningConstraintsEntry ::=
    SEQUENCE {
        dot1qConstraintVlan
            VlanIndex,
        dot1qConstraintSet
            Integer32,
        dot1qConstraintType
            INTEGER,
        dot1qConstraintStatus
            RowStatus
    }

dot1qConstraintVlan OBJECT-TYPE
    SYNTAX      VlanIndex
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Индекс строки в dot1qVlanCurrentTable для VLAN, 
        ограниченной этой записью."
    ::= { dot1qLearningConstraintsEntry 1 }

dot1qConstraintSet OBJECT-TYPE
    SYNTAX      Integer32 (0..65535)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Отождествление набора ограничений, к которому относится
        dot1qConstraintVlan. Значения могут быть выбраны станцией
        управления."
    ::= { dot1qLearningConstraintsEntry 2 }

dot1qConstraintType OBJECT-TYPE
    SYNTAX      INTEGER {
                    independent(1),
                    shared(2)
                }
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Тип ограничений, определяемых данной записью.
            independent(1) - VLAN dot1qConstraintVlan
                использует базу фильтров, не зависимую от других
                VLAN набора, определенного dot1qConstraintSet.
            shared(2) - VLAN dot1qConstraintVlan использует общую
                базу фильтров с другими VLAN, определенными
                dot1qConstraintSet."
    ::= { dot1qLearningConstraintsEntry 3 }

dot1qConstraintStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Статус данной записи."
    ::= { dot1qLearningConstraintsEntry 4 }

dot1qConstraintSetDefault OBJECT-TYPE
    SYNTAX      Integer32 (0..65535)
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Отождествление набора ограничений, к которому относится VLAN,
        если нет явной записи для VLAN в dot1qLearningConstraintsTable.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qVlan 9 }

dot1qConstraintTypeDefault OBJECT-TYPE
    SYNTAX      INTEGER {
                    independent(1),
                    shared(2)
                }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION
        "Тип набора ограничений, к которому относится VLAN, если нет
        явной записи для этой VLAN в dot1qLearningConstraintsTable. 
        Типы определяются для dot1qConstraintType.

        Значение этого объекта ДОЛЖНО сохраняться при 
        переинициализации системы управления."
    ::= { dot1qVlan 10 }

-- -------------------------------------------------------------
-- Субдерево dot1vProtocol 
-- -------------------------------------------------------------

dot1vProtocolGroupTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1vProtocolGroupEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с отображениями Protocol Template на
         Protocol Group Identifier, используемыми для
         классификации VLAN по порту и протоколу."
    REFERENCE
        "IEEE 802.1v clause 8.6.4"
    ::= { dot1vProtocol 1 }

dot1vProtocolGroupEntry OBJECT-TYPE
    SYNTAX      Dot1vProtocolGroupEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Отображение Protocol Template на Protocol Group Identifier."
    INDEX       { dot1vProtocolTemplateFrameType,
                  dot1vProtocolTemplateProtocolValue }
    ::= { dot1vProtocolGroupTable 1 }

Dot1vProtocolGroupEntry ::=
    SEQUENCE {
        dot1vProtocolTemplateFrameType
            INTEGER,
        dot1vProtocolTemplateProtocolValue
            OCTET STRING,
        dot1vProtocolGroupId
            Integer32,
        dot1vProtocolGroupRowStatus
            RowStatus
    }

dot1vProtocolTemplateFrameType OBJECT-TYPE
    SYNTAX      INTEGER {
                  ethernet  (1),
                  rfc1042   (2),
                  snap8021H (3),
                  snapOther (4),
                  llcOther  (5)
                }
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Формат инкапсуляции канального уровня или 
         detagged_frame_type в Protocol Template."
    REFERENCE
        "IEEE 802.1v clause 8.6.2"
    ::= { dot1vProtocolGroupEntry 1 }

dot1vProtocolTemplateProtocolValue OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE (2 | 5))
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Идентификация протокола над канальным уровнем в Protocol
         Template. В зависимости от типа кадра строка октетов
         принимает одно из следующих значений:
         для ethernet, rfc1042 и snap8021H это 16-битовое (2 октета)
             поле типа IEEE 802.3;
         для snapOther это 40-битовый (5 октетов) идентификатор PID.
         для llcOther это 2-октетная пара IEEE 802.2 LSAP11, где первый 
             октет задает DSAP12, а второй - SSAP13."
    REFERENCE
        "IEEE 802.1v clause 8.6.2"
    ::= { dot1vProtocolGroupEntry 2 }

dot1vProtocolGroupId OBJECT-TYPE
    SYNTAX      Integer32 (0..2147483647)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Представляет группу протоколов, связанных вместе при назначении
         VID для кадра."
    REFERENCE
        "IEEE 802.1v clause 8.6.3, 12.10.2.1"
    ::= { dot1vProtocolGroupEntry 3 }

dot1vProtocolGroupRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Этот объект указывает статус данной записи."
    ::= { dot1vProtocolGroupEntry 4 }

dot1vProtocolPortTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF Dot1vProtocolPortEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Таблица с наборами VID, используемыми для классификации
         VLAN по порту и протоколу."
    REFERENCE
        "IEEE 802.1v clause 8.4.4"
    ::= { dot1vProtocol 2 }

dot1vProtocolPortEntry OBJECT-TYPE
    SYNTAX      Dot1vProtocolPortEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Набор VID для порта."
    INDEX       { dot1dBasePort,
                  dot1vProtocolPortGroupId }
    ::= { dot1vProtocolPortTable 1 }

Dot1vProtocolPortEntry ::=
    SEQUENCE {
        dot1vProtocolPortGroupId
            Integer32,
        dot1vProtocolPortGroupVid
            Integer32,
        dot1vProtocolPortRowStatus
            RowStatus
    }

dot1vProtocolPortGroupId OBJECT-TYPE
    SYNTAX      Integer32 (1..2147483647)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Указывает группу протоколов в Protocol Group Database."
    REFERENCE
        "IEEE 802.1v clause 8.6.3, 12.10.1.2"
    ::= { dot1vProtocolPortEntry 1 }

dot1vProtocolPortGroupVid OBJECT-TYPE
    SYNTAX      Integer32 (1..4094)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "VID, связанный с группой протоколов для каждого порта."
    REFERENCE
        "IEEE 802.1v clause 8.4.4, 12.10.1.2"
    ::= { dot1vProtocolPortEntry 2 }

dot1vProtocolPortRowStatus OBJECT-TYPE
    SYNTAX      RowStatus
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Этот объект указывает статус данной записи ."
    ::= { dot1vProtocolPortEntry 3 }

-- -------------------------------------------------------------
-- IEEE 802.1Q MIB — информация о соответствии
-- -------------------------------------------------------------

qBridgeConformance OBJECT IDENTIFIER ::= { qBridgeMIB 2 }

qBridgeGroups OBJECT IDENTIFIER ::= { qBridgeConformance 1 }

qBridgeCompliances OBJECT IDENTIFIER ::= { qBridgeConformance 2 }


-- -------------------------------------------------------------
-- Блоки соответствия
-- -------------------------------------------------------------

qBridgeBaseGroup OBJECT-GROUP
    OBJECTS {
        dot1qVlanVersionNumber,
        dot1qMaxVlanId,
        dot1qMaxSupportedVlans,
        dot1qNumVlans,
        dot1qGvrpStatus
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, обеспечивающих информацию для управления
        и статуса на уровне устройства для служб моста VLAN."
    ::= { qBridgeGroups 1 }

qBridgeFdbUnicastGroup OBJECT-GROUP
    OBJECTS {
        dot1qFdbDynamicCount,
        dot1qTpFdbPort,
        dot1qTpFdbStatus
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов с информацией обо всех индивидуальных адресах,
        определенных динамически или статически заданных системой
        управления, в каждой Filtering Database."
    ::= { qBridgeGroups 2 }

qBridgeFdbMulticastGroup OBJECT-GROUP
    OBJECTS {
        dot1qTpGroupEgressPorts,
        dot1qTpGroupLearnt
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов с информацией обо всех групповых адресах,
        определенных динамически или статически заданных системой
        управления, в каждой Filtering Database."
    ::= { qBridgeGroups 3 }

qBridgeServiceRequirementsGroup OBJECT-GROUP
    OBJECTS {
        dot1qForwardAllPorts,
        dot1qForwardAllStaticPorts,
        dot1qForwardAllForbiddenPorts,
        dot1qForwardUnregisteredPorts,
        dot1qForwardUnregisteredStaticPorts,
        dot1qForwardUnregisteredForbiddenPorts
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов с информацией о требованиях службы, 
        определенных динамически или статически заданных системой
        управления, в каждой Filtering Database."
    ::= { qBridgeGroups 4 }

qBridgeFdbStaticGroup OBJECT-GROUP
    OBJECTS {
        dot1qStaticUnicastAllowedToGoTo,
        dot1qStaticUnicastStatus,
        dot1qStaticMulticastStaticEgressPorts,
        dot1qStaticMulticastForbiddenEgressPorts,
        dot1qStaticMulticastStatus
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов с информацией обо всех индивидуальных адресах,
        и групповых адресах, статически заданных системой управления в
        каждой Filtering Database или VLAN."
    ::= { qBridgeGroups 5 }

qBridgeVlanGroup OBJECT-GROUP
    OBJECTS {
        dot1qVlanNumDeletes,
        dot1qVlanFdbId,
        dot1qVlanCurrentEgressPorts,
        dot1qVlanCurrentUntaggedPorts,
        dot1qVlanStatus,
        dot1qVlanCreationTime
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов с информацией обо всех VLAN, настроенных
         в данный момент на устройстве."
    ::= { qBridgeGroups 6 }

qBridgeVlanStaticGroup OBJECT-GROUP
    OBJECTS {
        dot1qVlanStaticName,
        dot1qVlanStaticEgressPorts,
        dot1qVlanForbiddenEgressPorts,
        dot1qVlanStaticUntaggedPorts,
        dot1qVlanStaticRowStatus,
        dot1qNextFreeLocalVlanIndex
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов с информацией обо всех VLAN, статически
        настроенных системой управления."
    ::= { qBridgeGroups 7 }

qBridgePortGroup OBJECT-GROUP
    OBJECTS {
        dot1qPvid,
        dot1qPortAcceptableFrameTypes,
        dot1qPortIngressFiltering,
        dot1qPortGvrpStatus,
        dot1qPortGvrpFailedRegistrations,
        dot1qPortGvrpLastPduOrigin
    }
    STATUS      deprecated
    DESCRIPTION
        "Набор объектов с информацией для управления и состояния 
        VLAN на уровне порта для всех портов устройства."
    ::= { qBridgeGroups 8 }

qBridgeVlanStatisticsGroup OBJECT-GROUP
    OBJECTS {
        dot1qTpVlanPortInFrames,
        dot1qTpVlanPortOutFrames,
        dot1qTpVlanPortInDiscards
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов со статистикой пакетов на уровне порта 
        для всех VLAN, настроенных в устройстве."
    ::= { qBridgeGroups 9 }

qBridgeVlanStatisticsOverflowGroup OBJECT-GROUP
    OBJECTS {
        dot1qTpVlanPortInOverflowFrames,
        dot1qTpVlanPortOutOverflowFrames,
        dot1qTpVlanPortInOverflowDiscards
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов со счетчиками переполнения для статистики
        пакетов на уровне порта во всех VLAN, настроенных на данном 
        устройстве, для высокоскоростных интерфейсов, у которых
        соответствующий экземпляр ifSpeed больше 650 000000 бит/с."
    ::= { qBridgeGroups 10 }

qBridgeVlanHCStatisticsGroup OBJECT-GROUP
    OBJECTS {
        dot1qTpVlanPortHCInFrames,
        dot1qTpVlanPortHCOutFrames,
        dot1qTpVlanPortHCInDiscards
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов со статистикой на уровне порта во всех VLAN, 
        настроенных в системе, для высокоскоростных интерфейсов, у которых 
        соответствующих экземпляр ifSpeed больше 650 000 000 бит/с."
    ::= { qBridgeGroups 11 }

qBridgeLearningConstraintsGroup OBJECT-GROUP
    OBJECTS {
        dot1qConstraintType,
        dot1qConstraintStatus
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, определяющих ограничения Filtering Database
        всех VLAN относительно друг друга."
    ::= { qBridgeGroups 12 }

qBridgeLearningConstraintDefaultGroup OBJECT-GROUP
    OBJECTS {
        dot1qConstraintSetDefault,
        dot1qConstraintTypeDefault
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов, определяющих принятые по умолчанию ограничения 
        Filtering Database для VLAN, не имеющих конкретных ограничений."
    ::= { qBridgeGroups 13 }

qBridgeClassificationDeviceGroup OBJECT-GROUP
    OBJECTS {
        dot1vProtocolGroupId,
        dot1vProtocolGroupRowStatus
    }
    STATUS      current
    DESCRIPTION
        "Классификационные данные VLAN для моста."
    ::= { qBridgeGroups 14 }

qBridgeClassificationPortGroup OBJECT-GROUP
    OBJECTS {
        dot1vProtocolPortGroupVid,
        dot1vProtocolPortRowStatus
    }
    STATUS      current
    DESCRIPTION
        "Данные классификации VLAN для отдельных портов."
    ::= { qBridgeGroups 15 }

qBridgePortGroup2 OBJECT-GROUP
    OBJECTS {
        dot1qPvid,
        dot1qPortAcceptableFrameTypes,
        dot1qPortIngressFiltering,
        dot1qPortGvrpStatus,
        dot1qPortGvrpFailedRegistrations,
        dot1qPortGvrpLastPduOrigin,
        dot1qPortRestrictedVlanRegistration
    }
    STATUS      current
    DESCRIPTION
        "Набор объектов с информацией для управления и состояния 
        VLAN на уровне порта для всех портов устройства."
    ::= { qBridgeGroups 16 }

-- -------------------------------------------------------------
-- Заявления о соответствии
-- -------------------------------------------------------------

qBridgeCompliance MODULE-COMPLIANCE
    STATUS  deprecated
    DESCRIPTION
        "Заявление о соответствии для устройства в части поддержки 
        служб Virtual LAN Bridge.

        RFC2674 умалчивает об ожидаемой сохранности доступных для
        чтения и записи объектов данного модуля MIB. Приложениям
        НЕДОПУСТИМО делать предположения о сохранности объектов 
        read-write при повторной инициализации системы управления."

    MODULE
        MANDATORY-GROUPS {
            qBridgeBaseGroup,
            qBridgeVlanGroup,
            qBridgeVlanStaticGroup,
            qBridgePortGroup
        }

        GROUP       qBridgeFdbUnicastGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих прозрачные
            мосты 802.1Q."

        GROUP       qBridgeFdbMulticastGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих прозрачные
            мосты 802.1Q."

        GROUP       qBridgeServiceRequirementsGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих расширенную
            фильтрацию. Все объекты должны быть доступны для чтения и записи,
            если службы расширенной фильтрации включены."

        GROUP       qBridgeFdbStaticGroup
        DESCRIPTION
            "Эта группа не обязательна."

        GROUP       qBridgeVlanStatisticsGroup
        DESCRIPTION
            "Эта группа не обязательна, поскольку ее поддержка может
            быть связана со значительными издержками при реализации."

        GROUP       qBridgeVlanStatisticsOverflowGroup
        DESCRIPTION
            "Эта группа не обязательна, поскольку ее поддержка может
            быть связана со значительными издержками при реализации.
            Она относится прежде всего к скоростным интерфейсам, когда 
            агент SNMP поддерживает только SNMPv1."

        GROUP       qBridgeVlanHCStatisticsGroup
        DESCRIPTION
            "Эта группа не обязательна, поскольку ее поддержка может
            быть связана со значительными издержками при реализации.
            Она относится прежде всего к скоростным интерфейсам."

        GROUP       qBridgeLearningConstraintsGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих оба режима
             IVL14 и SVL15 работы базы фильтрации, определенных IEEE 802.1Q."

        GROUP       qBridgeLearningConstraintDefaultGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих оба режима
             IVL и SVL работы базы фильтрации, определенных IEEE 802.1Q."

        OBJECT      dot1qPortAcceptableFrameTypes
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

        OBJECT      dot1qPortIngressFiltering
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

        OBJECT      dot1qConstraintSetDefault
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

        OBJECT      dot1qConstraintTypeDefault
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

       ::= { qBridgeCompliances 1 }

qBridgeCompliance2 MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
        "Заявления о соответствии для поддержки служб Virtual LAN Bridge.

        Этот документ разъясняет требования к сохранению объектов 
        read-write в данном модуля MIB. Все реализации, заявляющие
        соответствие qBridgeCompliance2, ДОЛЖНЫ сохранять объекты
        read-write, задающие такое требование."

    MODULE
        MANDATORY-GROUPS {
            qBridgeBaseGroup,
            qBridgeVlanGroup,
            qBridgeVlanStaticGroup,
            qBridgePortGroup2
        }

        GROUP       qBridgeFdbUnicastGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих прозрачные
            мосты 802.1Q."

        GROUP       qBridgeFdbMulticastGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих прозрачные
            мосты 802.1Q."

        GROUP       qBridgeServiceRequirementsGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих расширенную
            фильтрацию. Все объекты должны быть доступны для чтения и записи,
            если расширенная фильтрация включена."

        GROUP       qBridgeFdbStaticGroup
        DESCRIPTION
            "Эта группа не обязательна."

        GROUP       qBridgeVlanStatisticsGroup
        DESCRIPTION
            "Эта группа не обязательна, поскольку ее поддержка может
            быть связана со значительными издержками при реализации."

        GROUP       qBridgeVlanStatisticsOverflowGroup
        DESCRIPTION
            "Эта группа не обязательна, поскольку ее поддержка может
            быть связана со значительными издержками при реализации.
            Она относится прежде всего к скоростным интерфейсам, когда 
            агент SNMP поддерживает только SNMPv1."

        GROUP       qBridgeVlanHCStatisticsGroup
        DESCRIPTION
            "Эта группа не обязательна, поскольку ее поддержка может
            быть связана со значительными издержками при реализации.
            Она относится прежде всего к скоростным интерфейсам."

        GROUP       qBridgeLearningConstraintsGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих оба режима
             IVL и SVL работы базы фильтрации, определенных IEEE 802.1Q."

        GROUP       qBridgeLearningConstraintDefaultGroup
        DESCRIPTION
            "Эта группа обязательна для устройств, реализующих оба режима
             IVL и SVL работы базы фильтрации, определенных IEEE 802.1Q."

        GROUP       qBridgeClassificationDeviceGroup
        DESCRIPTION
            "Эта группа обязательна лишь для устройств, реализующих 
             классификацию VLAN в соответствии с IEEE 802.1v."

        GROUP       qBridgeClassificationPortGroup
        DESCRIPTION
            "Эта группа обязательна лишь для устройств, реализующих 
             классификацию VLAN в соответствии с IEEE 802.1v."

        OBJECT      dot1qPortAcceptableFrameTypes
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

        OBJECT      dot1qPortIngressFiltering
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

        OBJECT      dot1qConstraintSetDefault
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

        OBJECT      dot1qConstraintTypeDefault
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1Q."

        OBJECT      dot1vProtocolGroupId
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1v."

        OBJECT      dot1vProtocolGroupRowStatus
        MIN-ACCESS  read-only
        DESCRIPTION
            "Возможность записи не требуется, поскольку это опция в IEEE 802.1v."
        ::= { qBridgeCompliances 2 }
END

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

Большая часть этого документа является результатом работы группы IEEE 802.1 в процессе подготовки обновлений IEEE 802.1D [802.1D] и стандарта IEEE 802.1Q [802.1Q].

Авторы хотят выразить благодарность членам рабочей группы Bridge, а также David Harrington, Anders SW Christensen, Andrew Smith, Paul Langille, Anil Rijhsinghani и Keith McCloghrie за их комментарии и предложения, которые послужили улучшению документа.

Редактирование окончательной версии выполнил David Levi.

Новые текстовые соглашения, относящиеся к VLAN-ID, были разработаны в результате анализа применения VLAN-ID в нескольких модуля MIB. Исследование показало, что объекты VLAN-ID определены в нескольких модулях MIB. Редактор признателен всем, кто принял участие в обсуждении, которое привело к созданию новых текстовых соглашений. В частности, спасибо Bert Wijnen, Les Bell, Andrew Smith, Mike Heard, Randy Presuhn, Dan Romascanu, Eduardo Cardona, Tom Petch, Juergen Schoenwaelder, Richard Woundy, Tony Jeffree и William Murwin. Были также получены предложения и отклики от IEEE, подтвердившие, что значения 0 и 4095 не используются для конкретных VLAN-ID и могут служить для представления отсутствия VLAN или всех VLAN (см. Приложение A).

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

В этом модуле MIB определено множество объектов с MAX-ACCESS, разрешающим запись (read-write и/или read-create). Такие объекты могут быть уязвимыми в некоторых сетевых средах. Поддержка операций SET в небезопасной среде без подобающей защиты может оказывать негативное влияние на работу сети. Эти таблицы и объекты вместе с их уязвимостями описаны ниже.

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

         dot1dTrafficClassesEnabled
         dot1dGmrpStatus
         dot1dPortPriorityTable
         dot1dUserPriorityRegenTable
         dot1dTrafficClassTable
         dot1dPortGarpTable
         dot1dPortGmrpTable

Ниже перечислены таблицы и объекты Q-BRIDGE-MIB, которыми можно манипулировать для нарушения работы VLAN. Это может, например, использоваться для принудительной реинициализации машин состояний, вызывающей нестабильность сети или изменение правил пересылки или фильтрации.

         dot1qGvrpStatus
         dot1qForwardAllTable
         dot1qStaticUnicastTable
         dot1qStaticMulticastTable
         dot1qVlanStaticTable
         dot1qPortVlanTable
         dot1qLearningConstraintsTable
         dot1vProtocolGroupTable
         dot1vProtocolPortTable

Некоторые из доступных для чтения объектов данного модуля MIB (т. е. объекты, у которых MAX-ACCESS отличается от not-accessible) могут быть уязвимы в некоторых сетевых средах. Поэтому важно контролировать доступ GET и/или NOTIFY к таким объектам и по возможности шифровать объекты при передаче через сеть по протоколу SNMP.

Объекты dot1dDeviceCapabilities и dot1dPortCapabilitiesTable в P-BRIDGE-MIB могут использоваться атакующим для определения атак, которые могут быть применены против данного устройства.

Перечисленные ниже объекты и таблицы Q-BRIDGE-MIB, доступные лишь для чтения, могут использоваться атакующим для попыток воздействия на данное устройство с целью блокировки или фильтрации, а также могут помочь при определении логической топологии сети.

         dot1qMaxVlanID
         dot1qMaxSupportedVlans
         dot1qNumVlans
         dot1qFdbTable
         dot1qTpFdbTable
         dot1qTpGroupTable
         dot1qVlanCurrentTable
         dot1qPortVlanStatisticsTable

Протокол SNMP до версии SNMPv3 не обеспечивает адекватной защиты. Даже в защищенной сети (например, с помощью IPSec) нет возможности персонально контролировать доступ GET/SET (чтение, изменение, создание, удаление) к объектам данного модуля MIB.

Разработчикам рекомендуется рассмотреть функции защиты, обеспечиваемые SNMPv3 (см. раздел 8 [RFC3410]), включая полную поддержку криптографических механизмов SNMPv3 (для аутентификации и конфиденциальности).

Более того, развертывание версий SNMP до SNMPv3 не рекомендуется. Вместо этого рекомендуется использовать SNMPv3 и включать криптографическую защиту. Тогда на абонентов/операторов ложится ответственность за обеспечение того, чтобы объект SNMP, предоставляющий доступ к экземпляру этого модуля MIB, был правильно настроен для предоставления доступа к объектам лишь тем элементам (пользователям), которые имеют легитимные права выполнять операции GET или SET (изменить, создать, удалить).

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

[BRIDGE-MIB] Norseth, K. and E. Bell, «Definitions of Managed Objects for Bridges», RFC 4188, September 2005.

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

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A., and K. McCloghrie, «Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions», RFC 2674, August 1999.

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

[RFC3418] Presuhn, R., «Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3418, December 2002.

[802.1D] «Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Common specifications — Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.» ISO/IEC 15802-3: 1998.

[802.1Q] ANSI/IEEE Standard 802.1Q, «IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks», 2003.

[802.1t] IEEE 802.1t-2001, «(Amendment to IEEE Standard 802.1D) IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Common specifications — Part 3: Media Access Control (MAC) Bridges: Technical and Editorial Corrections».

[802.1u] IEEE 802.1u-2001, «(Amendment to IEEE Standard 802.1Q) IEEE Standard for Local and metropolitan area networks — Virtual Bridged Local Area Networks — Amendment 1: Technical and Editorial Corrections».

[802.1v] IEEE 802.1v-2001, «(Amendment to IEEE Standard 802.1Q) IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks—Amendment 2: VLAN Classification by Protocol and Port».

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

[RFC1493] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, «Definitions of Managed Objects for Bridges», RFC 1493, July 1993.

[RFC4323] Patrick, M. and W. Murwin, «Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB)», RFC 4323, January 2006.

[RFC4149] Kalbfleisch, C., Cole, R., and D. Romascanu, «Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms», RFC 4149, August 2005.

[RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, «Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0», RFC 2613, June 1999.

[RFC3318] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, «Framework Policy Information Base», RFC 3318, March 2003.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

Приложение A. Письмо от Tony Jeffrey из IEEE

   -----Original Message-----
   From: Tony Jeffree [mailto:tony@jeffree.co.uk]
   Sent: Friday, 6th of June 2003 17:16
   To: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
   Subject: RE: VLAn ID


   Bert et al -

   We have concluded that the use of 4095 as a wildcard is acceptable
   to 802.1, and we will make any necessary changes to 802.1Q in due
   course to relax the current stated restriction.  However, we need
   to know whether that is all that needs to be done to 802.1Q - i.e.,
   is there any need to change our definitions of the managed objects
   in the document (Clause 12) to reflect the interpretation of 4095
   as a wildcard, or is this simply an issue for the SNMP machinery
   to handle?16

   Regards,
   Tony

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

David Levi

Nortel Networks

4655 Great America Parkway

Santa Clara, CA 95054

USA

Phone: +1 865 686 0432

EMail: dlevi@nortel.com

David Harrington

Effective Software

50 Harding Rd.

Portsmouth, NH 03801

USA

Phone: +1 603 436 8634

EMail: ietfdbh@comcast.net

Vivian Ngai

Salt lake City, UT

USA

EMail: vivian_ngai@acm.org

Les Bell

Hemel Hempstead

Herts. HP2 7YU

UK

EMail: elbell@ntlworld.com

Andrew Smith

Beijing Harbour Networks

Jiuling Building

21 North Xisanhuan Ave.

Beijing, 100089

PRC

Fax: +1 415 345 1827

EMail: ah_smith@acm.org

Paul Langille

Newbridge Networks

5 Corporate Drive

Andover, MA 01810

USA

Phone: +1 978 691 4665

EMail: langille@newbridge.com

Anil Rijhsinghani

Accton Technology Corporation

5 Mount Royal Ave

Marlboro, MA 01752

USA

EMail: anil@accton.com

Keith McCloghrie

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

Phone: +1 408 526 5260

EMail: kzm@cisco.com

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

Network Working Group                                    S. Bellovin
Request for Comments: 4278                        AT&T Labs Research
Category: Informational                                     A. Zinin
                                                             Alcatel
                                                        January 2006

Отход от стандартных требований для опции TCP MD5 Signature (RFC 2385) и спецификации BGP-4

Standards Maturity Variance Regarding the TCP MD5 Signature Option

(RFC 2385) and the BGP-4 Specification

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

Процедура стандартизации IETF¹ требует, чтобы все ссылки на нормативные документы (normative reference) имели такой же или более высокий уровень стандартизации, как и ссылающийся на них документ. Параграф 9.1 RFC 2026 позволяет IESG предоставлять возможность отхода от стандартной практики IETF. Данный документ объясняет, как IESG делает это в отношении пересмотренной версии спецификации BGP-4, которая содержит ссылку на нормативный документ RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option². Документ RFC 2385 продолжает сохранять статус Proposed Standard³.

1. Введение

Процедура стандартизации IETF [RFC2026] требует, чтобы все ссылки на нормативные документы (normative reference) имели такой же или более высокий уровень стандартизации, как и ссылающийся на них документ. Параграф 9.1 RFC 2026 позволяет IESG предоставлять возможность отхода от стандартной практики IETF. В соответствии с такой возможностью рассматривается вопрос публикации обновленной спецификации BGP-4 [RFC4271] как предварительного стандарта (Draft Standard), несмотря на то, что в ней имеется ссылка в разделе “Нормативные документы” на [RFC2385] Защита сеансов BGP и использованием сигнатур MD5. Документ RFC 2385 продолжает сохранять статус Proposed Standard (отметим, что несмотря на наличие в названии документа [RFC2385] слова «сигнатура», описанная в нем технология более известна как MAC⁴ и ее не следует путать с технологиями цифровых подписей).

Широко реализованный алгоритм [RFC2385] для протокола BGP-4 представляет собой только механизм защиты на транспортном уровне. Другие возможные механизмы типа IPsec [RFC2401] и TLS [RFC2246] используются для этой задачи весьма редко, если не сказать никогда. С учетом долгосрочных требований по обеспечению защиты протокола невозможно продвигать BGP-4 без обязательного механизма защиты.

Конфликт уровней завершенности стандартизации разных спецификаций обычно разрешается путем продвижения спецификации, на которую имеется нормативная ссылка до уровня завершенности ссылающегося документа. Однако в рассматриваемом случае IESG полагает, что алгоритм [RFC2385], вполне подходящий для BGP, не является достаточно надежным для задач общего назначения и его не следует стандартизовать. В этой ситуации IESG полагает, что следует использовать изменение процедуры, чтобы позволить публикацию обновленной спецификации BGP-4 со статусом Draft Standard.

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

2. Требования к предварительным стандартам

Требования к уровням Proposed Standard (предложенный стандарт) и Draft Standard (предварительный стандарт) изложены в [RFC2026]. Для Proposed Standards [RFC2026] указывает:

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

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

Требования для Draft Standards более жестки:

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

Иными словами, документы, которые имеют известные недостатки, не следует продвигать в качестве Draft Standard.

3. Опция TCP MD5 Signature

[RFC2385], несмотря на публикация в 1998 г., описывает существенно более старый алгоритм MAC (Message Authentication Code). Алгоритм основан на методе keyed hash function, использующем MD5 [RFC1321] в качестве функции хэширования. На момент разработки оригинального кода этот метод представлялся подходящим, особенно для тех случаев, когда ключ добавлялся в конце (append), а не в начале (prepend) защищаемых данных. Но криптографические хэш-функции не были предназначены для использования в качестве MAC и результаты последующего криптоанализа показали, что конструкция не столь сильна, как представлялось поначалу [PV1, PV2]. Хуже того, в используемой методом функции MD5, были найдены существенные недостатки [Dobbertin, Wang]. С учетом этого было принято решение IETF об адаптации алгоритма HMAC (Hashed Message Authentication Code) [RFC2104] с подтвержденными защитными свойствами в качестве стандартного MAC.

Кроме того, [RFC2385] не включает никакого механизма управления ключами. Общепринятой практикой является использование пароля в качестве открытого ключа (shared secret) для пары сайтов, но это не является хорошей идеей [RFC3562].

Другая проблема указана непосредственно в [RFC2385] и связана отсутствием кода типа или номера версии, а также с неспособностью использующих эту схему систем воспринимать некоторые пакеты TCP reset.

Несмотря на широкое использование [RFC2385] в системах BGP, IESG считает, что этот алгоритм не подходит для использования в ином контексте. [RFC2385] не удовлетворяет требованиям к уровню Draft Standard.

4. Картина использования RFC 2385

С учетом сказанного выше возникает резонный вопрос, почему [RFC2385] продолжает использоваться для BGP. Ответом на этот вопрос является практика развертывания, присущая исключительно BGP.

Соединения BGP обычно являются очень короткими. На практике протяженность внешних соединений BGP обычно составляет 1 интервал⁵ (hop). Хотя внутренние соединения BGP обычно бывают более длинными, они, как правило, включают в себя только маршрутизаторы (а не компьютеры общего назначения, которые более подходят атакующим для использования в качестве средств перехвата TCP [Joncheray]).

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

Сказанное выше не отрицает возможности организации атак (если бы атаки не были возможны, не возникало бы задачи обеспечения защиты). Атакующие могут перехватывать соединения на уровнях 1 и 2 или использовать (в некоторых случаях) подставные пакеты⁶ ARP⁷ в точках обмена на основе технологий Ethernet. Тем не менее, в целом протокол BGP используется в средах, которые менее подвержены этому типу атак.

Существует другой тип атак, по отношению к которым протокол BGP весьма уязвим – фиктивные анонсы маршрутов из автономных систем, находящихся на расстоянии более одного интервала. Однако ни [RFC2385], ни другие механизмы защиты на транспортном уровне, не могут блокировать такие атаки. Для решения этой проблемы требуются иные схемы типа S-BGP [Kent].

5. Протокол LDP

Протокол LDP⁸ [RFC3036] также использует [RFC2385]. Практика развертывания LDP очень похожа на среду работы BGP — соединения LDP обычно существуют внутри одной автономной системы и чаще всего представляют собой прямые соединения между маршрутизаторами. Это делает среду LDP очень похожей (с точки зрения угроз) на среду BGP. Учитывая это обстоятельство и достаточно широкое использование LDP в сетях сервис-провайдеров мы не запрещаем использование [RFC2385] с протоколом LDP.

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

IESG полагает, что описанная здесь процедура не будет оказывать негативного влияния на безопасность Internet.

7. Заключение

Проведенный выше анализ убеждает IESG в том, что в данном случае допустимо отклонение от предусмотренных требований. [RFC2385] явно не подходит для статуса Draft Standard. Другие существующие механизмы (например, IPsec) будут делать эту работу лучше. Однако имеющийся опыт эксплуатации в сетях сервис-провайдеров (и, в частности, использование стандартных ключей с большим сроком жизни, вопреки [RFC3562]) говорит, что преимущества от использования таких схем в описанной ситуации достаточно малы и не покроют издержек, связанных с переходом. Мы предпочитаем дождаться появления механизма защиты, приспособленного для основных угроз в среде BGP.

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

[Dobbertin] H. Dobbertin, «The Status of MD5 After a Recent Attack»⁹, RSA Labs’ CryptoBytes, Vol. 2 No. 2, Summer 1996.

[Joncheray] Joncheray, L. «A Simple Active Attack Against TCP.» Proceedings of the Fifth Usenix Unix Security Symposium, 1995.

[Kent] Kent, S., C. Lynn, and K. Seo. «Secure Border Gateway Protocol (Secure-BGP).» IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, April, 2000, pp. 582-592.

[RFC3562] Leech, M., «Key Management Considerations for the TCP MD5 Signature Option», RFC 3562, July 2003.

[PV1] B. Preneel and P. van Oorschot, «MD-x MAC and building fast MACs from hash functions,» Advances in Cryptology — Crypto 95 Proceedings, Lecture Notes in Computer Science Vol. 963, D. Coppersmith, ed., Springer-Verlag, 1995.

[PV2] B. Preneel and P. van Oorschot, «On the security of two MAC algorithms,» Advances in Cryptology — Eurocrypt 96 Proceedings, Lecture Notes in Computer Science, U. Maurer, ed., Springer-Verlag, 1996.

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

[RFC2026] Bradner, S., «The Internet Standards Process – Revision 3», BCP 9, RFC 2026, October 1996.

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

[RFC2246] Dierks, T. and C. Allen, «The TLS Protocol Version 1.0», RFC 2246, January 1999.

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

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

[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, «LDP Specification», RFC 3036, January 2001.

[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[Wang] Wang, X. and H. Yu, «How to Break MD5 and Other Hash Functions.» Proceedings of Eurocrypt ’05, 2005.

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

Steven M. Bellovin

Department of Computer Science

Columbia University

1214 Amsterdam Avenue, M.C. 0401

New York, NY 10027-7003

Phone: +1 212-939-7149

EMail: bellovin@acm.org

Alex Zinin

Alcatel

701 E Middlefield Rd

Mountain View, CA 94043

EMail: zinin@psg.com

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

Network Working Group                                   D. McPherson
Request for Comments: 4277                            Arbor Networks
Category: Informational                                     K. Patel
                                                       Cisco Systems
                                                        January 2006

Опыт использования протокола BGP-4

Experience with the BGP-4 Protocol

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

Целью настоящего документа является рассмотрение вопроса о том, как требования, предъявляемые к публикации проектов стандартов Internet¹ для протоколов маршрутизации, выполнены для протокола BGP-4².

Этот документ удовлетворяет требованиям ко “второму отчету” (the second report), описанным в параграфе 6.0 документа RFC 1264. Для удовлетворения этих требования данный документ дополняет RFC 1773 и описывает дополнительный опыт, приобретенный в период между выпуском проекта стандарта (Draft Standard) и заявлением его в качестве стандарта.

1. Введение

Целью настоящего документа является рассмотрение вопроса о том, как требования, предъявляемые к публикации проектов стандартов Internet³ для протоколов маршрутизации, выполнены для протокола BGP-4.

Этот документ удовлетворяет требованиям ко “второму отчету” (the second report), описанным в параграфе 6.0 документа RFC 1264. Для удовлетворения этих требования данный документ дополняет RFC 1773 и описывает дополнительный опыт, приобретенный в период между выпуском проекта стандарта (Draft Standard) и заявлением его в качестве стандарта.

2. Обзор BGP-4

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

Первая версия протокола BGP была определена в [RFC1105]. Впоследствии были разработаны версии BGP с номерами 2, 3 и 4, определенные в [RFC1163], [RFC1267] и [RFC1771], соответственно. Изменения BGP-4 после получения статуса Draft Standard [RFC1771], перечислены в Приложении A⁴ документа [RFC4271].

2.1. Протокол граничного шлюза

Первая версия протокола BGP была опубликована в [RFC1105], вторая – в [RFC1163], третья – в [RFC1267]. Протокол BGP версии 4 определен в [RFC1771] и [RFC4271]. Приложения A, B, C и D документа [RFC4271] содержат список изменений, внесенных в каждую итерацию спецификации протокола BGP.

3. База MIB

База управляющей информации MIB⁵ протокола BGP-4 была опубликована в документе [BGP-MIB]. Эта база была обновлена на основе предыдущих версий, опубликованных в [RFC1657] и [RFC1269].

За исключением нескольких системных переменных BGP MIB разбита на две таблицы — BGP Peer и BGP Received Path Attribute.

Таблица Peer содержит информацию о соединениях с партнерами BGP (состояние и текущие действия). Таблица Received Path Attribute содержит все атрибуты, полученные от всех партнеров без применения к ним правил локальной политики маршрутизации. Атрибуты, используемые для реального определения маршрутов, являются подмножеством этой таблицы.

4. Сведения о реализациях

В настоящее время имеется множество независимых интероперабельных реализаций протокола BGP. Хотя предыдущий вариант этого документа содержал обзор интероперабельности реализаций, использующихся в сети Internet, в настоящее время было предложено выделить эту информацию в отдельный документ — BGP Implementation Report [RFC4276].

Следует отметить, что опыт реализации BGP-4 в продукции Cisco описан в документе [RFC1656].

Дополнительные сведения о реализациях протокола можно найти в [RFC4276].

5. Опыт использования протокола

В этой главе рассматривается опыт использования BGP и BGP-4. Протокол BGP использовался в сети с 1989 г., а BGP-4 – с 1993 г. Эксплуатация BGP подразумевает использование всех значимых функций протокола. Современная сетевая среда, где BGP используется в качестве протокола маршрутизации между автономными системами, является гетерогенной. Полоса каналов меняется в диапазоне от 56 кбит/с до 10 Гбит/с. Маршрутизаторы, на которых используется BGP, существенно различаются по производительности – от маломощных процессоров общего назначения до высокопроизводительных специализированных RISC-процессоров и включают как специализированные устройства, так и обычные станции, на которых используется тот или иной вариант UNIX или другая операционная система.

С точки зрения топологии сеть меняется от очень малозаселенной (малая плотность соединений) до весьма плотной. Требование полносвязности (full-mesh) топологии IBGP было существенно ослаблено за счет Route Reflection, AS Confederations и комбинаций этих расширений. Функция BGP Route Reflection была изначально определена в [RFC1966] и обновлена в [RFC2796]. Конфедерации AS для BGP были определены в [RFC1965] и потом обновлены в [RFC3065].

На момент создания этого документа BGP-4 используется как протокол маршрутизации между автономными системами во всех AS, подключенных к сети Internet. Общее число активных AS в глобальной таблице маршрутизации Internet составляет около 21000.

BGP используется как для обмена маршрутными данными между транзитными и оконечными (stub) AS, так и для обмена между транзитными AS. Протокол не различает сложившееся исторически разделение сетей на магистральные (backbones), региональные (regional) и краевые (edge).

Полный набор внешних маршрутов, передаваемых с помощью BGP включает более 170000 агрегированных записей, что в несколько раз превышает число подключенных сетей. Число активных путей в магистральных маршрутизаторах некоторых сервис-провайдеров превышает 2,5 миллиона. Естественная длина AS path для некоторых маршрутов составляет 10, но существуют AS, «дополняющие» длину пути до 25 или более.

6. Использование TCP

BGP использует TCP [RFC793] в качестве протокола транспортного уровня. В силу этого присущие TCP характеристики наследуются протоколом BGP.

Например, в результате особенностей поведения TCP функции управления полосой не могут быть реализованы, поскольку принятый в TCP алгоритм замедленного старта приводит к разрыву соединения BGP.

7. Метрика

В этой главе обсуждаются различные варианты метрики, используемые в BGP. Протокол BGP имеет различные параметры метрики для IBGP и EBGP. Это позволяет дать метрике, основанной на правилах, более высокий приоритет по сравнению с метрикой, определяемой дистанцией. Благодаря этому каждая автономная система может определить независимую политику как внутри AS, так и для внешних маршрутов. Атрибут BGP MED⁶ используется в качестве метрики узлами EBGP (междоменная маршрутизация), а LOCAL_PREF⁷ — узлами IBGP (внутридоменная маршрутизация).

7.1. Атрибут MED

В BGP версии 4 старый атрибут метрики INTER-AS был переопределен как MULTI_EXIT_DISC (MED)⁸. Это значение может использоваться в процессе отбрасывания лишних маршрутов (tie-breaking), когда выбирается предпочтительный путь к данному пространству адресов, и может обеспечивать узлам BGP возможность выбора оптимальной точки входа в локальную AS со стороны AS партнера.

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

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

Другим вопросом, связанным с использованием атрибута MED, является влияние агрегирования маршрутной информации BGP на значения MED. Объединенные маршруты часто генерируются из множества точек в AS для обеспечения стабильности, резервирования и т. п. Когда значения MED получаются на основе метрики IGP, связанной упомянутыми агрегированными маршрутами, анонсируемое партнеру значение MED может привести к выбору далекого от оптимума маршрута.

Атрибут MED был специально создан как “слабая” метрика, которая будет использоваться только в конце процесса выбора лучшего маршрута. Рабочая группа BGP была озабочена тем, что любая метрика, заданная удаленным оператором, будет воздействовать на маршрутизацию в локальной AS лишь в тех случаях, когда не указано иных предпочтений. Основной целью создания MED было обеспечение гарантий того, что партнеры не смогут “потерять” или “поглотить” трафик для сетей, которые они анонсируют.

7.1.1. MED и картошка

Рассмотрим поток трафика между парой адресатов, каждый из которых соединен с двумя транзитными сетями. В этом случае каждая из транзитных сетей может выбирать между передачей трафика партнеру, ближайшему к второму транзитному провайдеру, или партнеру, анонсирующему «более дешевый» путь через другого провайдера. Первый метод называют hot potato routing, поскольку он напоминает быстрое перебрасывание горячей картофелины, удерживаемой голыми руками. Маршрутизация этого типа осуществляется без передачи полученного от EBGP значения MED в IBGP. Это минимизирует транзитный трафик для провайдера, маршрутизирующего трафик. Значительно менее распространенным методом является cold potato routing, когда транзитный провайдер использует свою транзитную емкость для получения трафика, направляемого смежному транзитному провайдеру, анонсируемому как ближайший к адресату. Этот тип маршрутизации выполняется путем передачи полученного от EBGP значения MED в IBGP.

Если один из транзитных провайдеров использует метод hot potato, а другой — cold potato, трафик между адресатами будет симметричным. В зависимости от конкретных отношений между провайдерами, если один из них имеет большую емкость или существенно менее загруженную транзитную сеть, он может использовать метод cold potato. Созданная NSF магистральная сеть NSFNET и региональные сети NSF являлись в середине 1990 годов примером повсеместного использования маршрутизации по методу cold potato.

В некоторых случаях провайдер может использовать метод hot potato для некоторых адресатов в данной партнерской AS и метод cold potato — для других. Разное отношение к коммерческому и исследовательскому трафику в сети NSFNET середины 1990 годов является примером такого решения. Однако этот вариант можно описать термином mashed potato⁹ routing, отражающим сложность настройки конфигурации маршрутизаторов в то время.

По-видимому более понятными терминами, не относящимися к огородной сфере, будут best exit routing¹⁰ вместо cold potato routing и closest exit routing¹¹ вместо hot potato routing.

7.1.2. Передача MED партнерам BGP

[RFC4271] позволяет передавать атрибуты MED, полученные узлом BGP от любого из партнеров EBGP, своим партнерам IBGP. Хотя анонсирование атрибутов MED партнерам IBGP не является требуемым, оно обычно используется по умолчанию. Атрибуты MED, полученные узлом BGP от партнеров EBGP, не следует передавать другим партнерам EBGP.

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

7.1.3. Нулевое значение MED и отсутствие MED

[RFC4271] требует от реализации поддержки механизма удаления атрибутов MED. Предыдущие реализации не рассматривали отсутствие атрибута MED тождественным MED = 0. Спецификация [RFC4271] требует, чтобы отсутствие атрибута MED трактовалось как нулевое значение.

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

7.1.4. Атрибуты MED и выбор маршрута с учетом его «возраста»

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

8. Локальные предпочтения

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

Одним из недостатков спецификации BGP-4 было предложение использовать принятое по умолчанию значение LOCAL_PREF, если последнее не задано явно. Использование по умолчанию нулевого или максимального значения имеет свои ограничения, поэтому единое значение, используемое по умолчанию во всех маршрутизаторах AS, будет упрощать использование маршрутизаторов разных фирм в одной AS. Атрибут LOCAL_PREF задается локально, следовательно проблем за пределами границы AS не возникает.

[RFC4271] требует, чтобы значение LOCAL_PREF передавалось партнерам IBGP и не передавалось партнерам EBGP. Хотя используемого по умолчанию значения LOCAL_PREF спецификация не определяет, чаще всего используется значение 100.

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

                     /---- транзит B ----\
 конечный пользователь                   транзит A----
                     /---- транзит C ----\

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

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

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

9. Internal BGP в больших автономных системах

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

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

В больших AS это ведет к полносвязности соединений TCP (n * (n-1)) и использованию того или иного метода настройки и поддержки этих соединений. Протокол BGP не задает способов распространения такой информации. Следовательно, предпринимаются различные альтернативные попытки (такие, как вставка маршрутной информации BGP в локальный протокол IGP), но многие из них мало применимы на практике.

Для смягчения необходимости организации полносвязного IBGP были разработаны несколько вариантов, включая BGP Route Reflection [RFC2796] и AS Confederations for BGP [RFC3065].

10. Динамика Internet

Как обсуждается в [RFC4274], рост нагрузки на CPU и расхода полосы каналов обусловлены динамической природой маршрутизации в Internet. По мере расширения сети Internet возрастает частота изменения маршрутов.

Мы автоматически получаем некоторый уровень подавления этого роста, когда более специфичные NLRI агрегируются в более крупные блоки, однако этого недостаточно. В Приложении F к документу [RFC4271] приводится описание методов подавления, которые могут применяться к передаче анонсов. В будущих спецификациях протоколов типа BGP методы такого подавления нужно рассматривать как обязательные для реализации.

Механизм BGP Route Flap Damping определен в документе [RFC2439]. BGP Route Flap Damping помогает снизить объем маршрутной информации, передаваемой между партнерами BGP, что ведет к снижению нагрузки на эти узлы без негативного влияния на время схождения для относительно стабильных маршрутов.

Ни одна из современных реализаций BGP Route Flap Damping не сохраняет маршрутную историю в уникальных NRLI или AS Path, хотя RFC 2439 требует это. Потенциальным результатом отказа от раздельного рассмотрения каждого AS Path является чересчур агрессивное подавление адресатов в сети с высокой плотностью соединений (densely meshed network). Наиболее важным следствием этого является подавление адресата после единственного отказа. Поскольку автономные системы верхних уровней в Internet имеют высокий уровень связности, описанные здесь негативные последствия уже наблюдаются.

Изменения маршрутов анонсируются с помощью сообщений UPDATE. Наибольший трафик, связанный с сообщениями UPDATE, возникает при неэффективной упаковке анонсов с сообщениями об изменениях маршрутов. Анонсирование маршрутных изменений с общими атрибутами в одном сообщении BGP UPDATE помогает снизить расход полосы и загрузку процессора при обработке анонсов, как описано в главе 12 «Упаковка сообщений UPDATE».

Постоянные ошибки BGP могут заставить партнеров BGP постоянно переключать (flap) маршруты, если не реализованы средства подавления. Такое переключение ведет к значительному росту нагрузки на CPU маршрутизатора. Разработчики могут счесть полезной для предотвращения таких ситуаций реализацию функций подавления [RFC4271].

11. Базы маршрутной информации BGP (RIB)

В [RFC4271] сказано: «Вопросы локальной политики, которая может приводить к включению маршрутов в базу Adj-RIB-Out без их добавления в таблицу пересылки локального узла BGP выходят за пределы данного документа.»

Однако несколько широко распространенных реализаций не подтверждают, что записи Loc-RIB используются для заполнения таблицы пересылки до их установки в базу Adj-RIB-Out. Чаще всего это наблюдается в тех случаях, когда данный префикс представлен несколькими протоколами и уровень предпочтения для маршрута, полученного от BGP, ниже, чем для маршрута,полученного от другого протокола. В результате маршрут, полученный от другого протокола, включается в таблицу пересылки.

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

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

12. Упаковка сообщений UPDATE

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

Протокол BGP4 позволяет анонсировать множество префиксов с общим набором атрибутов пути в одном сообщении UPDATE. Обычно такое анонсирование называют упаковкой обновлений (update packing). По возможности рекомендуется использовать такую упаковку, поскольку она обеспечивает механизм для более эффективного поведения в нескольких областях, включая:

• снижение нагрузки на систему, связанной с генерацией и приемом сообщений UPDATE;

• снижение уровня сетевого трафика за счет уменьшения числа пакетов и расхода полосы;

• снижение частоты обработки атрибутов пути и поиска соответствий в базе данных AS_PATH (если таковая имеется); упорядочение атрибутов пути упрощает поиск соответствий в базе данных, поскольку в этом случае не может существовать нескольких представлений одного набора данных.

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

13. Ограничение частоты обновлений

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

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

13.1. Учет характеристик TCP

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

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

Если NLRI многократно изменяется в течение периода блокировки записи для одного или нескольких партнеров, передавать следует только последний лучший маршрут. В этом случае BGP работает в соответствии с рекомендациями [RFC4274]. В случаях экстремально частых изменений маршрутов партнерам, способным обрабатывать информацию с высокой скоростью, передается больший объем маршрутных данных, нежели более медленным партнерам.

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

14. Упорядочение атрибутов пути

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

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

15. Сортировка AS_SET

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

16. Контроль согласования версий

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

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

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

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

17.1. Опция TCP MD5

[RFC2385] определяет способ использования сигнатур TCP MD5 для проверки информации, передаваемой между двумя партнерами. Этот метод позволяет предотвратить вставку третьими сторонами информации (например, TCP Reset) в поток данных или изменение маршрутной информации, передаваемой между двумя узлами BGP.

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

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

В связи с этим рекомендуется использовать опцию MD5 TCP для защиты BGP от сброса соединений и вставки данных.

17.2. Использование BGP с IPsec

BGP может работать на основе IPsec как в туннельном, так и в транспортном режиме. В этом случае TCP-часть пакетов IP шифруется. Это не только предотвращает возможность вставки информации в поток данных между двумя узлами BGP, но и не позволяет атакующему изучать данные, передаваемые между партнерами.

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

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

17.3. Разное

Другой проблемой протоколов маршрутизации является подтверждение корректности и полномочности маршрутной информации, передаваемой в системе маршрутизации. В настоящее время на решении этой задачи сосредоточено много усилий, включая работы по определению угроз маршрутным данным BGP [BGPATTACK] и разработке мер проверки корректности и полномочности маршрутных данных, передаваемых BGP [SBGP] [soBGP].

В дополнение к этому IETF создана рабочая группа RPSEC¹² для обсуждения и оказания помощи в сфере защиты протоколов маршрутизации. В рамках RPSEC данный документ является откликом на BGP4, направленным на дальнейшее совершенствование протокола.

18. Рабочие группы PTOMAINE и GROW

Рабочая группа GROW¹³, недавно созданная взамен группы PTOMAINE¹⁴, занимается вопросами роста размеров таблиц маршрутизации, взаимодействия протоколов внутренней и внешней маршрутизации, а политики и практики распределения адресов в контексте влияния на глобальную систему маршрутизации. Кроме того, GROW будет также документировать эксплуатационные проблемы измерения, политики, безопасности и VPN.

GROW в настоящее время изучает влияние агрегирования маршрутов и вопрос невозможности агрегирования в результате неадекватной координации провайдеров.

В рамках GROW данный документ является откликом на BGP4, направленным на дальнейшее совершенствование протокола.

19. Реестры маршрутизации Internet (IRR¹⁵)

Многие организации регистрируют свою политику маршрутизации и происхождение префиксов в различных распределенных базах данных Реестра маршрутизации Internet (IRR). Эти базы данных обеспечивают доступ к информации, хранящейся в формате языка RPSL, определенного в [RFC2622]. Хотя регистрационная информация для некоторых провайдеров может поддерживаться и корректироваться, недостаточная корректность и своевременность (актуальность) данных в различных базах данных IRR препятствует широкому использованию этого ресурса.

20. Региональные реестры (RIR¹⁶) и IRR, немного истории

Программа NSFNET использовала протокол EGP (а впоследствии BGP) для обеспечения внешней маршрутной информации. Политика NSF заключалась в дифференцировании цен и типов услуг для исследовательских или учебных (RE) и коммерческих (CO) сетей, что привело к созданию изначальных требований к политике BGP. Кроме большей платы сети CO не могли использовать магистраль NSFNET для доступа в другие сети CO. Причиной более высокой платы для коммерческих пользователей NSFNET было желание субсидировать сети RE. Признание того, что сеть Internet изменилась от иерархической к многосвязной одноуровневой привело к отказу от EGP и BGP-1, а также представлений об иерархии сетей.

Реализация политики NSF обеспечивалась за счет поддержки базы данных NSF PRDB¹⁷. База PRDB не только содержала классификацию каждой сети как CO или RE, но также включала список предпочтительных точек входа в NSFNET для доступа в каждую сеть. Это послужило основой для современной системы оценки уровня предпочтений BGP LOCAL_PREF. Средства, обеспечиваемые PRDB позволяли полностью сгенерировать конфигурационные параметры маршрутизатора для NSFNET.

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

После того, как NSFNET прекратила в 1995 году предоставление магистральных услуг, было принято решение о том, что PRDB следует отделить от конкретного провайдера, а унаследованное содержимое базы данных и ее последующее обновление сделать достоянием всех провайдеров, желающих пользоваться этой базой данных. Европейское сетевое сообщество в течение долгого времени считало, что PRDB слишком концентрируется на США. На базе RIPE¹⁸ был создан открытый формат RIPE-181 и поддерживается открытая база данных о регистрации адресов и номеров AS, а также политики маршрутизации. База PRDB была преобразована в формат RIPE-181 и были также переработаны инструменты для работы с этим форматом. Набор баз данных стал называться Реестром маршрутизации Internet (IRR), начальными компонентами которого были база данных RIPE и созданный с помощью NSF Routing Arbitrator¹⁹ (RA).

Через некоторое время стала ясна необходимость расширения RIPE-181 и было получено согласие RIPE на такое расширение, которое было создано рабочей группой IETF RPS, как язык RPSL. Другим результатом работы RPS явилась модель аутентификации и способ широкого распространения базы данных с сохранением контроля и синхронизацией множества хранилищ. Были разработаны свободно распространяемые инструменты, созданные прежде всего RIPE, Merit, и ISI (наиболее полным является набор ISI). Усилия участников IRR были несколько затруднены провайдерами, не желающими предоставлять в IRR актуальную информацию. Наиболее крупные из таких провайдеров заявляли устно, что поддержка записей в базе данных создает дополнительную нагрузку для администраторов, содержащаяся в базе информация может давать преимущества их конкурентам, использующим IRR. Результатом этого стала фактическая бесполезность IRR и повышение уровня уязвимости Internet к атакам, направленным на систему маршрутизации, и эпизодическим вставкам ложной маршрутной информации.

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

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

Мы благодарим Paul Traina и Yakov Rekhter за разработку предыдущей версии этого документа и создание хорошей основы для данного обновления. Благодарим также Curtis Villamizar за написание текста и просмотр документа. Спасибо Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich и Jude Ballard за их проницательный взгляд на документ.

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

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

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

[RFC1966] Bates, T. and R. Chandra, «BGP Route Reflection An alternative to full mesh IBGP», RFC 1966, June 1996.

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, «BGP Route Flap Damping», RFC 2439, November 1998.

[RFC2796] Bates, T., Chandra, R., and E. Chen, «BGP Route Reflection — An Alternative to Full Mesh IBGP», RFC 2796, April 2000.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, «Autonomous System Confederations for BGP», RFC 3065, February 2001.

[RFC4274] Meyer, D. and K. Patel, «BGP-4 Protocol Analysis», RFC 4274, January 2006.

[RFC4276] Hares, S. and A. Retana, «BGP 4 Implementation Report», RFC 4276, January 2006.

[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC1657] Willis, S., Burruss, J., Chu, J., «Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2», RFC 1657²³, July 1994.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

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

[RFC1105] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol (BGP)», RFC 1105, June 1989.

[RFC1163] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol (BGP)», RFC 1163, June 1990.

[RFC1264] Hinden, R., «Internet Engineering Task Force Internet Routing Protocol Standardization Criteria», RFC 1264, October 1991.

[RFC1267] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol 3 (BGP-3)», RFC 1267, October 1991.

[RFC1269] Willis, S. and J. Burruss, «Definitions of Managed Objects for the Border Gateway Protocol: Version 3», RFC 1269, October 1991.

[RFC1656] Traina, P., «BGP-4 Protocol Document Roadmap and Implementation Experience», RFC 1656, July 1994.

[RFC1771] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[RFC1773] Traina, P., «Experience with the BGP-4 protocol», RFC 1773, March 1995.

[RFC1965] Traina, P., «Autonomous System Confederations for BGP», RFC 1965, June 1996.

[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, «Routing Policy Specification Language (RPSL)», RFC 2622, June 1999.

[BGPATTACK] Convery, C., «An Attack Tree for the Border Gateway Protocol», Work in Progress²⁷.

[SBGP] «Secure BGP», Work in Progress⁸.

[soBGP] «Secure Origin BGP», Work in Progress⁸.

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

Danny McPherson

Arbor Networks

EMail: danny@arbor.net

Keyur Patel

Cisco Systems

EMail: keyupate@cisco.com

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

Network Working Group                                       S. Hares
Request for Comments: 4276                                   NextHop
Category: Informational                                    A. Retana
                                                               Cisco
                                                        January 2006

Отчет о реализации протокола BGP-4

BGP-4 Implementation Report

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

В этом документе рассматриваются результаты опроса по реализациям протокола BGP-4. Опрос содержал 259 вопросов о реализациях, поддерживающих протокол BGP-4 в соответствии со спецификацией RFC 4271. После краткого обзора приведены все полученные отклики. Документ содержит отклики от 4 разработчиков, которые полностью ответили на вопросы (Alcatel, Cisco, Laurel и NextHop), а также краткую информацию от 3 других разработчиков (Avici, Data Connection Ltd. и Nokia).

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

1. Введение

В этом документе рассматриваются результаты опроса по реализациям протокола BGP-4. RFC 4271 приведен в соответствие с текущей установленной базой BGP-4 и отменяет действие [RFC1771]. Протокол BGP является широко распространенным протоколом, являющимся основой технологии Internet и добавляющим новые функции по мере необходимости в процессе развития Internet. В современной сети Internet протокол BGP-4 включает как базовую спецификацию, так и множество дополнительных спецификаций, таких, как TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065] и BGP Route Refresh [RFC2918].

Опрос о реализациях BGP содержал 259 вопросов о соответствии спецификации RFC 4271. Четыре разработчика (Alcatel, Cisco, Laurel и NextHop) полностью ответили на вопросы. Результаты обработки этих ответов приведены в главе 3.

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

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

1.1. Используемые соглашения

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

2. Результаты опроса

Респонденты должны были ответить Y (да) или N (нет) на 259 вопросов, чтобы показать, насколько их реализация поддерживает функции/описание в терминах [RFC2119] требований спецификации [RFC4271].

Респонденты могли указать ответ O (иное) для индикации ответов, которые не могли трактоваться как Y или N (например, альтернативный вариант поведения).

2.1. Значимые различия

Каждый вопрос, на который было получено не менее двух неотрицательных ответов (т. е., два Y или Y и O), за исключением следующих вопросов:

1. необходимо – связанные вопросы 212 и 213, относящиеся к параграфу 9.1.4

   Из-за принятого формата связанных вопросов три производителя (Cisco, Laurel и NextHop) ответили N на вопрос 213 (подробности приведены в параграфе 2.2).

2. не следует – вопрос 228, относящийся к параграфу 9.2.2.2

   Три производителя (Alcatel, Cisco и Laurel) ответили N для не следует (означает, что они делают это). Один производитель (NextHop) указал O, что соответствует спецификации.

   Текст: Маршруты с разными атрибутами MULTI_EXIT_DISC не следует агрегировать (параграф 9.2.2.2, [RFC4271])

3. следует – вопросы 257 и 258, относящиеся к Приложению F

   Три производителя ответили N и один — Y на вопрос 257. Все 4 производителя ответили N на вопрос 258 (отметим, что поддержка Приложения F Рекомендации для разработчиков не является обязательной.)

   Текст¹: Во избежание ненужных осцилляций маршрутов (route flapping) узлу BGP, которому нужно отозвать адресата и передать обновление с более (или менее) специфичным маршрутом, следует объединять анонсы в одно сообщение UPDATE. (Приложение F.2, [RFC4271])

   Текст: Последний (самый правый) экземпляр данного номера AS сохраняется. (Приложение F.6, [RFC4271])

4. возможно – вопросы 180 и 254, относящиеся к параграфу 8.2.1.4² и главе 10

   Три производителя ответили N и один — Y на вопрос 180.

   Текст: Номера событий (1-28) используются при описании машины состояний. Реализации могут использовать эти номера для систем сетевого управления. Точная форма FSM или событий FSM зависит от реализации. (параграф 8.2.1.4, [RFC4271])

   Примечание редактора: Параграф 8.2.1.4 был включен для того, чтобы позволить существующим реализациям перейти к новой нумерации событий. Предполагается, что по прошествии времени (3 года) нумерация событий FSM будет заменена на новую.

   На вопрос 254 о настройке значений параметра флуктуации³ три производителя ответили N и один Y.

   Текст: Данный узел BGP может использовать одинаковые флуктуации для каждого из этих таймеров независимо от адресатов передаваемых обновлений (т. е., флуктуации не требуется делать независимыми для каждого партнера). (глава 10, [RFC4271])

   Вопрос: Является ли диапазон флуктуаций настраиваемым?

2.2. Обзор отличий

В этом параграфе дается обзор отличий между 4 реализациями протокола.

На перечисленные ниже вопросы не было получено ответа Y ни от одного из 4 респондентов. Отметим, что номера вопросов соответствуют последней части номера параграфов в главе 3.

необходимо

97, 106, 107, 111, 122, 125, 138, 141, 213

нужно

233, 239

не следует

228

следует

42, 117, 132, 146, 152, 155, 156, 157, 158, 159, 160, 161, 163, 164, 165, 169, 170, 171, 173, 174, 175, 202, 225, 250, 255, 256

не нужно

226

возможно

67, 94, 121, 143, 180, 223, 247, 254

Прочее

236, 238

Связанные вопросы

212/213

Три производителя ответили N и один — Y на вопрос 213 об агрегировании маршрутов. Вопросы 212 и 213 были объединены в один.

Вопрос 212: «процесс выбора должен установить в Loc-RIB оба маршрута или …»

Вопрос 213: «объединить их и установить в Loc-RIB агрегированный маршрут, что обеспечивается наличием в обоих маршрутах одинакового значения атрибута NEXT_HOP»

Четыре респондента ответили Y на вопрос 212, три сказали N в ответ на вопрос 213. В контексте вопроса ответ N на вопрос 213 является допустимым.

2.3. Взаимодействие реализаций

2.4. Идентификация реализаций BGP

1.6.0 Alcatel

Разработчик/версия: Alcatel 7750 BGP Implementation Release 1.3

Дата: июль 2003

Контактное лицо: Devendra Raut

Электронная почта: Devendra.raut@Alcatel.com

1.6.1 Cisco

Разработчик/версия: Cisco BGP Implementation, 12.0(27)S

Контактное лицо: Alvaro Retana

Дата: 26 ноября 2003

1.6.2 Laurel

Разработчик/версия: Laurel Networks 3.0

Контактное лицо: Manish Vora

Электронная почта: vora@laurelnetworks.com

Дата: 1 февраля 2004

1.6.3 NextHop Technologies

Разработчик/версия: Gated NGC 2.0, 2.2

Дата: январь 2004

3. Отчет о реализациях BGP-4

Для каждого из перечисленных элементов респонденты указывали поддерживает ли их реализация Функции/описание (Y/N) согласно спецификации требований [RFC2119]. Все комментарии респондентов приведены в тексте. В некоторых случаях респонденты давали ответ O (иное), показывающий, что варианты Y/N не подходят (например, альтернативный вариант поведения). Для лучшего понимания указаны ссылки на соответствующие разделы спецификации [RFC4271]. Отметим, что последняя часть номера параграфа в этой главе совпадает с номером вопроса.

3.0. Основы работы протокола, глава 3 [RFC4271]

3.0.1. Базовое поведение

Функции/описание: Совместима ли ваша реализация с базовым поведением протокола, описанным в этой главе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.0.2. Локальное изменение политики

Функции/описание: Чтобы позволить активизацию изменений локальной политики без сброса соединений BGP, узлу BGP следует (a) сохранить текущую версию маршрутов, анонсированных всеми партнерами в течение сеанса или (b) использовать расширение Route Refresh [RFC2918]

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.1. Маршруты – анонсирование и хранение, параграф 3.1 [RFC4271]

3.1.3. Отзыв маршрутов

Функции/описание: Поддерживает ли ваша реализация три метода, описаных в этом параграфе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.1.4. Атрибуты пути

Функции/описание: Добавление или изменение атрибутов перед анонсированием маршрута.

RFC2119: MAY (можно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.2. База маршрутной информации, параграф 3.2 [RFC4271]

3.2.5. Базы маршрутной информации

Функции/описание: Совместима ли ваша реализация со структурой RIB, описанной в этом параграфе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.2.6. Преобразование Next Hop

Функции/описание: Значение следующего интервала (next hop) для каждого из маршрутов таблицы Loc-RIB должно быть преобразуемым с помощью локальной таблицы маршрутизации узла BGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.3. Формат сообщений, глава 4 [RFC4271]

3.3.7. Размер сообщений

Функции/описание: Поддерживает ли ваше реализация размеры сообщений, указанные в этой главе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.4. Формат заголовка сообщений, параграф 4.1 [RFC4271]

3.4.8. Marker

Функции/описание: Поле должно содержать только единицы.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.4.9. Length

Функции/описание: Значение поля должно быть не менее 19 и не более 4096

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.4.10. Length

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

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.4.11. Заполнение сообщений

Функции/описание: Не допускается добавление в конце сообщения ненужных байтов заполнения (padding), следовательно поле Length должно иметь минимальное значение, достаточное для размещения остальной части сообщения.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.5. Формат сообщения OPEN, параграф 4.2 [RFC4271]

3.5.12. Расчет значения Hold Timer

Функции/описание: Использование меньшего из двух значений Hold Time – заданного в параметрах конфигурации и полученного в сообщении OPEN.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.5.13. Минимальное значение Hold Time

Функции/описание: Значение этого параметра должно быть нулевым или не менее трех секунд.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.5.14. Отказ от приема соединения

Функции/описание: На основе Hold Time

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y Передается уведомление.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6. Формат сообщения UPDATE, параграф 4.3 [RFC4271]

3.6.15. UPDATE

Функции/описание: Одновременное анонсирование доступного маршрута и отзыв недоступных маршрутов.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: O Мы обеспечиваем поддержку этой возможности на приемной стороне, но не можем анонсировать и отзывать маршруты одновременно.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.16. Установка бита Transitive

Функции/описание: Для общепринятых (well-known) атрибутов бит Transitive должен иметь значение 1

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.17. Установка бита Partial

Функции/описание: Для общепринятых и дополнительных непереходных атрибутов бит Partial должен иметь значение 0

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.18. Передача октета флагов атрибута

Функции/описание: Четыре младших бита имеют нулевое значение.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.19. Прием октета флагов атрибута

Функции/описание: Четыре младших бита игнорируются.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.20. NEXT_HOP

Функции/описание: Используется как следующий интервал на пути к адресату, указанному в поле NLRI сообщения UPDATE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.21. MULTI_EXIT_DISC

Функции/описание: Используется узлом BGP в процессе выбора маршрутов для разделения множества точек входа в соседнюю AS.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.22. IP-адрес AGGREGATOR

Функции/описание: Тот же адрес, который указывается в поле BGP Identifier для данного узла.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y Используется по умолчанию. В конфигурации можно задать использование другого адреса.

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.23. Сообщения UPDATE с одинаковым префиксом в WITHDRAWN ROUTES и NLRI

Функции/описание: В сообщения UPDATE не следует включать такие данные.

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.24. Сообщения UPDATE с одинаковым префиксом в WITHDRAWN ROUTES и NLRI

Функции/описание: Узел BGP должен быть способен обрабатывать такие сообщения.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.6.25. Сообщения UPDATE с одинаковым префиксом в WITHDRAWN ROUTES и NLRI

Функции/описание: Трактовка поля WITHDRAWN ROUTES как не содержащего адресный префикс.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y Отзываемые маршруты обрабатываются до полей NLRI. Следовательно, мы обеспечиваем желаемое поведение.

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.7. Формат сообщения KEEPALIVE, параграф 4.4 [RFC4271]

3.7.26. Максимальная частота передачи KEEPALIVE

Функции/описание: Недопустимо передавать более одного сообщения в секунду.

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.7.27. Частота передачи сообщений KEEPALIVE

Функции/описание: Задается как функция интервала Hold Time.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.7.28. Согласование нулевого значения Hold Time

Функции/описание: Сообщения KEEPALIVE не передаются

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.8. Формат сообщения NOTIFICATION, параграф 4.5 [RFC4271]

3.8.29. Сообщение NOTIFICATION

Функции/описание: Поддерживает ли ваша реализация сообщения NOTIFICATION, описанные в этом параграфе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9. Атрибуты пути, глава 5 [RFC4271]

3.9.30. Атрибуты пути

Функции/описание: Поддерживает ли ваша реализация атрибуты пути, описанные в этой главе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.31. Общепринятые атрибуты

Функции/описание: Распознаются всеми реализациями BGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.32. Обязательные атрибуты

Функции/описание: Включаются в каждое сообщение UPDATE, содержащее NLRI.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.33/34. Необязательные атрибуты

Функции/описание: Передаются в отдельных сообщениях UPDATE.

RFC2119: MAY (возможно) или MAY NOT (необязательно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.35. Общепринятые атрибуты

Функции/описание: Передаются другим партнерам BGP (после возможного изменения).

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.36. Дополнительные атрибуты

Функции/описание: В дополнение к общепринятым атрибутам каждый путь может содержать один или множество дополнительных атрибутов.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.37. Нераспознанные транзитивные дополнительные атрибуты

Функции/описание: Принимаются

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.38. Бит Partial для нераспознанных переходных дополнительных атрибутов

Функции/описание: Устанавливается значение 1, если атрибут принят и передается другим узлам BGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.39. Нераспознанные непереходные дополнительные атрибуты

Функции/описание: Игнорируются и не передаются другим партнерам BGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.40. Новые транзитивные дополнительные атрибуты

Функции/описание: Добавляются к пути в исходной точке маршрута (originator) или любым другим узлом BGP на пути.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.41. Дополнительные атрибуты

Функции/описание: Обновляются узлами BGP на пути.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.42. Атрибуты пути

Функции/описание: Упорядочиваются по возрастанию идентификаторов типа атрибута.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: O Все атрибуты упорядочиваются по возрастанию идентификатора типа за исключением атрибута Extended Community, который имеет тип 16, но передается после атрибута группы (community).

Laurel Y/N/O/комментарии: Y Упорядочиваются все атрибуты за исключением MBGP, который всегда указывается последним

NextHop Y/N/O/комментарии: Y

3.9.43. Прием атрибутов с нарушенным порядком

Функции/описание: Получатель должен обеспечивать возможность обработки

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.9.44. Обязательные атрибуты

Функции/описание: Присутствуют в каждом обмене, если в сообщении UPDATE имеется атрибут NLRI.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.10. Атрибут ORIGIN, параграф 5.1.1 [RFC4271]

3.10.45. ORIGIN

Функции/описание: Значение не следует изменять никакому узлу за исключением исходного (originator).

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.11. Атрибут AS_PATH, параграф 5.1.2 [RFC4271]

3.11.46. AS_PATH

Функции/описание: Не изменяется при анонсировании маршрута внешним партнерам.

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.11.47. Переполнение сегмента

Функции/описание: Если при добавлении в начало (prepending) будет возникать переполнение в сегменте AS_PATH (число AS превысит 255), нужно добавить в начало (prepend) новый сегмент типа AS_SEQUENCE и указать свой номер AS в начале этого сегмента.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.11.48. Добавление себя в начало (Prepending)

Функции/описание: Локальная система может добавлять в начало или включать (include/prepend) более одного экземпляра своего номера AS в атрибут AS_PATH.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12. Атрибут NEXT_HOP, параграф 5.1.3 [RFC4271]

3.12.49. NEXT_HOP

Функции/описание: Используется как следующий интервал на пути к адресатам, указанным в сообщении UPDATE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.50. NEXT_HOP

Функции/описание: При передаче внутреннему партнеру маршрута, имеющего нелокальное происхождение, узлу BGP не следует изменять атрибут NEXT_HOP, если узел явно не настроен на передачу собственного адреса IP в качестве NEXT_HOP.

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.51. NEXT_HOP

Функции/описание: При анонсировании внутреннему партнеру маршрута локального происхождения узлу BGP нужно использовать в качестве значения NEXT_HOP адрес интерфейса маршрутизатора, через который анонсируемая сеть доступна для этого узла.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.52. NEXT_HOP

Функции/описание: Если маршрут непосредственно подключен к данному узлу или адрес интерфейса, через который анонсируемая сеть доступна для узла, является адресом внутреннего партнера, узлу BGP нужно использовать в качестве атрибута NEXT_HOP свой адрес IP (адрес интерфейса, используемого для доступа к партнеру).

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.53. NEXT_HOP из “первых рук”

Функции/описание: Если внешний партнер, которому будет анонсироваться маршрут, разделяет общую подсеть с одним из интерфейсов анонсирующего узла BGP, этот узел может использовать IP-адрес такого интерфейса в качестве атрибута NEXT_HOP.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.54. Значение NEXT_HOP по умолчанию

Функции/описание: IP-адрес интерфейса, который узел использует для организации BGP-соединения с партнером X.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.55. Распространение NEXT_HOP

Функции/описание: Узел может быть настроен на распространение атрибута NEXT_HOP. В этом случае при анонсировании маршрута, полученного узлом от одного из своих партнеров значение атрибута NEXT_HOP в анонсируемом маршруте должно совпадать со значением атрибута NEXT_HOP в полученном от партнера маршруте (узел просто не должен менять атрибут NEXT_HOP).

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: O

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.56. NEXT_HOP из “третьих рук”

Функции/описание: Должна обеспечиваться возможность запрета.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.57. NEXT_HOP

Функции/описание: Маршрут, порожденный узлом BGP не следует анонсировать анонсировать партнеру с указанием адреса интерфейса этого партнера в качестве NEXT_HOP.

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.58. NEXT_HOP

Функции/описание: Узлу BGP не следует устанавливать маршруты со своим адресом в качестве NEXT_HOP.

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.59. NEXT_HOP

Функции/описание: Используется для определения реального выходного интерфейса и адреса непосредственно следующего интервала (immediate next-hop), который следует использовать для пересылки пакетов соответствующим адресатам.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.60. Преобразованный IP-адрес NEXT_HOP

Функции/описание: Если запись задает непосредственно подключенную подсеть, но не задает адрес следующего интервала, следует использовать значение атрибута NEXT_HOP в качестве адреса непосредственно следующего интервала.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.12.61. Преобразованный IP-адрес NEXT_HOP

Функции/описание: Если запись задает также адрес следующего интервала, этот адрес следует использовать при пересылке, как адрес непосредственно следующего интервала.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.13. Атрибут MULTI_EXIT_DISC, параграф 5.1.4 [RFC4271]

3.13.62. Предпочтительная метрика

Функции/описание: Наименьшее значение

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.13.63. MULTI_EXIT_DISC

Функции/описание: Полученный через EBGP атрибут MULTI_EXIT_DISC можно распространять через IBGP другим узлам BGP в той же AS.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.13.64. MULTI_EXIT_DISC

Функции/описание: Полученный из соседней AS атрибут MED недопустимо распространять в другие соседние AS.

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.13.65. Удаление MULTI_EXIT_DISC

Функции/описание: Локальный конфигурационный механизм для удаления атрибута из маршрута.

RFC2119: MUST (требуется)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.13.66. Удаление MULTI_EXIT_DISC

Функции/описание: Выполняется до определения степени предпочтения маршрута и выполнения процедур выбора маршрутов.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.13.67. Изменение MULTI_EXIT_DISC

Функции/описание: Реализация может также (в соответствии с локальными настройками) изменять значение атрибута MULTI_EXIT_DISC, полученного через EBGP.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: O

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.13.68. Изменение MULTI_EXIT_DISC

Функции/описание: Выполняется до определения степени предпочтения маршрута и выполнения процедур выбора маршрутов.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.14. LOCAL_PREF, параграф 5.1.5 [RFC4271]

3.14.69. LOCAL_PREF

Функции/описание: Включается во все сообщения UPDATE, которые данный узел BGP передает внутренним партнерам.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.14.70. Степень предпочтения

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

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.14.71. LOCAL_PREF

Функции/описание: Высшей значение должно быть наиболее предпочтительным.

RFC2119: MUST (требуется)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.14.72. LOCAL_PREF

Функции/описание: Не включается в сообщения UPDATE, передаваемые внешним партнерам, за исключением случаев участия в конфедерации BGP [RFC3065]

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.14.73. LOCAL_PREF

Функции/описание: Игнорируется, если принят от внешнего партнера, за исключением случаев участия в конфедерации BGP [RFC3065]

RFC2119: MUST (требуется)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.15. ATOMIC_AGGREGATE, параграф 5.1.6 [RFC4271]

3.15.74. ATOMIC_AGGREGATE

Функции/описание: Включается, если при агрегировании маршрута исключается по крайней мере один из номеров AS, присутствующих в AS_PATH объединяемых маршрутов в результате отбрасывания AS_SET.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.15.75. Принимаемые атрибуты ATOMIC_AGGREGATE

Функции/описание: Узлу BGP не нужно удалять этот атрибут при распространении маршрута другим узлам.

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.15.76. Принимаемые атрибуты ATOMIC_AGGREGATE

Функции/описание: Узлу BGP недопустимо делать любые NLRI из маршрута с таким атрибутом более специфичными (как указано в параграфе 9.1.4).

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.16. AGGREGATOR, параграф 5.1.7 [RFC4271]

3.16.77. AGGREGATOR

Функции/описание: Включается в обновления, которые формируются в результате агрегирования маршрутов (смю параграф 9.2.2.2)

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.16.78. AGGREGATOR

Функции/описание: Добавляется узлом BGP, выполняющим объединение маршрутов.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.16.79. AGGREGATOR

Функции/описание: Содержит номер локальной AS и адрес IP.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y Используется по умолчанию. Локальная конфигурация может задавать использование другого адреса IP.

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.16.80. IP-адрес AGGREGATOR

Функции/описание: Совпадает со значением BGP Identifier данного узла.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.17. Обработка ошибок BGP, глава 6 [RFC4271]

3.17.81. Обработка ошибок

Функции/описание: Совместима ли ваша реализация с процедурами обработки ошибок, описанными в этой главе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.17.82. Субкод ошибки

Функции/описание: Считается нулевым, если не указан.

RFC2119: MUST

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.18. Обработка ошибок в заголовках сообщений, параграф 6.1 [RFC4271]

3.18.83. Ошибки в заголовке сообщений

Функции/описание: Указываются путем передачи сообщения NOTIFICATION с кодом ошибки Message Header Error

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.18.84. Ошибки синхронизации

Функции/описание: Для субкода ошибки должно устанавливаться значение Connection Not Synchronized

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.18.85. Размер сообщения

Функции/описание: Для индикации некорректного размера сообщения должен использоваться субкод Bad Message Length.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.18.86. Некорректный размер сообщения

Функции/описание: Поле Data должно содержать некорректное значение поля Length вызвавшего ошибку сообщения.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.18.87. Поле Type

Функции/описание: Если поле Type в заголовке сообщения не распознано, для субкода ошибки должно устанавливаться значение Bad Message Type

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.18.88. Некорректный тип сообщения

Функции/описание: Поле Data должно содержать некорректное значение поля Type вызвавшего ошибку сообщения.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19. Обработка ошибок в сообщениях OPEN, параграф 6.2 [RFC4271]

3.19.89. Ошибки в сообщениях OPEN

Функции/описание: Указываются путем передачи сообщения NOTIFICATION с кодом ошибки OPEN Message Error

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.90. Номер версии не поддерживается

Функции/описание: Для субкода ошибки должно указываться значение Unsupported Version Number.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.91. Недопустимое значение поля Autonomous System

Функции/описание: Для субкода ошибки должно указываться значение Bad Peer AS.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.92. Субкод недопустимого значения Hold Time

Функции/описание: Этот субкод используется в тех случаях, когда поле Hold Time в сообщении OPEN содержит недопустимое значение.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.93. Отказ от полученного значения Hold Time

Функции/описание: Значения в 1 или 2 секунды

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.94. Отказ от полученного значения Hold Time

Функции/описание: Реализация может отвергать любое предложенное значение Hold Time.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: Y

3.19.95. Значение Hold Time

Функции/описание: Если параметр принят, должно использоваться согласованное значение.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.96. Синтаксически некорректное значение BGP Identifier

Функции/описание: Должен указываться субкод ошибки Bad BGP Identifier.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.97. Нераспознанные дополнительные параметры

Функции/описание: Для субкода ошибки должно указываться значение Unsupported Optional Parameters

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N We may fix this.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.19.98. Распознанные, но некорректно сформированные дополнительные параметры

Функции/описание: Для субкода ошибки должно указываться значение 0 (Unspecific – не задан).

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20. Обработка ошибок в сообщениях UPDATE, параграф 6.3 [RFC4271]

3.20.99. Ошибки в сообщениях UPDATE

Функции/описание: Указываются путем передачи сообщения NOTIFICATION с кодом ошибки UPDATE Message Error

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.100. Слишком большое сообщение

Функции/описание: Если размер Withdrawn Routes или Total Attribute Length слишком велик, должно указываться значение субкода Malformed Attribute List

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.101. Конфликт флагов

Функции/описание: Если любой из распознанных атрибутов имеет поле Attribute Flags, конфликтующее с полем Attribute Type Code, должен указываться субкод ошибки Attribute Flags Error.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.102. Конфликт флагов

Функции/описание: Поле Data должно содержать значение вызвавшего ошибку атрибута.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.103. Конфликт размера

Функции/описание: Если любой из распознанных атрибутов имеет значение поля Attribute Length, конфликтующее с ожидаемым размером, для субкода ошибки должно указываться значение Attribute Length Error.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.104. Конфликт размера

Функции/описание: Поле Data должно содержать вызвавший ошибку атрибут.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.105. Отсутствие обязательных общепринятых атрибутов

Функции/описание: Для субкода ошибки должно указываться значение Missing Well-known Attribute.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.106. Отсутствие обязательных общепринятых атрибутов

Функции/описание: Поле Data должно содержать значение кода типа (Attribute Type Code) для пропущенного атрибута.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N Планируется исправить это в будущих версиях.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.107. Нераспознанный обязательный общепринятый атрибут

Функции/описание: Для субкода ошибки должно указываться значение Unrecognized Well-known Attribute

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N Указывается субкод Attribute Flags Error, но в будущих версиях планируется исправить эту некорректность.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.108. Нераспознанный обязательный общепринятый атрибут

Функции/описание: Поле Data должно содержать нераспознанный атрибут.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.109. Неопределенное значение ORIGIN

Функции/описание: Для субкода ошибки должно указываться значение Invalid Origin Attribute

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.110. Неопределенное значение ORIGIN

Функции/описание: Поле Data должно содержать нераспознанный атрибут.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.111. Синтаксически некорректное значение NEXT_HOP

Функции/описание: Для субкода ошибки должно указываться значение Invalid NEXT_HOP Attribute.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N В случае получения “марсианского” значения для следующего интервала или при несовпадении размера полученного адреса с размером адреса Ipv4 префикс игнорируется и передается сообщение NOTIFICATION с субкодом ошибки Attribute Length.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.112. Синтаксически некорректное значение NEXT_HOP

Функции/описание: В поле Data должно включаться значение некорректного атрибута.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.113. Семантическая корректность NEXT_HOP

Функции/описание: Проверяется семантическая корректность атрибута NEXT_HOP в соответствии с критериями спецификации.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.114. Семантическая корректность NEXT_HOP

Функции/описание: Недопустимо наличие в полученном атрибуте IP-адреса принявшего сообщение узла.

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.115. Семантическая корректность NEXT_HOP

Функции/описание: В случае EBGP, когда между отправителем и получателем один интервал IP (IP hop), адрес в поле NEXT_HOP должен быть IP-адресом отправителя (который использовался для организации соединения BGP) или интерфейс, связанный с адресом NEXT_HOP должен находиться в одной подсети с принимающим узлом BGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.116. Семантическая некорректность NEXT_HOP

Функции/описание: Информация об ошибке записывается в журнальный файл.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.117. Семантическая некорректность NEXT_HOP

Функции/описание: Маршрут игнорируется.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: Y

3.20.118. Семантическая некорректность NEXT_HOP

Функции/описание: Сообщение NOTIFICATION не передается.

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.119. Семантическая некорректность NEXT_HOP

Функции/описание: Соединение не разрывается

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.120. Семантическая некорректность AS_PATH

Функции/описание: Для субкода ошибки должно указываться значение Malformed AS_PATH.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.121. Проверка первого соседа в AS_PATH

Функции/описание: Если сообщение UPDATE получено от внешнего партнера, локальная система может проверить совпадение самого левого значения AS в атрибуте AS_PATH с номером автономной системы передавшего сообщение соседа.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: Y

3.20.122. Проверка первого соседа в AS_PATH

Функции/описание: Если при проверке⁴ обнаружилось, что номера автономных систем не совпадают, должно указываться значение субкода ошибки Malformed AS_PATH.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: n/a

NextHop Y/N/O/комментарии: Y

3.20.123. Дополнительные атрибуты

Функции/описание: Если атрибут распознан, его значение должно проверяться.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.124. Ошибки в дополнительных атрибутах

Функции/описание: Атрибут должен отбрасываться.

RFC2119: MUST

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.125. Ошибки в дополнительных атрибутах

Функции/описание: Для субкода ошибки должно быть указано значение Optional Attribute Error.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N Что такое дополнительный атрибут? Если ошибка связана с флагом, мы передаем субкод Update Flag Error. Для ошибок, связанных с размером, передается субкод Update Length Error. Эти значения субкодов более эффективны при отладке, нежели субкод Optional Attribute Error.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y Единственной ошибкой, связанной с дополнительными атрибутами, которая не имеет специального субкода, является ошибка, связанная с atomic aggregate в версиях 3 и 4. Во всех остальных случаях передается более специфичный субкод ошибки, если он реализован.

3.20.126. Ошибки в дополнительных атрибутах

Функции/описание: Поле Data должно содержать связанный с ошибкой атрибут.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.127. Дубликаты атрибутов

Функции/описание: Если в сообщении UPDATE присутствует более одного экземпляра того или иного атрибута, должно передаваться сообщение NOTIFICATION с субкодом ошибки Malformed Attribute List

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.128. Семантически некорректное поле NLRI

Функции/описание: Для субкода ошибки должно быть установлено значение Invalid Network Field.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.129. Семантически некорректное поле NLRI

Функции/описание: Сообщение об ошибке следует сохранить в локальном журнале системы.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.130. Семантически некорректное поле NLRI

Функции/описание: Префикс следует игнорировать.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.20.131. Сообщения UPDATE без поля NLRI

Функции/описание: Сообщение UPDATE, содержащее корректные атрибуты пути, но не включающее NLRI, нужно трактовать как корректное сообщение UPDATE.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.21. Обработка ошибок в сообщениях NOTIFICATION, параграф 6.4 [RFC4271]

3.21.132. Ошибка в сообщении NOTIFICATION

Функции/описание: Отмечена, отражена в локальном журнале, информация передана также администратору партнера.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.22. Обработка ошибок Hold Timer Expired, параграф 6.5 [RFC4271]

3.22.133. Hold Timer Expired

Функции/описание: Совместима ли ваша реализация с процедурами обработки ошибок, описанными в этом параграфе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.23. Обработка ошибок FSM⁵, параграф 6.6 [RFC4271]

3.23.134. Ошибки FSM

Функции/описание: Совместима ли ваша реализация с процедурами обработки ошибок, описанными в этом параграфе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.24. Cease, параграф 6.7 [RFC4271]

3.24.135. Cease NOTIFICATION

Функции/описание: Используется при отсутствии критических ошибок, если узел BGP решает закрыть свое соединение.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N Мы закрываем сессии TCP без передачи CEASE NOTIFICATION.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.24.136. Cease NOTIFICATION

Функции/описание: Не используется при указанных в спецификации критических ошибках.

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.24.137. Верхний предел числа префиксов, принимаемых от соседа

Функции/описание: Поддерживается как параметр локальной конфигурации.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.24.138. Верхний предел числа префиксов, принимаемых от соседа

Функции/описание: При достижении порога и решении узла BGP о разрыве соединения должно передаваться сообщение Cease NOTIFICATION.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N Мы не передаем CEASE, но планируем вскоре исправить эту некорректность.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y Разрыв соединений не поддерживается. Рассматривается вопрос о поддержке в будущих версиях.

3.24.139. Верхний предел числа префиксов, принимаемых от соседа

Функции/описание: Достижение порога записывается в локальный системный журнал.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.25. Детектирование конфликтов в соединениях BGP, параграф 6.8 [RFC4271]

3.25.140. Конфликт соединений

Функции/описание: Одно из соединений должно быть закрыто.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.25.141. Получение сообщения OPEN

Функции/описание: Локальная система должна проверить все свои соединения, находящиеся в состоянии OpenConfirm.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: O Мы детектируем конфликты своим способом и метод разрешения конфликтов описан в документации.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.25.142. Получение сообщения OPEN

Функции/описание: Проверка соединений, находящихся в состоянии OpenSent, если известно значение BGP Identifier из внешних (по отношению к протоколу) источников.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.26. Согласование версии BGP, глава 7 [RFC4271]

3.26.143. Согласование версий

Функции/описание: Множественные попытки организации соединения BGP, начинающиеся со старшей версии, поддерживаемой узлом.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: N Поддерживается только версия 4

Cisco Y/N/O/комментарии: O Мы решаем эту проблему с помощью конфигурационных параметров. Если конфигурация создана для версии 3 и мы получаем версию 4, в ответ на сообщение OPEN всегда будут возвращаться отказ. Аналогично при настройке конфигурации для версии 4 (используется по умолчанию) мы не будем поддерживать партнеров версии 3, пока это не будет задано в конфигурации.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: N Поддерживается только версия 4

3.26.144. Будущие версии BGP

Функции/описание: Должны сохранять формат сообщений OPEN и NOTIFICATION.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.27. Машина конечных состояний BGP (FSM), глава 8 [RFC4271]

3.27.145. FSM

Функции/описание: Совместима ли ваша реализация с концептуальной моделью FSM, описанной в этой главе?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28. Административные события, параграф 8.1.2 [RFC4271]

3.28.146. Установка дополнительных атрибутов сессии

Функции/описание: Каждое событие имеет индикацию какие необязательные сеансовые атрибуты следует устанавливать на каждом этапе.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: O Это не очевидно. Мы поддерживаем опцию для ручной организации и прекращения сессий, но не опцию для всех дополнительных сеансовых атрибутов, указанных в спецификации.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y В данной реализации поддерживаются необязательные сеансовые атрибуты 1) Automatic start и 2) Automatic Stop, 3)

3.28.147. Событие 1: ManualStart

Функции/описание: Для атрибута PassiveTcpEstablishment следует устанавливать значение FALSE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.148. Событие 3: AutomaticStart

Функции/описание: Для атрибута AllowAutomaticStart следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.149. Событие 3: AutomaticStart

Функции/описание: Для атрибута PassiveTcpEstablishment следует устанавливать значение FALSE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.150. Событие 3: AutomaticStart

Функции/описание: Для атрибута DampPeerOscillations следует устанавливать значение FALSE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y Атрибут DampPeerOscillations не поддерживается и всегда имеет значение FALSE.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.151. Событие 4: ManualStart_with_PassiveTcpEstablishment

Функции/описание: Для атрибута PassiveTcpEstablishment следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y Мы ждем в течение фиксированного времени прежде, чем инициировать OPEN.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.152. Событие 4: ManualStart_with_PassiveTcpEstablishment

Функции/описание: Для атрибута DampPeerOscillations следует устанавливать значение FALSE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y Атрибут DampPeerOscillations не поддерживается и всегда имеет значение FALSE.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O Мы не поддерживаем отключение атрибута DampPeerOscilation и, следовательно, Событие 4. Новые версии будут поддерживать событие 4.

3.28.153. Событие 5: AutomaticStart_with_PassiveTcpEstablishment

Функции/описание: Для атрибута AllowAutomaticStart следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.154. Событие 5: AutomaticStart_with_PassiveTcpEstablishment

Функции/описание: Для атрибута PassiveTcpEstablishment следует устанавливать значение TRUE.

RFC2119: SHOULD

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.155. Событие 5: AutomaticStart_with_PassiveTcpEstablishment

Функции/описание: Для атрибута DampPeerOscillations следует устанавливать значение FALSE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y Атрибут DampPeerOscillations не поддерживается и всегда имеет значение FALSE.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O Мы не поддерживаем установку для атрибута DampPeerOscilation значения FALSE и, следовательно, не поддерживаем Событие 5. В будущих версиях планируется такая поддержка.

3.28.156. Событие 6: AutomaticStart_with_DampPeerOscillations

Функции/описание: Для атрибута AllowAutomaticStart следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Атрибут DampPeerOscillations не поддерживается.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.157. Событие 6: AutomaticStart_with_DampPeerOscillations

Функции/описание: Для атрибута DampPeerOscillations следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: N Атрибут DampPeerOscillations не поддерживается.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.158. Событие 6: AutomaticStart_with_DampPeerOscillations

Функции/описание: Для атрибута PassiveTcpEstablishment следует устанавливать значение FALSE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Не поддерживается атрибут DampPeerOscillations и, следовательно, Событие 6.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.159. Событие 7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

Функции/описание: Для атрибута AllowAutomaticStart следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Атрибут DampPeerOscillations не поддерживается, равно как и Событие 7.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.160. Событие 7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

Функции/описание: Для атрибута DampPeerOscillations следует устанавливать значение TRUE.

RFC2119: SHOULD

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Не поддерживается атрибут DampPeerOscillations и, следовательно, Событие 7.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.161. Событие 7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

Функции/описание: Для атрибута PassiveTcpEstablishment следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Не поддерживается атрибут DampPeerOscillations и, следовательно, Событие 7.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.28.162. Событие 8: AutomaticStop

Функции/описание: Для атрибута AllowAutomaticStop следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.29. События, связанные с таймерами, параграф 8.1.3 [RFC4271]

3.29.163. Событие 12: DelayOpenTimer_Expires

Функции/описание: DelayOpen следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: n/a

NextHop Y/N/O/комментарии: Y

3.29.164. Событие 12: DelayOpenTimer_Expires

Функции/описание: Следует поддерживать атрибут DelayOpenTime.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: n/a

NextHop Y/N/O/комментарии: Y

3.29.165. Событие 12: DelayOpenTimer_Expires

Функции/описание: Следует поддерживать DelayOpenTimer.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: n/a

NextHop Y/N/O/комментарии: Y

3.29.166. Событие 13: IdleHoldTimer_Expires

Функции/описание: Следует поддерживать атрибут DampPeerOscillations.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Атрибут DampPeerOscillations и Событие 13 не поддерживаются.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.29.167. Событие 13: IdleHoldTimer_Expires

Функции/описание: Отсчет таймера IdleHoldTimer следует считать завершенным.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Атрибут DampPeerOscillations и Событие 13 не поддерживаются.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.30. События, связанные с соединениями TCP, параграф 8.1.4 [RFC4271]

3.30.168. Событие 14: TcpConnection_Valid

Функции/описание: В качестве порта получателя для BGP следует использовать порт с номером 179.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.30.169. Событие 14: TcpConnection_Valid

Функции/описание: Для атрибута TrackTcpState следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O GateD NGC 2.0 обеспечивает “ловушки” для отслеживания состояний TCP, но использование этой опции зависит от ее поддержки операционной системой. В будущих версиях появятся новые ловушки.

3.30.170. Событие 15: Tcp_CR_Invalid

Функции/описание: Для атрибута TrackTcpState следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O GateD NGC 2.0 обеспечивает “ловушки” для отслеживания состояний TCP, но использование этой опции зависит от ее поддержки операционной системой. В будущих версиях появятся новые ловушки.

3.31. События, связанные с сообщениями BGP, параграф 8.1.5 [RFC4271]

3.31.171. Событие 19: BGP Open

Функции/описание: Для дополнительного атрибута DelayOpen следует устанавливать значение FALSE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: n/a

NextHop Y/N/O/комментарии: Y

3.31.172. Событие 19: BGP Open

Функции/описание: Не следует запускать таймер DelayOpenTimer.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.31.173. Событие 20: BGP Open при включенном таймере DelayOpenTimer

Функции/описание: Для атрибута DelayOpen следует устанавливать значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N Неприменимо.

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: n/a

NextHop Y/N/O/комментарии: Y

3.31.174. Событие 20: BGP Open при включенном таймере DelayOpenTimer

Функции/описание: Таймер DelayOpenTimer следует держать в активном состоянии.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: n/a

NextHop Y/N/O/комментарии: Y

3.31.175. Событие 23: OpenCollisionDump

Функции/описание: Если машина FSM при обработке этого события находится в состоянии Established, для атрибута CollisionDetectEstablishedState следует установить значение TRUE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y Обнаруженные конфликты записываются в журнальный файл системы.

Cisco Y/N/O/комментарии: O Мы всегда детектируем конфликты до перехода в состояние Established.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O GateD NGC 2.0 не поддерживает детектирование конфликтов в состоянии Established. Этот дополнительный атрибут всегда имеет значение FALSE.

3.32. Определение FSM, параграф 8.2.1 [RFC4271]

3.32.176. FSM

Функции/описание: Раздельная машина FSM для каждого указанного в конфигурации партнера.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.32.177. TCP Port 179

Функции/описание: Реализация BGP должна подключаться и прослушивать порт TCP 179 в дополнение к попыткам организации соединения с партнерами.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.32.178. Входящие соединения

Функции/описание: машина состояний должна поддерживать множество экземпляров.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.33. FSM и детектирование конфликтов, параграф 8.2.1.2 [RFC4271]

3.33.179. Конфликт соединений

Функции/описание: Машину FSM для закрываемого соединения следует отключать.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.34. Номера событий FSM, параграф 8.2.1.4 [RFC4271]

3.34.180. Номера событий

Функции/описание: Используются для обеспечения данных сетевого управления.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y Недоступны для оператора.

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: N Будущие версии GateD NGC могут поддерживать номера событий.

3.35. Машина конечных состояний, параграф 8.2.2 [RFC4271]

3.35.181. ConnectRetryTimer

Функции/описание: Значение должно быть достаточно большим, чтобы позволить инициализацию TCP.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.35.182. Отслеживание двойных соединений

Функции/описание: В ответ на успешную организацию соединения TCP [Событие 16 или 17] второе соединение нужно отслеживать до тех пор, пока через него не будет передано сообщение OPEN.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.36. Обработка сообщений UPDATE, глава 9 [RFC4271]

3.36.183. Обработка сообщений UPDATE

Функции/описание: Ваша реализация обрабатывает сообщения UPDATE совместимым с требованиями данной главы способом?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.36.184. Отзываемые маршруты

Функции/описание: Все ранее анонсированные маршруты, которые содержатся в данном поле, нужно удалять из базы Adj-RIB-In.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.36.185. Отзываемые маршруты

Функции/описание: Узлу BGP нужно запустить процесс выбора маршрутов (Decision Process), поскольку анонсированный ранее маршрут больше не может использоваться.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.36.186. Неявный отзыв маршрутов

Функции/описание: Если сообщение UPDATE содержит доступный маршрут и значение NLRI для нового маршрута идентично значению для обного из маршрутов Adj-RIB-In, новый маршрут нужно установить взамен прежнего.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.36.187. Другие доступные маршруты

Функции/описание: если сообщение UPDATE содержит доступный маршрут и значение NLRI нового маршрута идентично значению одного из маршрутов в Adj-RIB-In, новый маршрут нужно включить в базу Adj-RIB-In.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.36.188. Обновление Adj-RIB-In

Функции/описание: При обновлении узлом BGP базы Adj-RIB-In ему нужно запустить процесс выбора маршрутов (Decision Process).

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.37. Процесс выбора маршрутов, параграф 9.1 [RFC4271]

3.37.189. Процесс выбора маршрутов⁶

Функции/описание: Совместима ли ваша реализация с требованиями этого параграфа?

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.37.190. Уровень предпочтения

Функции/описание: Не следует использовать в качестве входных данных перечисленные здесь: существование других маршрутов, отсутствие других маршрутов или атрибуты пути других маршрутов.

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.38. Фаза 1: Расчет уровня предпочтения, параграф 9.1.1 [RFC4271]

3.38.191. Неподходящий уровень предпочтения

Функции/описание: Маршрут может не передаваться на следующий этап выбора.

RFC2119: MAY NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.38.192. Неподходящий уровень предпочтения

Функции/описание: Используется как значение LOCAL_PREF при дальнейшем анонсировании в IBGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.39. Фаза 2: Выбор маршрута, параграф 9.1.2 [RFC4271]

3.39.193. Непреобразуемое значение NEXT_HOP

Функции/описание: Если атрибут NEXT_HOP маршрута BGP указывает непреобразуемый адрес или этот адрес не будет преобразовываться после установки маршрута, такой маршрут BGP должен исключаться из обработки

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.39.194. Маршруты, установленные в LOC-RIB

Функции/описание: Маршрут из Adj-RIBs-In, идентифицированный как лучший (см. параграф 9.1.2), устанавливается в Loc-RIB, заменяя собой любой имеющийся в Loc-RIB маршрут к тем же адресатам.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.39.195. Адрес непосредственно следующего интервала (Immediate Next-Hop)

Функции/описание: Должен определяться из атрибута NEXT_HOP выбранного маршрута (см. параграф 5.1.3)

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.39.196. Фаза 2: Выбор маршрута

Функции/описание: Выполняется еще раз, если изменяется непосредственно следующий интервал или стоимость IGP для пути к NEXT_HOP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.39.197. Адрес непосредственно следующего интервала (Immediate Next-Hop)

Функции/описание: Используется для пересылки пакетов.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.39.198. Непреобразуемые маршруты

Функции/описание: Удаляются из Loc-RIB и таблицы маршрутизации.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.39.199. Непреобразуемые маршруты

Функции/описание: Сохраняется в соответствующей базе Adj-RIBs-In

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.40. Условия преобразуемости маршрутов, параграф 9.1.2.1 [RFC4271]

3.40.200. Непреобразуемые маршруты

Функции/описание: Исключаются из Фазы 2 при выборе маршрутов.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.40.201. Множество подходящих маршрутов

Функции/описание: Следует рассматривать только маршрут с наибольшей длиной соответствия.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.40.202. Взаимная рекурсия

Функции/описание: Если маршрут не проходит проверку на преобразуемость вследствие взаимной рекурсии, сообщение об ошибке следует записать в системный журнал.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: O Мы проверяем запрет взаимной рекурсии, поэтому такая ситуация невозможна.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.41. Отбрасывание лишнего (Фаза 2), параграф 9.1.2.2 [RFC4271]

3.41.203. Критерии отбрасывания лишнего (Tie-Breaking)

Функции/описание: Применяются в указанном порядке.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.41.204. Используемый алгоритм

Функции/описание: Реализация BGP может использовать любой алгоритм, который дает такие же результаты, как указано в спецификации.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.41.205. Удаление MULTI_EXIT_DISC

Функции/описание: Если удаление происходит до реанонсирования маршрута в IBGP, сравнение может выполняться для полученного от EBGP атрибута MULTI_EXIT_DISC.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.41.206. Удаление MULTI_EXIT_DISC

Функции/описание: Если выполняется дополнительное сравнение MULTI_EXIT_DISC, при этом должны рассматриваться только маршруты, полученные от EBGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.41.207. Сравнение MULTI_EXIT_DISC

Функции/описание: Выполняется для маршрутов, полученных от IBGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.42. Фаза 3: Распространение маршрутов, параграф 9.1.3 [RFC4271]

3.42.208. Правила обработки маршрутов из Loc-RIB, передаваемых в Adj-RIBs-Out

Функции/описание: Маршруты из Loc-RIB могут не добавляться в ту или иную базу Adj-RIB-Out.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.42.209. Установка маршрута в Adj-Rib-Out

Функции/описание: Маршрут не следует устанавливать в Adj-Rib-Out, если для адресатов и NEXT_HOP этого маршрута а таблице маршрутизации нет соответствующей записи.

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.42.210. Отзываемые маршруты

Функции/описание: Если маршрут из базы Loc-RIB не включается в ту или иную базу Adj-RIB-Out, ранее анонсированный маршрут этой базы Adj-RIB-Out должен быть отозван с помощью сообщения UPDATE (см. параграф 9.2).

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.43. Перекрывающиеся маршруты, параграф 9.1.4 [RFC4271]

3.43.211. Перекрывающиеся маршруты

Функции/описание: Рассматриваются оба маршрута с учетом заданной политики восприятия маршрутов.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.43.212. Приемлемые перекрывающиеся маршруты

Функции/описание: Процесс выбора (Decision Process) должен установить в Loc-RIB оба маршрута или …

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.43.213. Приемлемые перекрывающиеся маршруты

Функции/описание: … объединить их и установить в Loc-RIB агрегированный маршрут, что обеспечивается наличием в обоих маршрутах одинакового значения атрибута NEXT_HOP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N Мы устанавливаем оба маршрута в Local RIB.

Laurel Y/N/O/комментарии: N Нет автоматического агрегирования.

NextHop Y/N/O/комментарии: N Нет автоматического агрегирования.

3.43.214. Агрегирование

Функции/описание: В AS_SET включаются все AS, использованные для формирования агрегированного маршрута или к маршруту добавляется атрибут ATOMIC_AGGREGATE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.43.215. Деагрегирование

Функции/описание: Маршруты не нужно деагрегировать.

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.43.216. Маршруты с атрибутом ATOMIC_AGGREGATE

Функции/описание: Недопустимо деагрегировать.

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.44. Процесс передачи обновлений, параграф 9.2 [RFC4271]

3.44.217. Сообщения UPDATE, полученные от внутреннего партнера

Функции/описание: Маршрутная информация не передается другим внутренним партнерам, если данный узел не работает в режиме BGP Route Reflector [RFC2796]

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.44.218. Нет маршрута для замены

Функции/описание: Все недавно анонсированные и объявленные недоступными маршруты, для которых нет замены, нужно анонсировать партнерам с помощью сообщений UPDATE

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.44.219. Ранее анонсированные маршруты

Функции/описание: Узлу BGP не нужно анонсировать данный доступный маршрут BGP, если этот узел будет генерировать сообщение UPDATE, содержащее ранее уже анонсированный маршрут BGP.

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.44.220. Недоступные маршруты

Функции/описание: Удаляются из Loc-RIB

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.44.221. Изменения в доступности адресатов

Функции/описание: Изменения в доступности адресатов своей автономной системы нужно также анонсировать с помощью сообщений UPDATE.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.44.222. Один маршрут не помещается в сообщение UPDATE

Функции/описание: Маршрут не анонсируется.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.44.223. Один маршрут не помещается в сообщение UPDATE

Функции/описание: Записать информацию об ошибке в журнальный файл.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.45. Частота анонсирования маршрутов, параграф 9.2.1.1 [RFC4271]

3.45.224. MinRouteAdvertisementIntervalTimer

Функции/описание: Минимальный интервал между двумя сообщениями UPDATE с анонсами доступных маршрутов и/или отзывом недоступных для некого общего набора адресатов, передаваемые узлом BGP своему партнеру.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.45.225. Быстрое схождение

Функции/описание: Значение MinRouteAdvertisementIntervalTimer для внутренних партнеров следует делать более коротким, нежели MinRouteAdvertisementIntervalTimer для внешних партнеров.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: O Настраивается независимо для каждого партнера.

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: N Одинаковое значение для ebgp и ibgp.

NextHop Y/N/O/комментарии: Y Конфигурационная опция независимой установки времени для каждого партнера.

3.45.226. Быстрое схождение

Функции/описание: Процедуру, описанную в этом параграфе, не нужно применять для внутренних партнеров.

RFC2119: SHOULD NOT (не нужно)

Alcatel Y/N/O/комментарии: O Оператор может выбрать этот режим в параметрах конфигурации.

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: Y Отключено по умолчанию для всех партнеров BGP.

3.45.227. MinRouteAdvertisementIntervalTimer

Функции/описание: Последний выбранный маршрут нужно анонсировать в конце интервала MinRouteAdvertisementIntervalTimer

RFC2119: SHALL (нужно)

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46. Агрегирование маршрутной информации, параграф 9.2.2.2 [RFC4271]

3.46.228. MULTI_EXIT_DISC

Функции/описание: Маршруты с различающимися атрибутами MULTI_EXIT_DISC не следует агрегировать.

RFC2119: SHALL NOT (не следует)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: Y

3.46.229. AS_SET как первый элемент

Функции/описание: Если агрегированный маршрут имеет AS_SET в качестве первого элемента атрибута AS_PATH, маршрутизатору, от которого исходит маршрут, не следует анонсировать атрибут MULTI_EXIT_DISC с этим маршрутом.

RFC2119: SHOULD NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.230. NEXT_HOP

Функции/описание: При агрегировании маршрутов с разными атрибутами NEXT_HOP в агрегированном маршруте атрибуту NEXT_HOP нужно сопоставлять интерфейс узла BGP, выполняющего агрегирование.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.231. ORIGIN INCOMPLETE

Функции/описание: Если хотя бы один из агрегируемых маршрутов имеет ORIGIN = INCOMPLETE, для объединенного маршрута также должно устанавливаться ORIGIN = INCOMPLETE.

RFC2119: MUST (необходимо)

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.232. ORIGIN EGP

Функции/описание: Используется, если хотя бы один из объединяемых маршрутов имеет значение ORIGIN = EGP.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.233. Агрегируемые маршруты имеют разные атрибуты AS_PATH

Функции/описание: Если агрегируемые маршруты имеют разные атрибуты AS_PATH, агрегированному атрибуту AS_PATH нужно удовлетворять каждому из перечисленных ниже требований …

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.234. Агрегируемые маршруты имеют разные атрибуты AS_PATH

Функции/описание: Всем парам типа AS_SEQUENCE агрегированного AS_PATH нужно присутствовать в каждом атрибуте AS_PATH исходного набора агрегируемых маршрутов.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.235. Агрегируемые маршруты имеют разные атрибуты AS_PATH

Функции/описание: Всем парам типа AS_SET агрегированного AS_PATH нужно присутствовать хотя бы в одном атрибуте AS_PATH исходного набора.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.236. Агрегируемые маршруты имеют разные атрибуты AS_PATH

Функции/описание: Для любой пары X типа AS_SEQUENCE в агрегированном AS_PATH, которая предшествует паре Y агрегированного AS_PATH, X предшествует Y в каждом атрибуте AS_PATH исходного набора, который содержит Y, независимо от типа Y.

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.237. Агрегируемые маршруты имеют разные атрибуты AS_PATH

Функции/описание: Ни одной паре типа AS_SET не следует появляться в агрегированном AS_PATH более одного раза.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.238. Агрегируемые маршруты имеют разные атрибуты AS_PATH

Функции/описание: Множество пар типа AS_SEQUENCE с одинаковыми значениями может присутствовать в агрегированном AS_PATH только по-соседству с другой однотипной парой с совпадающим значение.

RFC2119: N/A

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: Y

3.46.239. Алгоритм агрегирования AS_PATH

Функции/описание: Способность выполнять (как минимум) алгоритм, описанный в параграфе 9.2.2.2.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N Мы не делаем слияния.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.240. ATOMIC_AGGREGATE

Функции/описание: Если хотя бы один из объединяемых маршрутов имеет атрибут ATOMIC_AGGREGATE, в объединенный маршрут также нужно включать этот атрибут.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.241. AGGREGATOR

Функции/описание: Атрибут из агрегируемых маршрутов недопустимо включать в агрегированный маршрут.

RFC2119: MUST NOT (недопустимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.46.242. AGGREGATOR

Функции/описание: Добавляется новый атрибут к агрегированному маршруту (см. параграф 5.1.7)

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.47. Критерии выбора маршрутов, параграф 9.3 [RFC4271]

3.47.243. Нестабильные маршруты

Функции/описание: Избегать использования таких маршрутов.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.47.244. Изменения маршрутов

Функции/описание: Не следует принимать быстрых спонтанных решений об изменении при выборе маршрутов.

RFC2119: SHOULD NOT (не следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.48. Генерация маршрутов BGP, параграф 9.4 [RFC4271]

3.48.245. Маршруты из других источников (не BGP)

Функции/описание: Распространяются другим узлам BGP в локальной AS как часть процесса обновления (см. параграф 9.2).

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.48.246. Маршруты из других источников (не BGP)

Функции/описание: Распространение маршрутов управляется параметрами конфигурации.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.49. Таймеры BGP, глава 10 [RFC4271]

3.49.247. Необязательные таймеры

Функции/описание: Могут поддерживаться два необязательных таймера – DelayOpenTimer и IdleHoldTimer

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: O Мы поддерживаем только таймер DelayOpenTimer.

Laurel Y/N/O/комментарии: Y Поддерживается только таймер IdleHoldTimer.

NextHop Y/N/O/комментарии: Y

3.49.248. Hold Time

Функции/описание: Независимо настраивается для каждого партнера.

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.49.249. Таймеры

Функции/описание: Можно настраивать значения других таймеров.

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.49.250. Флуктуации (Jitter)

Функции/описание: Применяются к таймерам, связанным с MinASOriginationInterval, KeepAlive, MinRouteAdvertisementInterval и ConnectRetry

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: O Мы применяем флуктуации только для ConnectRetry.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.49.251. Флуктуации (Jitter)

Функции/описание: Используются одинаковые флуктуации для каждого из перечисленных параметров, независимо от адресата, которому будут передаваться одновления (т. е., флуктуации не задаются независимо для каждого партнера).

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y Мы применяем флуктуации только для ConnectRetry.

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.49.252. Флуктуации по умолчанию

Функции/описание: Определяются путем умножения базового значения таймера на случайные значения, равномерно распределенные в диапазоне от 0.75 до 1.0.

RFC2119: SHALL (нужно)

Alcatel Y/N/O/комментарии: Y Диапазон от 0.9 до 1.1.

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.49.253. Флуктуации по умолчанию

Функции/описание: Выбирается новое случайное значение при каждой установке таймера.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

3.49.254. Диапазон случайных значений флуктуаций

Функции/описание: Настраиваемый

RFC2119: MAY (возможно)

Alcatel Y/N/O/комментарии: N

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: N

3.50. Опции TCP, которые могут использоваться с BGP, Приложение E [RFC4271]

3.50.255. Поддержка TCP PUSH

Функции/описание: Каждое сообщение BGP следует передавать с установленным флагом PUSH.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O В зависимости от возможностей стека TCP. GateD 10, NGC может работать с различными вариантами стека протоколов.

3.50.256. Поддержка поля DSCP⁷

Функции/описание: Соединения TCP открываются с битами 0-2 поля DSCP, имеющими двоичное значение 110.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: O В зависимости от возможностей стека TCP. GateD 10, NGC может работать с различными вариантами стека протоколов.

3.51. Снижение числа переключений маршрутов, Приложение F.2 [RFC4271]

3.51.257. Предотвращение избыточных переключений маршрутов

Функции/описание: Узлу BGP, которому нужно отозвать адресата и передать обновление с более (или менее) специфичным маршрутом, следует объединять анонсы в одно сообщение UPDATE.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: N

3.52. Комплексное агрегирование AS_PATH, Приложение F.6 [RFC4271]

3.52.258. Повторяющиеся экземпляры в AS_PATH

Функции/описание: Все вхождения одного номера AS, кроме последнего (самый правый) следует удалить из агрегированного атрибута PATH.

RFC2119: SHOULD (следует)

Alcatel Y/N/O/комментарии: N Мы используем алгоритм 9.2.2.2

Cisco Y/N/O/комментарии: N

Laurel Y/N/O/комментарии: N

NextHop Y/N/O/комментарии: N

3.53. Вопросы безопасности [RFC4271]

3.53.259. Механизм аутентификации

Функции/описание: Реализация BGP должна поддерживать механизм аутентификации, описанный в RFC 2385 [RFC2385].

RFC2119: MUST (необходимо)

Alcatel Y/N/O/комментарии: Y

Cisco Y/N/O/комментарии: Y

Laurel Y/N/O/комментарии: Y

NextHop Y/N/O/комментарии: Y

4. Дополнительные сведения о реализациях BGP

Три разработчика ответили по телефону (в период с 20.05.2004 по 02.06.2004) и сообщили, что у них имеются реализации BGP, но они не ответили полностью на вопросы “анкеты”. Полученная от этих разработчиков информация представлена ниже.

4.1. Avici

Если у вас есть реализация BGP, но вы не отправили отчет о ней (ответы на 259 вопросов), не могли бы вы прислать мне ответы на следующие вопросы:

1) Продукция BGP

Разработчик (ваше имя): Curtis Villamizar [curtis@fictitious.org]

Компания: Avici

Название продукции: IPriori (TM)

Младшая версия: не возникает проблем интероперабельности при работе с любой версией.

В настоящее время реализованы версии 5.x и 6.0.x. Версия 6.1 и последующие будут тестироваться на предмет соответствия последней спецификации BGP [RFC4271].

2) С какими реализациями может совместно работать ваша?

Cisco: IOS 12.0(22)

Juniper: JUNOS (версия не указана)

3) Обеспечивает ли ваша реализация интероперабельность с:

1) Alcatel BGP (release) – не тестировалась

2) cisco BGP IOS 12.0(27)s — не тестировалась; тестировалась с IOS 12.0(22); BGP в этих версиях не различается.

3) laurel BGP (specify release) — не тестировалась

4) NextHop GateD — не тестировалась

4) Количество вопросов анкеты BGP послужило причиной того, что вы не отправили отчет о своей реализации BGP?

Да

4.2. Data Connection Ltd.

Если у вас есть реализация BGP, но вы не отправили отчет о ней (ответы на 259 вопросов), не могли бы вы прислать мне ответы на следующие вопросы:

1) Продукция BGP

Разработчик (ваше имя): Mike Dell

Компания: Data Connection Ltd.

Название продукции: DC-BGP

Версия: v1.1

Дата выпуска: апрель 2003

2) С какими реализациями может совместно работать ваша?

Cisco (12.0(26)S)

Alcatal (7770 0BX)

Agilent (Router Tester)

Ixia (1600T)

Netplane (Powercode)

Nortel (Shasta 5000 BSN)

Redback (SmartEdge 800)

Riverstone (RS8000)

Spirent (AX4000)

IP Infusion (ZebOs)

Nokia (IP400)

Juniper (M5)

3) Обеспечивает ли ваша реализация интероперабельность с:

1) Alcatel BGP (release) – Да

2) cisco BGP IOS 12.0(27)s – Неизвестно, но мы можем работать совместно с v12.0(26)s

3) laurel BGP (specify release) – Неизвестно

4) NextHop GateD – Да

4) Количество вопросов анкеты BGP послужило причиной того, что вы не отправили отчет о своей реализации BGP?

Да

4.3. Nokia

Если у вас есть реализация BGP, но вы не отправили отчет о ней (ответы на 259 вопросов), не могли бы вы прислать мне ответы на следующие вопросы:

1) Продукция BGP

Разработчик (ваше имя): Rahul Bahadur (rahul.bahadur@nokia.com)

Компания: Nokia

Название продукции: платформы IP Security

Версия: IPSO 3.8 Build031

Дата выпуска: 24 мая 2004

2) С какими реализациями может совместно работать ваша?

Cisco: IOS 12.3(1)

Extreme: Extremeware Version 6.1.7 (Build 9)

Foundry: SW Version 07.5.05iT53

Juniper: JUNOS 5.3R1.2

Nortel: BayRS 15.4.0.1

GNU Zebra: zebra-0.92a

3) Обеспечивает ли ваша реализация интероперабельность с:

1) Alcatel BGP (release) – не тестировалась

2) cisco BGP IOS 12.0(27)s – да

3) laurel BGP (specify release) – не тестировалась

4) NextHop GateD – не тестировалась

4) Количество вопросов анкеты BGP послужило причиной того, что вы не отправили отчет о своей реализации BGP?

Да – нехватка ресурсов для выполнения этой задачи.

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

В этом документе не рассматриваются какие-либо вопросы безопасности.

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

[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC1771] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

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

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC2796] Bates, T., Chandra, R., and E. Chen, «BGP Route Reflection — An Alternative to Full Mesh IBGP», RFC 2796, April 2000.

[RFC2918] Chen, E., «Route Refresh Capability for BGP-4», RFC 2918, September 2000.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, «Autonomous System Confederations for BGP», RFC 3065, February 2001.

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

Отклики Alcatel были представлены:

Contact Name: Devendra Raut

Contact EMail: Devendra.raut@Alcatel.com

Отклики Cisco Systems были представлены:

Contact Name: Himanshu Shah, Ruchi Kapoor

Contact EMail: hhshah@cisco.com, ruchi@cisco.com

Отклики Laurel были представлены:

Contact Name: Manish Vora

Contact EMail: vora@laurelnetworks.com

Отклики NextHop были представлены:

Contact Name: Susan Hares

Contact EMail: skh@nexthop.com

Additional Help: Matt Richardson, Shane Wright.

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

Susan Hares

NextHop Technologies

825 Victors Way, Suite 100

Ann Arbor, MI 48108

Phone: 734.222.1610

EMail: skh@nexthop.com

Alvaro Retana

Cisco Systems, Inc.

7025 Kit Creek Rd.

Research Triangle Park, NC 27709

Phone: 919 392 2061

EMail: aretana@cisco.com

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

Network Working Group                                     P. Hoffman
Request for Comments: 4308                            VPN Consortium
Category: Standards Track                              December 2005

Шифронаборы для IPsec

Cryptographic Suites for IPsec

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Аннотация

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

1. Введение

Этот документ используется совместно с IPsec [RFC2401³] и двумя протоколами обмена ключами IKE [RFC2409] и IKEv2 [IKEv2]. Подобно многим другим протоколам защиты, IPsec, IKE и IKEv2 позволяют пользователям выбрать используемый криптографический алгоритм в соответствии со своими потребностями.

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

Хотя перечисленные здесь наборы UI не являются обязательными для реализации, этот документ внесен как предложенный стандарт, поскольку разработчики называют конкретные наборы перечисленными здесь именами для подтверждения соответствия наборам, перечисленным в этом документе. Эти наборы следует рассматривать не как расширения IPsec, IKE и IKEv2, а как административные методы описания набора конфигураций.

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

2. Наборы UI

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

Отметим, что эти наборы UI представляют собой лишь значения для некоторых опций IPsec. Использование наборов UI не вносит каких-либо изменений в протоколы IPsec, IKE и IKEv2. В частности, должна использоваться подструктура преобразования в IKE и IKEv2 для задания значения каждой указанной опции независимо от использования наборов UI.

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

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

Отметим, что перечисленные здесь наборы предназначены для использования IPsec в виртуальных частных сетях (VPN⁵). Для иных приложений IPsec могут быть определены свои наборы с другими именами.

Дополнительные наборы могут определяться в RFC. Имена, используемые для идентификации наборов UI, регистрируются в IANA.

2.1. Набор VPN-A

Этот набор соответствует наиболее распространенным на момент подготовки документа системам VPN, использующим IKEv1.

IPsec:

Протокол ESP⁶ [RFC2406]

Шифрование ESP TripleDES в режиме CBC [RFC2451]

Целостность ESP HMAC-SHA1-96 [RFC2404]

IKE и IKEv2:

Шифрование TripleDES в режиме CBC [RFC2451]

Псевдослучайная функция HMAC-SHA1 [RFC2104]

Целостность HMAC-SHA1-96 [RFC2404]

Группа Diffie-Hellman 1024-bit Modular Exponential (MODP) [RFC2409]

Функции Rekeying of Phase 2 (для IKE) или CREATE_CHILD_SA (для IKEv2) должны поддерживаться обеими частями этого набора. Инициатор обмена может включать новый ключ Diffie-Hellman. Если ключ включен, он должен представлять собой 1024-битовую группу MODP. Если инициатор обмена включает ключ Diffie-Hellman, отвечающая сторона должна включить ключ Diffie-Hellman и этот ключ должен быть 1024-битовой группой MODP.

2.2. Набор VPN-B

Этот набор соответствует системам VPN, которые будут наиболее массово применяться в ближайшие несколько лет после публикации этого документа.

IPsec:

Протокол ESP [RFC2406]

Шифрование ESP AES со 128-битовыми ключами в режиме CBC [AES-CBC]

Целостность ESP AES-XCBC-MAC-96 [AES-XCBC-MAC]

IKE и IKEv2:

Шифрование AES со 128-битовыми ключами в режиме CBC [AES-CBC]

Псевдослучайная функция AES-XCBC-PRF-128 [AES-XCBC-PRF-128]

Целостность AES-XCBC-MAC-96 [AES-XCBC-MAC]

Группа Diffie-Hellman 2048-bit MODP [RFC3526]

Функции Rekeying of Phase 2 (для IKE) или CREATE_CHILD_SA (для IKEv2) должны поддерживаться обеими частями этого набора. Инициатор обмена может включать новый ключ Diffie-Hellman. Если ключ включен, он должен представлять собой 2048-битовую группу MODP. Если инициатор обмена включает ключ Diffie-Hellman, отвечающая сторона должна включить ключ Diffie-Hellman и этот ключ должен быть 2048-битовой группой MODP.

2.3. Время жизни для IKEv1

IKEv1 имеет два параметра защиты, которые отсутствуют в IKEv2, а именно — время жизни ассоциаций SA⁷ для фазы 1 и фазы 2. Системы, использующие IKEv1 с наборами VPN-A или VPN-B, должны задавать для времени жизни SA значение 86400 секунд (1 сутки) для фазы 1 и 28800 секунд (8 часов ) для фазы 2.

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

Большая часть текста этого документа и идеи заимствованы из ранних версий документа IKEv2 под редакцией Charlie Kaufman. Остальной текст и идеи были включены другими членами рабочей группы IPsec.

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

Этот документ наследует все связанные с безопасностью аспекты документов IPsec, IKE и IKEv2.

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

5. Взаимодействие с IANA

Агентство IANA создало и поддерживает реестр «Cryptographic Suites for IKEv1, IKEv2, and IPsec». Этот реестр состоит из текстовых строк и номеров RFC, в которых описаны соответствующие преобразования. Новые записи добавляются в реестр лишь после публикации RFC и одобрения экспертов, назначенных IESG.

Начальными значениями реестра являются:

Идентификатор  Документ
VPN-A          RFC 4308
VPN-B          RFC 4308

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

[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003.

[AES-XCBC-MAC] Frankel, S. and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, September 2003.

[AES-XCBC-PRF-128] Hoffman, P., «The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 3664, January 2004.

[IKEv2] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[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.

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

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406¹⁰, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409¹¹, November 1998.

[RFC2451] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[RFC3526] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

Адрес автора

Paul Hoffman

VPN Consortium

127 Segre Place

Santa Cruz, CA 95060

USA

EMail: paul.hoffman@vpnc.org

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2005).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

Network Working Group                                    J. Schiller
Request for Comments: 4307     Massachusetts Institute of Technology
Category: Standards Track                              December 2005

Криптографические алгоритмы для использования с IKEv2

Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Аннотация

Группа протоколов IPsec использует различные криптографические алгоритмы для обеспечения защиты информации. Протоколы IKE¹ (RFC 2409) и IKEv2 обеспечивают механизм согласования алгоритма, который должен использоваться для данного соединения (association). Однако для обеспечения взаимодействия между независимыми реализациями необходимо задать набор обязательных для реализации алгоритмов, чтобы по крайней мере один алгоритм поддерживался всеми реализациями. В этом документе определяется набор алгоритмов, являющихся обязательными для реализации, как часть IKEv2, а также алгоритмы, которые следует реализовать потому, что они могут стать обязательными в будущем.

1. Введение

Протокол IKE обеспечивает согласование криптографических алгоритмов между конечными точками криптографической ассоциации². Различные реализации IPsec и IKE могут поддерживать разные алгоритмы. Однако IETF желает обеспечить между всеми реализациями тот или иной вариант взаимодействия. В частности, требуется, чтобы протокол IKE определял набор обязательных для реализации алгоритмов, поскольку сам протокол IKE использует такие алгоритмы как часть процесса согласования. По этой причине некий набор алгоритмов требуется задать в качестве обязательного для реализации в IKE.

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

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

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

2. Уровни требований

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

В этом документе определены также дополнительные уровни требований:

SHOULD+ Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD+, в будущем перейдет в число обязательных (MUST).

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

MUST- Этот термин обозначает то же, что и MUST. Однако мы предполагаем, что в какой-то момент этот алгоритм перестанет быть обязательным и может перейти на уровень SHOULD или SHOULD-.

3. Выбор алгоритма

3.1. Выбор алгоритма IKEv2

3.1.1. Алгоритмы шифрования данных

Шифрование данных IKEv2 требует как алгоритма обеспечения конфиденциальности, так и алгоритма обеспечения целостности. Для обеспечения конфиденциальности реализация должна (MUST-) поддерживать 3DES-CBC и следует (SHOULD+0 также поддерживать AES-128-CBC. Для обеспечения целостности должен поддерживаться алгоритм HMAC-SHA1.

3.1.2. Группы Diffie-Hellman

Существует несколько групп MODP³, определенных для использования в IKEv2. Эти группы определены как в базовом документе [IKEv2], так и в документе, посвященном расширениям MODP. Группы идентифицируются номерами. Все группы, не указанные здесь, рассматриваются как возможные для реализации.

3.1.3. Алгоритмы преобразования IKEv2 типа 1

IKEv2 определяет несколько алгоритмов для Transfer Type 1 (шифрование). Ниже эти алгоритмы перечислены с указанием статуса для каждого.

3.1.4. Алгоритмы преобразования IKEv2 типа 2

Алгоритмы Transfer Type 2 являются псевдослучайными функциями для генерации случайных значений.

3.1.5. Алгоритмы преобразования IKEv2 типа 3

Алгоритмы Transfer Type 3 служат для обеспечения целостности и защищают данные от подделки.

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

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

Этот документ посвящен выбору криптографических алгоритмов для использования с IKEv2, а именно — выбору алгоритмов, обязательных для реализации. Алгоритмы, для которых указано MUST (необходимо) и SHOULD (следует), приняты к считаются безопасными в настоящее время и криптографические исследования позволяют надеяться на то, что они останутся безопасными в обозримом будущем. Однако это предположение может не оправдаться. Следовательно, в будущем могут появляться пересмотренные варианты этого документа, отражающие накопленный опыт.

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

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

[IKEv2] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

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

[RFC3526] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

[RFC2451] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[RFC2410] Glenn, R. and S. Kent, «The NULL Encryption Algorithm and Its Use With IPsec», RFC 2410, November 1998.

[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003.

[AES-CTR] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, January 2004.

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

[AESPRF] Hoffman, P., «The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 3664, January 2004.

[RFC2403] Madson, C. and R. Glenn, «The Use of HMAC-MD5-96 within ESP and AH», RFC 2403, November 1998.

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998.

[AES-MAC] Frankel, S. and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, September 2003.

Адрес автора

Jeffrey I. Schiller

Massachusetts Institute of Technology

Room W92-190

77 Massachusetts Avenue

Cambridge, MA 02139-4307

USA

Phone: +1 (617) 253-0161

EMail: jis@mit.edu

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2005).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

Network Working Group                                    C. Kaufman, Ed.
Request for Comments: 4306                                     Microsoft
Obsoletes: 2407, 2408, 2409                                December 2005
Category: Standards Track

Протокол обмена ключами в Internet (IKEv2)

Internet Key Exchange (IKEv2) Protocol

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Аннотация

В этом документе описана версия 2 протокола обмена ключами в Internet (IKE¹). Протокол IKE является частью IPsec и служит для обоюдной аутентификации партнёров, организации и поддержки защищённых связей (SA²).

Эта версия спецификации IKE объединяет содержимое нескольких отдельных документов прежних версий, включая ISAKMP³ (RFC 2408), IKE (RFC 2409), DOI⁴ (RFC 2407), спецификация работы через NAT⁵, унаследованную аутентификацию и получение удалённого адреса.

Версия 2 протокола IKE не совместима с версией 1, но имеет достаточно много общего в формате заголовков и обе версии однозначно могут работать через один и тот же порт UDP.

1. Введение

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

Организация этого состояния вручную не обеспечивает приемлемого масштабирования. Следовательно, требуется протокол для динамической организации этого состояния. В данном документе описан такой протокол — протокол обмена ключами Internet (IKE). Данное описание относится к версии 2 протокола IKE. Первая версия протокола IKE была определена в RFC 2407, 2408 и 2409 [Pip98, MSST98, HC98]. Данный документ заменяет три упомянутых RFC.

Определения основополагающих терминов, используемых в документе (таких, как защищённая связь или SA) можно найти в [RFC4301].

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

Термин Expert Review (экспертиза) интерпретируется в соответствии с определением [RFC2434].

IKE выполняет взаимную аутентификацию партнёров и организует защищённую связь IKE SA, включающую разделяемый секретный ключ, который может эффективно использоваться при организации SA для протоколов ESP⁷ [RFC4303] и/или AH⁸ [RFC4302], и набор криптографических алгоритмов, которые будут использоваться SA для защиты передаваемого трафика. В этом документе термины «набор» (suite) или «шифронабор» (cryptographic suite) обозначают все множество алгоритмов, используемых для защиты SA. Инициатор предлагает один или несколько наборов, перечисляя поддерживаемые им алгоритмы, которые могут быть объединены в наборы или использоваться «вперемешку». IKE может также согласовывать использование компрессии IP (IPComp⁹) [IPCOMP] совместно в ESP и/или AH SA. Для IKE SA будем использовать обозначение IKE_SA. SA для ESP и/или AH, проходящие через IKE_SA, будем обозначать CHILD_SA.

Весь обмен информацией IKE организован в форме парных сообщений запрос — отклик. Для пар используется термин «обмен» (exchange). Первые сообщения при организации IKE_SA включают обмен IKE_SA_INIT и IKE_AUTH, а за ними следуют обмены CREATE_CHILD_SA или INFORMATIONAL. В общем случае для организации IKE_SA и первой связи CHILD_SA используется один обмен IKE_SA_INIT и один обмен IKE_AUTH (всего 4 сообщения). В исключительных случаях оба обмена могут использоваться неоднократно. В любом случае все обмены IKE_SA_INIT должны быть завершены до начала обмена любого другого типа, после этого должны быть завершены все обмены IKE_AUTH и далее могут выполняться в любом порядке обмены CREATE_CHILD_SA и INFORMATIONAL. В некоторых сценариях между конечными точками IPsec требуется только один обмен CHILD_SA и, следовательно, не возникает дополнительных обменов. Последующие обмены могут использоваться для организации дополнительных CHILD_SA между теми же аутентифицированными парами конечных точек и для выполнения вспомогательных функций.

Поток сообщений IKE всегда состоит из запросов, за которыми следует соответствующий отклик. Ответственность за обеспечение надёжности возлагается на запрашивающую сторону. Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или прервать попытку соединения).

Первый запрос/отклик в сеансе IKE (IKE_SA_INIT) согласует параметры защиты для IKE_SA, передаёт специальные сигналы nonce и значения Diffie-Hellman.

Вторая пара запрос/отклик (IKE_AUTH) передаёт аутентификацию, обеспечивает информацию о секретах аутентифицированных сторон и организует защищённую связь для первой (зачастую, единственной) AH или ESP CHILD_SA.

Последующие обмены относятся к типу CREATE_CHILD_SA (создание CHILD_SA) и INFORMATIONAL (удаление SA, сообщения об ошибках и другие служебные функции). Каждый запрос требует отклика. Запросы типа INFORMATIONAL, не содержащие информации (кроме пустого поля Encrypted payload, требуемого синтаксисом) обычно используются для проверки сохранности соединения. Последующие обмены не могут осуществляться, пока не будут завершены начальные обмены. Далее в описании предполагается отсутствие ошибок. Изменения потока, связанные с ошибками, рассмотрены в параграфе 2.21.

1.1. Сценарии использования

Предполагается, что IKE будет использоваться при согласовании SA для протоколов ESP и/или AH SA во множестве различных сценариев с отличающимися требованиями.

1.1.1. Туннель между защитными шлюзами

             +-+-+-+-+-+            +-+-+-+-+-+
             !Конечная ! Туннель    !Конечная !
Защищённая   !точка    ! IPsec      !точка    !     Защищённая
подсеть  <-->!туннеля  !<---------->!туннеля  !<--> подсеть
             !         !            !         !
             +-+-+-+-+-+            +-+-+-+-+-+

Рисунок 1. Туннель между защитными шлюзами.

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

1.1.2. Туннель между конечными точками

+-+-+-+-+-+-+                                          +-+-+-+-+-+-+
!           !            Защищённая связь (SA)         !           !
!Защищённая !в туннельном или транспортном режиме IPsec!Защищённая !
!   точка   !<---------------------------------------->!   точка   !
!           !                                          !           !
+-+-+-+-+-+-+                                          +-+-+-+-+-+-+

Рисунок 2. Туннель между конечными точкам.

В этом сценарии обе конечные точки соединения IP реализуют IPsec в соответствии с требованиями для хостов в [RFC4301]. Обычно используется транспортный режим без внутренних заголовков IP. Если внутренний заголовок используется, адрес IP в нем будет совпадать с адресом во внешнем заголовке. Для защиты с помощью данной SA согласуется одна пара адресов. Конечные точки могут реализовать средства контроля доступа на прикладных уровнях на основе IPsec-аутентификации участников соединения. Этот сценарий обеспечивает сквозную защиту, которая является одним из принципов работы Internet с момента разработки [RFC1958], [RFC2775] и метода ограничения унаследованных проблем, связанных со сложностью сетей, которые отмечены в [RFC3439]. Хотя этот сценарий не может полноценно применяться в Internet на базе IPv4, он может успешно использоваться внутри сетей intranet на базе IKEv1. Более широкому распространению этого сценария будет способствовать переход на IPv6 и адаптация IKEv2.

В таком сценарии одна или обе конечных точки могут находиться за системой трансляции сетевых адресов (NAT). В этом этом случае туннелируемые пакеты будут инкапсулироваться в UDP так, что номера портов в заголовках UDP можно будет использовать для аутентификации отдельных конечных точек, расположенных за NAT (см. параграф 2.23).

1.1.3. Туннель между конечной точкой и защитным шлюзом

+-+-+-+-+-+-+                          +-+-+-+-+-+
!           !        Туннель           !Конечная !     Защищённая
!Защищённая !         IPsec            !точка    !     подсеть
!точка      !<------------------------>!туннеля  !<--- и/или
!           !                          !         !     Internet
+-+-+-+-+-+-+                          +-+-+-+-+-+

Рисунок 3. Туннель между конечной точкой и защитным шлюзом.

В этом сценарии защищённая конечная точка (обычно портативный компьютер) подключается к корпоративной сети с использованием защищённого туннеля IPsec. Туннель может использоваться только для доступа к информации, хранящейся в корпоративной сети, или служить для передачи всего трафика портативного компьютера через офисную сеть для обеспечения возможности использования корпоративного межсетевого экрана, защищающего компьютер от атак из сети Internet. В любом случае защищённой точке будет нужен IP-связанный с защитным шлюзом, чтобы адресованные этой точке пакеты попадали на защитный шлюз и передавались им через туннель на защищённую точку. Этот адрес может выделяться защитным шлюзом статически или динамически. Во втором случае IKEv2 включает механизм, с помощью которого инициатор соединения запрашивает адрес IP, принадлежащий шлюзу, для использования в течение срока действия SA.

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

В этом сценарии защищённая конечная точка может находиться за системой трансляции адресов (NAT). При этом адрес, который будет видеть защитный шлюз, отличается от IP-адреса защищённой конечной точки и пакеты будут инкапсулироваться в дейтаграммы UDP для обеспечения корректной маршрутизации.

1.1.4. Другие сценарии

Возможны и другие сценарии, представляющие собой комбинации перечисленных выше вариантов. Один примечательный вариант объединяет в сете аспекты 1.1.1 и 1.1.3. Подсеть может организовать весь доступ наружу через удалённый защитный шлюз, используя туннель IPsec и тогда внешние сети (Internet) будут маршрутизировать пакеты для подсети защитному шлюзу. Например, некая домашняя сеть может виртуально представляться в сети Internet статическими адресами IP, несмотря на то, что эта сеть подключена через ISP, который выделяет один динамический адрес пользовательскому защитному шлюзу (видимый в Internet статический адрес IP и трансляция IPsec обеспечивается третьей стороной, расположенной в другом месте).

1.2. Начальные обмены

Коммуникации с использованием IKE всегда начинаются с обменов IKE_SA_INIT и IKE_AUTH (в IKEv1 — Фаза 1). Эти начальные обмены включают четыре сообщения, хотя в некоторых сценариях это число может расти. Все коммуникации с использованием IKE состоят из пар «запрос-отклик». Сначала будет описываться базовый обмен, а затем — возможные варианты. Первая пара сообщений (IKE_SA_INIT) согласует криптографические алгоритмы, осуществляет обмен сигналами nonce и обмен Diffie-Hellman [DH].

Вторая пара сообщений (IKE_AUTH) аутентифицирует предыдущие сообщения, обеспечивает обмен аутентификационной информацией и сертификатами, а также создаёт первую CHILD_SA. Компоненты этих сообщений шифруются и целостность их защищается с использованием ключей, организованных при обмене IKE_SA_INIT, поэтому аутентификационные данные недоступны для подслушивания, а все поля сообщений аутентифицируются.

На врезке справа приведён список обозначений и краткое описание данных, содержащихся в сообщениях.

Содержимое данных в сообщениях подробно рассматривается в разделе 3. Данные, которые являются необязательными, указываются в квадратных скобках — [CERTREQ] показывает возможность включения запроса сертификата.

Начальные обмены имеют вид:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SAi1, KEi, Ni   -->

HDR содержит списки параметров защиты (SPI¹⁰), номера версий и различные флаги. SAi1 указывает поддерживаемые инициатором криптографические алгоритмы для IKE_SA. В KE передаются значения Diffie-Hellman от инициатора. Ni задаёт nonce от инициатора.

                            <--    HDR, SAr1, KEr, Nr, [CERTREQ]

Отвечающая сторона выбирает криптографический набор из числа предложенных инициатором и указывает свой выбор в SAr1, завершает обмен Diffie-Hellman в KEr и передаёт свой сигнал nonce в Nr.

На этом этапе согласования каждая из сторон может генерировать «затравку» SKEYSEED, на основе которой будут создаваться все ключи для данной IKE_SA. Все, кроме заголовков, во всех последующих сообщениях будет шифроваться с дополнительной защитой целостности. Ключи, используемые для шифрования и защиты целостности, создаются на основе SKEYSEED и обозначаются SK_e (encryption — шифрование) и SK_a (authentication — аутентификация для защиты целостности). Для каждого направления создаются отдельные ключи SK_e и SK_a. В дополнение к ключам SK_e и SK_a, создаваемым из значения DH для защиты IKE_SA, создаётся другая величина SK_d, которая используется для создания последующего материала для защищённых связей CHILD_SA. Обозначения SK { … } показывают, что эти данные зашифрованы с защитой целостности на основе ключей SK_e и SK_a для соответствующего направления.

       HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->

Инициатор предъявляет свою идентификацию в IDi, доказывает своё знание ключа, соответствующего IDi и защищает целостность содержимого первого сообщения, используя AUTH (см. параграф 2.15). Он может также передать свой сертификат (сертификаты) в CERT и список своих доверенных привязок¹¹ в CERTREQ. При включении CERT первый представляемый сертификат должен содержать открытый ключ, используемый для проверки поля AUTH. Необязательные данные IDr позволяют инициатору указать, какую идентификацию он хочет получить от отвечающей стороны. Это полезно в тех случаях, когда на машине, где работает отвечающая сторона, поддерживается множество вариантов идентификации для одного адреса IP. Инициатор начинает согласовывать CHILD_SA с использованием SAi2. Завершающие поля (начиная с SAi2) описаны при рассмотрении обмена CREATE_CHILD_SA.

                                   <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

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

Получателя сообщений 3 и 4 должны проверить корректность расчёта всех сигнатур и MAC, а также соответствие имён в ID ключам, используемым для генерации AUTH.

1.3. Обмен CREATE_CHILD_SA

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

Все сообщения после первоначального обмена шифруются с использованием криптографического алгоритма и ключей, согласованных в первых двух сообщениях обмена IKE. Последующие сообщения используют синтаксис Encrypted Payload (зашифрованные данные), описанный в параграфе 3.14. Все последующие сообщения включаются в Encrypted Payload, даже если они указаны в тексте документа, как «пустые».

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

CHILD_SA создаётся путём передачи запроса CREATE_CHILD_SA. Этот запрос может содержать данные KE для дополнительного обмена Diffie-Hellman, позволяющего заблаговременно гарантировать более строгую защиту (секретность) для CHILD_SA. Ключевой материал для CHILD_SA является функцией SK_d, организованного при создании IKE_SA, обмена сигналами nonce в процессе обмена CREATE_CHILD_SA, и значения Diffie-Hellman (если данные KE включены в обмен CREATE_CHILD_SA).

В CHILD_SA, создаваемой, как часть начального обмена, недопустимо передавать второй KE и nonce. Сигналы nonce из начального обмена используются при расчёте ключей для CHILD_SA.

Запрос CREATE_CHILD_SA включает:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SK {[N], SA, Ni, [KEi],
           [TSi, TSr]}             -->

Инициатор передаёт предложение (предложения) SA в данных SA, nonce в Ni, может передать значение Diffie-Hellman в KEi, а также предложенные селекторы трафика в TSi и TSr. Если этот обмен CREATE_CHILD_SA служит для замены ключей существующей SA, отличной от IKE_SA, ведущие данные N типа REKEY_SA MUST аутентифицируют SA, для которой меняются ключи. Если этот обмен CREATE_CHILD_SA не является заменой ключей для существующей SA, данные N должны быть опущены. Если предложения SA включают различные группы Diffie-Hellman, данные KEi должны быть элементом группы, которую инициатор желает принять от отвечающей стороны. Если это предположение ошибочно, обмен CREATE_CHILD_SA завершится неудачей и будет повторяться с другим KEi.

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

Отклик CREATE_CHILD_SA содержит:

                                  <--    HDR, SK {SA, Nr, [Ker], [TSi, TSr]}

Отвечающая сторона передаёт (используя то же значение Message ID) воспринятое предложение в данных SA, значение Diffie-Hellman в Ker, если в запрос были включены данные Kei, и выбранный криптографический набор, включающий данную группу. Если отвечающий выбирает криптографический набор с другой группой, он должен отвергнуть запрос. Инициатору следует повторить запрос с данными Kei из группы, выбранной отвечающим.

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

1.4. Обмен INFORMATIONAL

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

Управляющие сообщения, которые относятся к IKE_SA MUST, должны передаваться в данной IKE_SA. Управляющие сообщения, которые относятся к CHILD_SA должны передаваться под защитой IKE_SA, которая сгенерировала их (или её наследник, если IKE_SA была заменена при смене ключей).

Сообщения информационного обмена содержат 0 или более элементов данных Notification, Delete и Configuration. Получатель запроса INFORMATIONAL должен передать некий отклик (иначе отправитель будет предполагать потерю сообщения в сети и повторять его). Отклик может быть сообщением без элементов данных. Запросное сообщение в информационном обмене также может не содержать элементов данных. Предполагается, что это может использоваться конечными точками для проверки того, что партнёр «жив».

Защищённые связи ESP и AH всегда существуют в паре по одной SA для каждого направления. При закрытии SA должны быть закрыты оба члена пары. К тех случаях, когда SA являются вложенными, а также когда данные (и заголовки IP в туннельном режиме) сначала инкапсулируются с использованием IPComp, затем организовано ESP и, наконец, AH между одной парой конечных точек, все SA должны удаляться вместе. Каждая из конечных точек должна закрыть свои входящие SA и позволить другой точке закрыть соответствующую SA в каждой паре. Для удаления SA используется информационный обмен с передачей одного или множества элементов удаления (Delete Payload), перечисляющих SPI (которые ожидаются в заголовках входящих пакетов) удаляемых SA. Получатель должен закрыть означенные SA. Обычно отклик в информационном обмене будет содержать элементы удаления для парных SA обратного направления. Но существует одно исключение. Если обе стороны набора SA независимо решат закрыть их, каждая может передать элемент удаления и два запроса могут пересечься в сети. Если узел получает запрос удаления для SA, которые он уже указал в запросе удаления, он должен удалить исходящие SA в процессе обработки запроса и входящие SA при обработке отклика. В таких случаях в отклик недопустимо включать элементы удаления для удалённых SA, поскольку это будет приводить к дублированию удаления и может (теоретически) удалить ненужную SA.

Узлу следует рассматривать полузакрытые соединения, как аномалию, и при их сохранении делать запись в журнал аудита. Отметим, что в этой спецификации не задаётся никаких временных интервалов, поэтому конечные точки сами устанавливают время ожидания. Узел может отвергнуть приём входящих данных через полузакрытое соединение, но недопустимо закрывать его в одностороннем порядке и после этого снова использовать SPI. Если состояние соединения в достаточной степени беспорядочным, узел может закрыть IKE_SA; в этом случае он неявно закрывает все согласованные в нем SA. После этого узел может заново создать требуемые SA на базе новой IKE_SA.

Обмен INFORMATIONAL определяется следующим образом:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SK {[N,] [D,] [CP,]...} -->
                                    <-- HDR, SK {[N,] [D,] [CP],...}

Обработка информационного обмена определяется включёнными в него элементами данных.

1.5. Информационные сообщения вне IKE_SA

Если зашифрованный пакет IKE приходит в порт 500 или 4500 с нераспознанным SPI, причиной этого может быть недавний сбой принимающего узла и потеря информации о состоянии, тот или иной системный отказ или атака. Если принимающий узел имеет активную IKE_SA для IP-адреса, с которого пришел пакет, он может передать уведомление о странном пакете через IKE_SA, используя обмен INFORMATIONAL. Если узел не имеет такой IKE_SA, он может отправить информационное сообщение без криптографической защиты по адресу отправителя пакета. Такое сообщение не является частью информационного обмена и для принявшего это сообщение узла недопустимо отвечать на него. Такой ответ может привести к возникновению петли при обмене сообщениями.

2. Детали и вариации протокола IKE

IKE обычно слушает и передаёт дейтаграммы UDP через порт 500, хотя сообщения IKE принимаются также через порт UDP 4500 с использованием слегка отличающегося формата (см. параграф 2.23). Поскольку протокол UDP использует дейтаграммы (транспорт без гарантии доставки), IKE включает определение процедуры восстановления при ошибках передачи, включая потерю и повторное использование пакетов, а также приём поддельных пакетов. Протокол IKE рассчитан на работу в условиях, когда (1) по крайней мере один из серии переданных повторно пакетов достигает получателя до завершения времени ожидания и (2) канал не переполнен обманными и повторными пакетами так, что это ведёт к нехватке ресурсов сети или производительности CPU¹² на одной из конечных точек. Даже при невыполнении этих минимальных требований IKE будет прерывать работу «чисто» (как при обрыве сети).

Хотя сообщения IKEv2 должны быть короткими, они содержат структуры данных без жёстко заданной верхней границы размера (в частности, сертификаты X.509), а сам протокол IKEv2 не включает механизма фрагментирования больших сообщений. Протокол IP определяет механизм фрагментирования слишком больших дейтаграмм UDP, но максимальный поддерживаемый размер может зависеть от реализации. Более того, использование фрагментации IP открывает реализации для атак на службы (DoS¹³) [KPS03]. Кроме того, некоторые реализации NAT и/или межсетевых экранов могут блокировать фрагменты IP.

Все реализации IKEv2 должны быть способны передавать, принимать и обрабатывать сообщения IKE размером до 1280 байтов и следует также обеспечивать возможность передачи, приёма и обработки сообщений размеров до 3000 байтов. Реализациям IKEv2 следует принимать во внимание максимальный размер поддерживаемых сообщений UDP и можно укорачивать сообщения, убирая из них некоторые предлагаемые сертификаты и криптографические наборы, если это позволит сохранить размер сообщения ниже максимума. Использование форматов «Hash and URL¹⁴» там, где это возможно, позволит избежать большинства проблем. В реализациях и конфигурационных параметрах следует принимать во внимание, что в тех случаях, когда поиск URL становится возможным только после организации IPsec SA, проблемы рекурсии могут воспрепятствовать применению упомянутого метода.

2.1. Использование таймеров повтора передачи

Все сообщения в IKE существуют попарно — запрос и отклик. Организация IKE_SA обычно включает две пары запрос-отклик. После организации IKE_SA любая из сторон защищённой связи может в любой момент инициировать запрос и в каждый момент времени «налету» может находиться множество запросов и откликов. Но каждое сообщение помечается, как запрос или отклик и для каждой пары запрос-отклик одна из сторон является инициатором, а другая — ответчиком.

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

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

2.2. Использование порядковых номеров для Message ID

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

Message ID представляет собой 32-битовое число, которое принимает нулевое значение при передаче в IKE первого запроса в каждом направлении. Начальные сообщения при организации IKE_SA всегда будут иметь номера 0 и 1. Каждая конечная точка в IKE SA поддерживает два «текущих» значения Message ID — следующее, которое будет использоваться при инициировании запроса и следующее, которое она ожидает получить в запросе от другой стороны. Значения счётчиков инкрементируются при генерации и получении запросов, соответственно. Отклик всегда содержит значение Message ID из соответствующего запроса. Это означает, что после начального обмена каждое целое значение n может появляться в качестве идентификатора 4 разных сообщений — n-ого запроса от исходного инициатора IKE, соответствующего ему отклика, n-ого запроса от исходного ответчика IKE и соответствующего ему отклика. Если стороны делают разное число запросов, значения Message ID в разных направлениях могут существенно различаться. Однако здесь не возникает неоднозначности в сообщениях, поскольку биты инициатора (I) и ответчика (R) в заголовке сообщения показывают, которым из четырёх возможных сообщений является данное.

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

2.3. Размер окна для перекрывающихся запросов

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

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

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

Для конечной точки IKE недопустимо выходить за пределы заявленного партнёром размера окна при передаче запросов IKE. Иными словами, если отвечающая сторона заявляет для своего окна размер N, инициатору для того, чтобы отправить запрос X, требуется необходимо дождаться откликов на все запросы, вплоть до X-N. Конечная точка IKE должна хранить копию (или обеспечивать точное воспроизведение) каждого переданного ею запроса, пока на этот запрос не был получен отклик. Конечная точка IKE должна хранить копию (или обеспечивать точное воспроизведение) предыдущих откликов в количестве, равном объявленному ею размеру окна, на случай потери отклика и получения от инициатора повторного запроса.

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

2.4. Синхронизация состояний и время ожидания для соединений

Конечным точкам IKE разрешается в любой момент забывать все свои состояния, связанные с IKE_SA и набором соответствующих CHILD_SA. Это сделано для обеспечения устойчивости к авариям и перезапускам конечных точек. Важно, чтобы при аварии или повторной инициализации состояния конечной точки другая сторона детектировала такие события и прекращала бы расход полосы сети на передачу пакетом через отброшенную SA, которые будут уходить в «чёрную дыру».

Поскольку протокол IKE был разработан с учётом возможности атак на отказ служб (DoS) из сети, для конечной точки недопустимо констатировать отказ другой конечной точки на основе какой-либо маршрутной информации (например, сообщений ICMP) или сообщений IKE, приходящих без криптографической защиты (например, сообщений Notify о неизвестных SPI). Конечная точка должна констатировать отказ другой конечной точки только в случаях повторяющихся в течение всего периода ожидания отказах (отсутствии ответов) при попытках контакта с этой точкой или при получении криптографически защищённого уведомления INITIAL_CONTACT для другой IKE_SA с такой же аутентификацией. Конечной точки на основании соответствующей маршрутной информации и инициировать запрос для проверки жизнеспособности другой точки. Для такой проверки в IKE предусмотрены пустые сообщения INFORMATIONAL, которые (подобно всем запросам IKE) требуют подтверждения (отметим, что в контексте IKE_SA «пустое» сообщение представляет собой заголовок, за которым следует поле Encrypted, не содержащее данных). Если от другой стороны недавно было получено криптографически защищённое соединение, незащищённые уведомления можно игнорировать. Реализации должны ограничивать частоту операций, выполняемых на основе незащищённых соединений.

Число попыток и продолжительность времени ожидания не задаются данной спецификацией, поскольку они не оказывают влияния на взаимодействие. Предлагается повторять передачу сообщения по крайней мере дюжину раз в течение периода по крайней мере в несколько минут прежде, чем отказаться от SA, однако в разных средах эти параметры могут различаться. Для предотвращения возможных перегрузок период повтора передачи сообщений должен возрастать экспоненциально. Если на всех SA, связанных с IKE_SA, присутствовал только исходящий трафик, важно убедиться в жизненности другой конечной точки для предотвращения «чёрных дыр». Если в течение некоторого времени не было получено криптографически защищённых сообщений в IKE_SA или любой из дочерних CHILD_SA, система должна проверить жизненность удалённой точки для предотвращения передачи сообщений «мёртвому» партнёру. Получение свежего, криптографически защищённого сообщения в IKE_SA или любой из дочерних CHILD_SA гарантирует жизненность IKE_SA и всех дочерних CHILD_SA. Отметим, что это вносит требования к обработке отказов конечных точек IKE. Для реализации недопустимо продолжать передачу в любую SA, если тот или иной отказ не позволяет принимать сообщения на всех связанных SA. Если возможен отказ одной CHILD_SA независимо от других без возможности для IKE_SA передачи сообщения Delete, для таких SA должны согласовываться раздельные IKE_SA.

Существуют DoS-атаки на инициатора IKE_SA, которых можно избежать в случае применения инициатором соответствующих мер. Поскольку два первых сообщения при организации SA не защищаются криптографически, атакующий может ответить на сообщения инициатора раньше, чем вызываемая сторона, и сорвать организацию соединения. Для предотвращения этого инициатор может выбрать восприятие множества откликов на своё первое сообщение, трактуя их, как потенциально легитимные, а потом отбросить все некорректные полуоткрытые соединения, когда будет получен корректный, криптографически защищённый отклик на любой из его запросов. После получения криптографически корректного отклика все последующие отклики¹⁵ следует игнорировать, независимо от их криптографической корректности.

Отметим, что с приведёнными правилами не возникает необходимости согласования срока жизни SA. Если IKE предполагает, что партнёр не работает на основе повторяющегося отсутствия подтверждений для сообщения IKE, тогда IKE SA и все дочерние CHILD_SA, организованные в данной IKE_SA, удаляются.

Конечная точка IKE может в любой момент удалить неактивную CHILD_SA в целях освобождения ресурсов, используемых для поддержки состояния этих связей. Если конечная точка IKE принимает решение об удалении CHILD_SA, она должна передать другой стороне элемент Delete для уведомления об удалении. Это может быть похоже на тайм-аут для IKE_SA. Закрытие IKE_SA ведёт к неявному закрытию всех связанных CHILD_SA. В этом случае конечной точке IKE следует передать элемент Delete, показывающий удаление IKE_SA.

2.5. Номера версий и совместимость

В этом документе описывается версия 2.0 протокола IKE — старшая часть версии имеет номер 2, а младшая — 0. Очевидно, что некоторые реализации захотят поддерживать версии 1.0 и 2.0, а в будущем и другие версии.

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

Если конечная точка получает сообщение с большим (чем у неё) значением старшей части номера версии, она должна отбросить такое сообщение; следует также передать в ответ неаутентифицированное уведомление, содержащее поддерживаемое значение старшей части номера версии. Если конечная точка поддерживает версию со старшей частью n и m, она должна также поддерживать все версии между n и m. Если такая точка получает сообщение поддерживаемой версии, она должна отвечать сообщением той же версии. Для предотвращения ситуаций, когда пара узлов использует старшую часть номера версии меньше максимально поддерживаемого обоими узлами номера, в IKE используется флаг, показывающий, что узел способен поддерживать больший номер версии.

Таким образом, старшая часть номера версии в заголовке IKE показывает номер версии для данного сообщения, а не номер версии, поддерживаемой отправителем. Если инициатор способен поддерживать версии n, n+1 и n+2, а отвечающая сторона поддерживает версии n и n+1, они согласуют использование версии n+1, а инициатор будет устанавливать флаг способности поддерживать более высокую версию. Если узлы по ошибке (или в результате активной атаки) согласуют использование версии n, тогда оба узла будут указывать поддержку более высокой версии. В этом случае они должны разорвать соединение и организовать его заново с использованием версии n+1.

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

Для обеспечения совместимости с более новыми версиями во всех резервных полях реализации версии 2.0 должны устанавливать значение 0, а при получении сообщений такие реализации должны игнорировать содержимое резервных полей (будьте консервативными при передаче и либеральными при приёме). В результате новые версии протокола смогут использовать резервные поля так, что их значения будут игнорироваться реализациями, не понимающими таких полей. Аналогично, типы данных, которые не определены, являются резервными¹⁶.

IKEv2 добавляет флаг «критичности» (critical) к каждому заголовку данных для более гибкой совместимости с грядущими версиями. Если флаг critical установлен, а тип данных нераспознан, сообщение должно быть отвергнуто, а отклик на запрос IKE, включающий эти данные, должен включать элемент Notify UNSUPPORTED_CRITICAL_PAYLOAD, показывающий приём нераспознанных критичных данных. Если флаг критичности не установлен, нераспознанный элемент должен игнорироваться.

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

2.6. Cookie

Термин cookie, введённый Karn и Simpson [RFC2522] в Photuris — раннем варианте системы управления ключами IPsec, продолжает использоваться до настоящего времени. Фиксированный заголовок протокола управления ключами и защищёнными связями Internet (ISAKMP) [MSST98] включает два восьмиоктетных поля cookies и этот синтаксис используется в IKEv1 и IKEv2, хотя в последнем эти поля обозначаются, как IKE SPI, и имеется новое отдельное поле в элементе Notify, которое сохраняет значение cookie.

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

В отличие от ESP и AH, где только значение SPI для получателя появляется в заголовке пакета, в IKE каждое сообщение содержит также SPI отправителя. Поскольку значение SPI, выбранное исходным инициатором IKE_SA, всегда передаётся первым, конечная точка со множеством открытых IKE_SA, которая хочет найти подходящую IKE_SA по выбранному для неё значению SPI, должна просматривать значение флага I (инициатор) в заголовке для определения где искать — в первой или второй группе из 8 октетов.

В первом сообщении начального обмена IKE инициатор не знает значение SPI отвечающей стороны и будет, следовательно, помещать в это поле нулевое значение.

Возможной атакой на IKE является истощение ресурсов на хранение состояний и ресурсов CPU, когда объект атаки в лавинном режиме получает запросы на организацию сессий с подставных адресов IP. Воздействие таких атак можно снизить, если реализация отвечающей стороны по минимуму использует CPU и не фиксирует состояния SA до того, как узнает, что инициатор может получать пакеты по адресу, указанному в запросе. Для решения этой задачи ответчику следует при обнаружении большого числа полуоткрытых IKE_SA отвергать стартовые сообщения IKE, если они не содержат элемента Notify типа COOKIE. Взамен ответчику следует передавать в качестве отклика незащищённое сообщение IKE и включать в него COOKIE Notify с данными cookie для возврата. Инициатор, получивший такой отклик, должен повторить IKE_SA_INIT с элементом Notify типа COOKIE, содержащим предложенные ответчиком данные cookie в качестве первого элемента, сохраняя остальные элементы данных. Начальный обмен в таком случае будет иметь вид:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR(A,0), SAi1, KEi, Ni   -->
                                 <-- HDR(A,0), N(COOKIE)
       HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->
                                 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
       HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
           AUTH, SAi2, TSi, TSr} -->
                                 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Два первых сообщения не оказывают влияния на состояние инициатора и ответчика за исключением обмена cookie. В частности, порядковые номера в четырёх первых сообщениях будут иметь нулевые значения, а в двух последних сообщениях приведённого примера номера будут иметь значение 1. «A» обозначает значение SPI, присвоенное инициатором, а «B» — значение, присвоенное ответчиком.

Реализации IKE следует поддерживать генерацию cookie ответчиком так, чтобы не требовалось сохранять какое-либо состояние для проверки корректности cookie при получении второго сообщения IKE_SA_INIT. Выбор алгоритма и используемый для cookie синтаксис не оказывают влияния на взаимодействие, поэтому не задаются данной спецификацией. Ниже приведён пример использования cookie конечной точкой для частичной защиты от DoS—атак.

Хорошим способом реализации такой защиты является установка ответчиком cookie по следующему алгоритму:

      Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

где <secret> — случайное значение, известное только ответчику и периодически сменяемое, | указывает конкатенацию. Значение <VersionIDofSecret> следует менять всякий раз при смене <secret>. Значение cookie может быть рассчитано заново при получении IKE_SA_INIT второй раз и полученное значение сравнивается со значением cookie в принятом сообщении. Если значения совпадают, ответчик знает, что значение cookie было создано после замены <secret> и значение IPi должно совпадать с адресом отправителя, полученным в первом сообщении. Включение SPIi в расчёт обеспечивает создание различных значений cookie для случаев, когда множество IKE_SA создаётся одновременно (предполагается, что инициаторы устанавливают уникальные значения SPIi). Включение в хэш значения Ni не позволяет атакующему, который увидел только сообщение 2, корректно подменить сообщение 3.

Если значение <secret> меняется в процессе инициализации соединения, сообщение IKE_SA_INIT может быть возвращено с отличным от текущего значением <VersionIDofSecret>. Ответчик в таком случае может отвергнуть сообщение, передавая другой отклик с новым значением cookie, или может сохранять старое значение <secret> на короткое время после его замены и принимать cookie, рассчитанные с использованием этого значения. Ответчику не следует воспринимать cookie неограниченно долго после смены <secret>, поскольку это будет нарушать часть защиты от DoS-атак. Ответчику следует менять значение <secret> достаточно часто, особенно во время атак.

2.7. Согласование криптоалгоритма

Элемент данных типа SA показывает предложения в части выбора протоколов IPsec (IKE, ESP и/или AH) для SA, а также криптографических алгоритмов, связанных с каждым протоколом.

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

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

Каждое предложение включает, по крайней мере, один протокол. Если предложение принимается элемент SA в отклике должен содержать те же протоколы в том же порядке, как они были указаны в предложении. Ответчик должен принять одно из предложений или отвергнуть все предложения и возвратить сообщение об ошибке (Например, если предложение включает протоколы ESP и AH и это предложение принимается, оба протокола ESP и AH должны восприниматься. Если ESP и AH включены в разные предложения, ответчик должен принять только один из этих протоколов¹⁷).

Каждый предлагаемый протокол IPsec содержит, по крайней мере, одно преобразование. Каждое преобразование включает тип преобразования. Принимаемые криптографические наборы должны содержать в точности одно преобразование каждого типа, включённого в предложение. Например, если предложение ESP включает преобразования ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES с размером ключа 256, AUTH_HMAC_MD5 и AUTH_HMAC_SHA, принятый набор должен включать одно преобразование ENCR_ и одно преобразование AUTH_. Таким образом, возможно шесть комбинаций.

Поскольку инициатор передаёт своё значение Diffie-Hellman в сообщении IKE_SA_INIT, он должен угадать группу Diffie-Hellman, которую ответчик выберет из списка поддерживаемых групп. Если выбор инициатора окажется ошибочным, ответчик будет возвращать элемент данных Notify типа INVALID_KE_PAYLOAD, показывающий выбранную группу. В таком случае инициатор должен повторить запрос IKE_SA_INIT с указанием корректной группы Diffie-Hellman. Инициатор должен снова предложить полный набор допустимых криптографических наборов, поскольку сообщение с отказом было передано без аутентификации. Если этого не делать, активный атакующий сможет принудить конечные точки к выбору наиболее слабого криптографического набора из числа поддерживаемых обеими сторонами.

2.8. Смена ключей

Защищённые связи IKE, ESP и AH используют секретные ключи, которые следует применять в течение ограниченного периода времени для защиты ограниченного объёма данных. Эти требования ограничивают срок существования защищённых связей. Когда время жизни защищённой связи заканчивается, дальнейшее использование такой связи недопустимо. При необходимости может быть организована новая защищённая связь. Повторная организация защищённой связи при завершении срока существования последней называется сменой ключей (rekeying).

Для того, чтобы сохранить возможность создания реализаций IPsec с минимальным набором возможностей, смена ключей SA без повторной организации IKE_SA целиком является необязательной. Реализация может отвергать все запросы CREATE_CHILD_SA в IKE_SA. Если срок жизни SA закончился или близок к завершению и попытки смены ключей с использованием описанных здесь механизмов не дали положительного результата, реализация должна закрыть IKE_SA и все дочерние CHILD_SA, а после этого может организовать новые связи. Реализациям следует поддерживать замену ключей для SA, поскольку это обеспечивает повышение производительности и снижение числа пакетов, теряемых в переходный период.

Для смены ключей CHILD_SA в существующей IKE_SA создаётся новая, эквивалентная SA (см. параграф 2.17 ниже) и после создания старая связь удаляется. Для смены ключей IKE_SA создаётся новая, эквивалентная IKE_SA (см. параграф 2.18 ниже) с партнёром, который в старой IKE_SA совместно использовался в CREATE_CHILD_SA. Созданная таким путём IKE_SA наследует все CHILD_SA исходной in-place. Используется новая IKE_SA для всех управляющих сообщений, требуемых для поддержки CHILD_SA, созданных старой IKE_SA, после чего старая IKE_SA удаляется. Элемент данных Delete для удаления самой связи должен быть последним запросом, передаваемым через старую IKE_SA.

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

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

Если политика обеих сторон в части времени жизни совпадает, они могут ввести запросы на смену ключей одновременно (это приведёт к созданию избыточных SA). Для снижения вероятности такого события следует использовать вариации периода смены ключей (при получении уведомления о необходимости замены ключей вносится случайная задержка).

Такая форма смены ключей может приводить к временному существованию множества похожих SA между одной парой узлов. При наличии двух SA, подходящих для получения пакетов, узел должен воспринимать входящие пакеты из обеих SA. Если при таком конфликте создаются избыточные SA, связь, имеющую наименьшее из четырёх использованных в этих двух обмена значений nonce, следует закрыть (конечной точке, которая создала эту связь).

Отметим, что существование параллельных SA с одинаковым трафиком между парой конечных точек разрешено в IKEv2 осознанно. Одной из причин этого является поддержка различий в качестве обслуживания трафика (QoS¹⁸) между SA (см. [RFC2474], [RFC2475] и параграф 4.1 в [RFC2983]). Следовательно, в отличие от IKEv1, комбинация конечных точек и селекторов трафика может не быть уникальным идентификатором SA между парой точек, поэтому принятое при смене ключей в IKEv1 эвристическое удаление SA на основе совпадения селекторов трафика не следует использовать.

Узлу, который инициировал SA при досрочной замене ключей, следует удалить заменённую SA после создания новой.

Существуют интервалы времени (в частности, в присутствии потерь пакетов), когда конечные точки могут по разному трактовать состояние SA. Отвечающая на CREATE_CHILD_SA сторона должна быть готова к восприятию сообщений через SA до передачи своего отклика на запрос создания связи, поэтому здесь для инициатора не возникает неоднозначности. Инициатор может начать передачу в SA сразу после обработки отклика. Инициатор, однако, не может принимать через новую SA до получения и обработки отклика на свой запрос CREATE_CHILD_SA. Как, в таком случае, ответчик может узнать о возможности начать передачу в новую SA?

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

Ответчик может быть уверен в том, что инициатор готов получать сообщения через SA, если (1) он получил криптографически корректное сообщение через новую SA или (2) новая SA создана при замене ключей для существующей SA и был получен запрос IKE на закрытие заменённой SA. При смене ключей SA ответчику следует продолжать передачу сообщений через старую SA, пока не будет выполнено какое-либо из приведённых выше условий. При создании новой SA ответчик может отложить передачу сообщений через неё до получения сообщения через неё или завершения времени ожидания. Если инициатор получает сообщение в SA, для которой он ещё не получил отклика на свой запрос CREATE_CHILD_SA, ему следует интерпретировать это событие, как потерю пакетов, и передать запрос CREATE_CHILD_SA повторно. Инициатор может передать бутафорское (dummy) сообщение через новую SA, если у него нет сообщений в очереди, чтобы уведомить ответчика о своей готовности к приёму сообщений.

2.9. Согласование селекторов трафика

Когда полученный поддерживающей RFC4301 системой IPsec пакет IP соответствует «селектору защиты» в соответствии с SPD¹⁹, подсистема должна защитить пакет с использованием IPsec. Если SA ещё не существует, её создание является задачей IKE. Поддержка SPD в системе выходит за пределы IKE (см. [PFKEY] в качестве примера протокола), хотя некоторые реализации могут обновлять свои SPD в контакте с работающим IKE (см., для примера, сценарий 1.1.3).

Элементы данных TS²⁰ позволяют конечным точкам обмениваться некой информацией из SPD со своими партнёрами. Элементы TS задают критерии выбора пакетов, которые будут передаваться через вновь созданную SA. Это может служить проверкой согласованности в некоторых сценариях для контроля непротиворечивости SPD. В других случаях это ведёт к динамическому обновлению SPD.

В каждом из сообщений обмена, создающего пару CHILD_SA, появляется два элемента TS. Каждый из TS содержит один или множество селекторов трафика. Каждый селектор состоит из диапазона адресов (IPv4 или IPv6), диапазона портов и идентификатора протокола IP. В поддержку сценария, описанного в параграфе 1.1.3, инициатор может запросить у отвечающей стороны выделение адреса IP с его кратким описанием (что это?).

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

Первый из двух элементов TS называют TSi²¹, а второй — TSr²². TSi задаёт адрес отправителя трафика, пересылаемого от инициатора (или адрес получателя трафика, пересылаемого инициатору) пары CHILD_SA. TSr указывает адрес получателя трафика, пересылаемого ответчика (или адрес отправителя трафика, пересылаемого от ответчика) пары CHILD_SA. Например, если исходный инициатор запрашивает создание пары CHILD_SA и хочет туннелировать весь трафик из подсети 192.0.1.* на своей стороне в подсеть 192.0.2.*²³ на стороне ответчика, инициатор будет включать один селектор трафика в каждый элемент TS. TSi будет задавать диапазон адресов 192.0.1.0 — 192.0.1.255, а TSr — диапазон 192.0.2.0 — 192.0.2.255. Предположим, что предложение будет принято ответчиком — тогда он будет передавать обратно идентичные элементы TS.

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

Политика отвечающей стороны может содержать множество меньших диапазонов, охватываемое предложенным инициатором селектором трафика, причём политика требует передачи трафика для этих диапазонов через разные SA. Продолжим использование приведённых выше для примера адресов. Ответчик может иметь политику, которая позволяет туннелировать эти адреса в направлении инициатора и от него, но может требовать, чтобы для каждой пары адресов независимо согласовывалась CHILD_SA. Если инициатор генерирует свой запрос в ответ на пакет с адреса 192.0.1.43, направленный по адресу 192.0.2.123, у ответчика не будет способа определить, какую пару адресов следует включить в этот туннель и он будет пытаться угадать или отбросить запрос со статусом SINGLE_PAIR_REQUIRED.

Чтобы позволить ответчику выбрать подходящий диапазон в том случае, когда инициатор запрашивает SA в результате получения пакета данных, инициатору следует включить в качестве первого селектора трафика в каждом элементе Tsi и TSr очень специфичный селектор трафика, включающий адреса в пакете, вызвавшем запрос. В нашем примере инициатор будет включать в TSi два селектора трафика — первый будет содержать диапазон адресов 192.0.1.43 — 192.0.1.43, а также порт отправителя и протокол IP из пакета, а второй — диапазон 192.0.1.0 — 192.0.1.255 со всеми портами и протоколами. Инициатор будет также включать два селектора трафика в TSr.

Если политика отвечающей стороны не позволяет принять весь набор селекторов трафика из запроса инициатора, но позволяет принять первый селектор TSi и TSr, ответчик должен сузить селекторы трафика до подмножества, включающего первый выбор инициатора. В приведённом примере ответчик может возвратить TSi 192.0.1.43 — 192.0.1.43 с поддержкой всех портов и протоколов IP.

Если инициатор создаёт CHILD_SA пару не в ответ на получение пакета, а, например, при старте, может не быть предпочтений в части адресов для начального туннеля. В таких случаях первые значения TSi и TSr могут задавать диапазоны, а не конкретные адреса и ответчик выбирает подходящее подмножество указанных инициатором TSi и TSr. Если ответчика устраивает несколько подмножеств, которые нельзя объединить, ответчик должен принять некое подмножество и может включить в сообщение элемент Notify типа ADDITIONAL_TS_POSSIBLE для индикации инициатору возможности повтора. Такая ситуация возникает только в тех случаях, когда конфигурации инициатора и ответчика различаются. Если инициатор и ответчик согласовали гранулярность туннелей, инициатор никогда не будет запрашивать более широкий туннель, нежели приемлет отвечающая сторона. Такие расхождения в конфигурационных параметрах следует заносить в системный журнал ошибок.

2.10. Элементы nonce

Каждое сообщение IKE_SA_INIT содержит nonce. Эти nonce используются в качестве входной информации для криптографических функций. Запросы CREATE_CHILD_SA и отклики CREATE_CHILD_SA также включают nonce. Эти nonce используются для повышения эффективности метода, используемого при получении ключей для CHILD_SA, обеспечения достаточно высокого уровня случайности для псевдослучайных битов, получаемых из ключа Diffie-Hellman. Элементы nonce, используемые в IKEv2, должны выбираться случайным образом, должны иметь размер не менее 128 битов и не менее половины размера ключа согласованной prf²⁴. При использовании некого общего источника случайных чисел для ключей и nonce нужно быть осторожными, чтобы использование nonce не привело к компрометации ключей.

2.11. Использование адресов и портов

IKE работает по протоколу UDP через порты 500 и 4500, неявно устанавливая связи ESP и AH для тех же адресов IP. Адреса IP и номера портов во внешнем заголовке не защищаются криптографически и протокол IKE может работать даже через устройства трансляции адресов (NAT). Реализация должна воспринимать входящие запросы даже из портов с номерами, отличными от 500 или 4500 и должна отвечать на адрес и порт, с которых был получен запрос. Реализация должна указать в отклике адрес и порт, через которые был принят запрос, в качестве адреса и порта отправителя. Функции IKE идентичны для протоколов IPv4 и IPv6.

2.12. Многократное использование экспоненциалов Diffie-Hellman

Для обеспечения высокого уровня защиты²⁵ IKE генерирует короткоживущие ключи с использованием обмена Diffie-Hellman. Это означает, что после закрытия соединения соответствующие ключи забываются. Если кто-либо смог записать всю переданную через соединение информацию и получил доступ к долгосрочным ключам обеих сторон соединения, он не сможет восстановить ключи, которые использовались для соединения без перебора²⁶ всего пространства сеансовых ключей.

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

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

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

2.13. Материал для генерации ключей

В контексте IKE_SA согласуются четыре криптографических алгоритма — алгоритм шифрования, алгоритм защиты целостности, группа Diffie-Hellman и псевдослучайная функция (prf). Последняя используется при создании ключевого материала для всех криптографических алгоритмов, используемых как в IKE_SA, так и в дочерних CHILD_SA.

Мы полагаем, что каждый алгоритм шифрования и защиты целостности использует ключ фиксированного размера и случайно выбранное значение фиксированного размера может служить подходящим ключом. Для алгоритмов, которые воспринимают ключи переменного размера, должен указываться фиксированный размер ключа в процессе согласования криптографических преобразований. Для алгоритмов, в которых не все значения являются допустимыми ключами (например, DES или 3DES с чётностью ключа) криптографическим преобразованием должен задаваться алгоритм создания ключей из произвольных значений. Для функций защиты целостности на основе кода HMAC²⁷ фиксированным размером ключа является размер вывода нижележащей функции хэширования. Когда функций prf принимает ключ переменной длины и данные переменной длины, давая результат фиксированного размера (например, при использовании HMAC), применяются формулы из этого документа. Когда ключ для prf имеет фиксированный размер, представленные в качестве ключа данные усекаются или дополняются нулями, если приведённая ниже формула не задаёт специальной обработки.

Ключевой материал всегда производится, как выход согласованного алгоритма prf. Поскольку количество требуемого ключевого материала может быть больше, чем размер вывода алгоритма prf, мы будем использовать prf итеративно. Обозначим prf+ функцию, которая даёт на выходе псевдослучайный поток на основе входной информации prf в соответствии с приведёнными ниже правилами (| обозначает конкатенацию).

   prf+ (K,S) = T1 | T2 | T3 | T4 | ...

где:

   T1 = prf (K, S | 0x01)
   T2 = prf (K, T1 | S | 0x02)
   T3 = prf (K, T2 | S | 0x03)
   T4 = prf (K, T3 | S | 0x04)

и т. д., пока не будет достаточно материала для расчёта всех требуемых ключей. Ключи берутся из выходной строки без учёта границ (например, если нужен 256-битовый ключ AES²⁸ и 160-битовый ключ HMAC, а функция prf даёт на выходе 160 битов, ключ AES будет взят из T1 и начальной части T2, а ключ HMAC возьмёт остаток T2 и начало T3).

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

2.14. Генерация ключевого материала для IKE_SA

Для расчёта разделяемых ключей сначала вычисляется значение SKEYSEED на основе nonce из обмена IKE_SA_INIT и разделяемого секрета Diffie-Hellman созданного при этом обмене. Значение SKEYSEED используется для расчёта семи других секретов — SK_d применяется при создании новых ключей для CHILD_SA, создаваемых в данной IKE_SA; SK_ai и SK_ar применяются в качестве ключа алгоритма защиты целостности для аутентификации компонент сообщений в последующих обменах; SK_ei и SK_er применяются для шифрования (и дешифровки) всех последующих обменов; SK_pi и SK_pr применяются при генерации элемента данных AUTH.

SKEYSEED и производные от него ключи рассчитываются следующим образом:

SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)

(левая часть второго уравнения показывает, что значения SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi и SK_pr берутся в указанном порядке из битов результата prf+). Параметр g^ir является разделяемым секретом из краткосрочного²⁹ обмена Diffie-Hellman. Значение g^ir представляется строкой октетов в формате big endian³⁰ с дополнением при необходимости нулями для выполнения требований по размеру модуля. Ni и Nr — значения элементов nonce, извлечённые из любых заголовков. Если согласованная функция prf принимает ключ фиксированного размера, а суммарная длина Ni и Nr превышает нужное значения, берётся половина (первая) битов из Ni и половина (первая) битов из Nr.

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

2.15. Аутентификация IKE_SA

Если не используется расширяемая аутентификация (см. параграф 2.16), партнёры аутентифицируют себя посредством подписи (или MAC³¹ с использованием разделяемого секрета в качестве ключа) для блока данных. Для ответчика подписываемые данные начинаются с первого октета первого SPI в заголовке второго сообщения и заканчиваются последним октетом последнего элемента данных во втором сообщении. В конце к этому добавляется (с целью расчёта подписи) значение nonce Ni от инициатора (просто значение, а не содержащий его элемент данных) и значение prf(SK_pr,IDr’), где IDr’ — элемент ID ответчика без фиксированного заголовка. Отметим, что ни одно из значений Ni и prf(SK_pr,IDr’) не передаётся. Подобно этому инициатор подписывает первое сообщение, начиная с первого октета первого SPI в заголовке и заканчивая последним октетом последнего элемента данных. В конце к этому добавляется (для расчёта подписи) значение nonce Nr от ответчика и значение prf(SK_pi,IDi’). В приведённых выше расчётах IDi’ и IDr’ являются полными элементами данных ID без фиксированного заголовка. Для защиты обмена критично наличие подписи каждой стороны для nonce другой стороны.

Отметим, что подписываются все элементы данных, включая и те, которые не определены в этом документе. Если первое сообщение в обмене передаётся дважды (второй раз с cookie ответчика и/или другой группой Diffie-Hellman), подписывается вторая версия сообщения.

В дополнение к сказанному сообщения 3 и 4 могут включать сертификат или цепочку сертификатов, обеспечивающие очевидность того, что использованные для расчёта цифровой подписи ключ относится к имени в элементе данных ID. Сигнатура или MAC будет рассчитываться с использованием алгоритмов, диктуемых типом ключа, используемого подписывающим, и задаётся полем Auth Method в элементе данных Authentication. Здесь не задаётся использования одного криптографического алгоритма для инициатора и ответчика. Выбор криптографического алгоритма зависит от типа ключа, который имеет каждая из сторон. В частности, инициатор может использовать разделяемый ключ, а ответчик может иметь открытый ключ подписи и сертификат. Обычной (но не обязательной) практикой при наличии разделяемого ключа является использование этого ключа для аутентификации в обоих направлениях. Отметим, что общепринято, хотя и не обеспечивает достаточной защиты, использование разделяемого ключа, созданного исключительно на базе выбранного пользователем пароля без использования других источников случайных данных.

Такая защита недостаточна, поскольку пользовательские пароли с очевидностью не являются достаточно непредсказуемыми для устойчивости к атакам по словарю, следовательно данный метод от таких атак не защищает (приложениям, использующим аутентификацию по паролю на этапе загрузки и IKE_SA, следует применять метод аутентификации, описанный в параграфе 2.16, который предназначен для защиты от атак по словарю в режиме off-line). Разделяемый (pre-shared) ключ следует делать столь же непредсказуемым, как наиболее сильный из согласуемых ключей. В случае pre-shared-ключа значение AUTH вычисляется, как:

      AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)

где строка «Key Pad for IKEv2» представляет собой 17 символов ASCII без завершающего нуля. Разделяемый секрет (shared secret) может иметь переменный размер. Строка заполнения добавляется для того, чтобы при использовании разделяемого секрета на основе пароля реализации IKE не требовалось сохранять пароль в открытом виде, а можно было хранить его в форме prf(Shared Secret,»Key Pad for IKEv2″), которая не будет использоваться в качестве пароля для отличных от IKEv2 протоколов. Как отмечено выше, создание разделяемого ключа на основе пароля не обеспечивает должной защиты. Такая конструкция отмечена лишь потому, что многие люди ей пользуются до сих пор. Интерфейс управления, через который обеспечивается Shared Secret, должен принимать строки символов ASCII размером, по крайней мере, 64 октета; добавление завершающего нуля перед использованием строки в качестве разделяемого секрета недопустимо. Интерфейс управления должен также воспринимать разделяемый секрет в шестнадцатеричном (HEX) представлении. Интерфейс управления может воспринимать другие варианты кодировки строки, если указан алгоритм преобразования в двоичную строку. Если согласованная функция prf принимает ключ фиксированного размера, разделяемый секрет должен иметь такой же размер.

2.16. Методы EAP

В дополнение к аутентификации на основе подписей с открытыми ключами и разделяемыми секретами IKE поддерживает аутентификацию с использованием методов, определённых в RFC 3748 [EAP]. Обычно эти методы являются асимметричными (они разработаны для аутентификации пользователей на сервере) и могут не быть обоюдными. По это причине упомянутые протоколы обычно используются для аутентификации инициатора на отвечающей стороне и должны применяться в комбинации с аутентификацией ответчика инициатору по цифровой подписи на основе открытого ключа. Эти методы часто ассоциируются с механизмами, которые называют «унаследованной аутентификацией» (Legacy Authentication).

Хотя в этом документе [EAP] упоминается, прежде всего, в плане добавления в будущем новых методов без обновления данной спецификации, некоторые простые варианты описаны здесь и в параграфе 3.16. [EAP] определяет протокол аутентификации с переменным числом сообщений. Расширяемая аутентификация реализуется в IKE, как дополнительные обмены IKE_AUTH, которые должны быть выполнены для инициализации IKE_SA.

Инициатор показывает своё намерение использовать расширяемую аутентификацию, пропуская элемент AUTH в сообщении 3. За счёт включения элемента IDi при отсутствии AUTH инициатор объявляет свою идентификацию, но не подтверждает её. Если ответчик желает использовать расширяемую аутентификацию, он будет включать элемент EAP³² в сообщение 4 и откладывает передачу SAr2, TSi и Tsr, пока аутентификации инициатора не будет завершена в последующем обмене IKE_AUTH. В варианте минимально расширяемой аутентификации организация начальной SA будет иметь вид:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SAi1, KEi, Ni         -->
                                  <--    HDR, SAr1, KEr, Nr, [CERTREQ]
       HDR, SK {IDi, [CERTREQ,] [IDr,]
                SAi2, TSi, TSr}   -->
                                  <--    HDR, SK {IDr, [CERT,] AUTH, EAP}
       HDR, SK {EAP}              -->
                                  <--    HDR, SK {EAP (success)}
       HDR, SK {AUTH}             -->
                                  <--    HDR, SK {AUTH, SAr2, TSi, TSr}

Для методов EAP, которые создают разделяемый ключ в качестве побочного продукта аутентификации, этот ключ должен использоваться инициатором и ответчиком для генерации элементов данных AUTH в сообщениях 7 и 8 с использованием синтаксиса для разделяемых секретов, описанного в параграфе 2.15. Разделяемый ключ от EAP в спецификации EAP называется полем MSK. Разделяемый ключ, созданный в процессе обмена IKE, недопустимо использовать для иных целей.

Методы EAP, не создающие разделяемого ключа, использовать не следует, поскольку они подвержены многочисленным атакам MITM³³ [EAPMITM] при использовании в других протоколах, не применяющих аутентифицированные сервером туннели. Если используются методы EAP, не генерирующие разделяемого ключа, элементы данных AUTH в сообщениях 7 и 8 должны генерироваться с использованием SK_pi и SK_pr, соответственно.

Инициатору IKE_SA с использованием EAP следует поддерживать возможность расширения начального протокольного обмена по крайней мере до десяти обменов IKE_AUTH, если ответчик передаёт уведомления и/или повторяет приглашение к аутентификации. После успешного завершения протокольного обмена, определённого выбранным методом аутентификации EAP ответчик должен передать данные EAP, содержащие сообщение Success. Если при использовании выбранного метода аутентификации возник отказ, ответчик должен передать данные EAP, содержащие сообщение Failure. Ответчик может в любой момент прервать обмен IKE путём передачи данных EAP с сообщением Failure.

При таком расширенном обмене элементы данных EAP AUTH должны включаться в два сообщения, следующие за сообщением, содержащим EAP Success.

2.17. Материал для генерации ключей CHILD_SA

Одна связь CHILD_SA создаётся обменом IKE_AUTH, а дополнительные CHILD_SA могут создаваться в обменах CREATE_CHILD_SA. Ключевой материал для них создаётся следующим образом:

      KEYMAT = prf+(SK_d, Ni | Nr)

Здесь Ni и Nr — nonce из обмена IKE_SA_INIT, если данный запрос является первым созданием CHILD_SA, или обновлённые Ni и Nr из обмена CREATE_CHILD_SA при создании дополнительных связей.

Для обменов CREATE_CHILD_SA, включающих дополнительный обмен Diffie-Hellman, ключевой материал определяется следующим образом:

      KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )

где g^ir (new) — разделяемый секрет из краткосрочного обмена Diffie-Hellman данного обмена CREATE_CHILD_SA (представляется, как строка октетов в формате big endian, дополненная нулями в старших битах при необходимости выравнивания размера по модулю).

Согласование одной CHILD_SA может приводить к созданию множества защищённых связей. Связи ESP и AH существуют попарно (по одной для каждого направления) и при использовании одновременно ESP и AH в одном согласовании CHILD_SA могут создаваться четыре SA.

Ключевой материал должен браться из KEYMAT в следующем порядке:

все ключи для SA, передающих данные от инициатора к ответчику, берутся до SA в обратном направлении;

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

если один протокол имеет ключи для шифрования и аутентификации, ключ шифрования берётся из первых октетов KEYMAT, а ключ аутентификации — из последующих.

Каждый криптографический алгоритм берет фиксированное число битов ключевого материала, задаваемое в спецификации алгоритма.

2.18. Смена ключей IKE_SA с использованием обмена CREATE_CHILD_SA

Обмен CREATE_CHILD_SA можно использовать для смены ключей существующей связи IKE_SA (см. 2.8). Новые SPI инициатора и ответчика передаются в полях SPI. Элементы данных TS опускаются при смене ключей IKE_SA. SKEYSEED для новой IKE_SA рассчитывается с использованием SK_d из существующей IKE_SA:

       SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)

где g^ir (new) — разделяемый секрет из краткосрочного обмена Diffie-Hellman данного обмена CREATE_CHILD_SA (представляется, как строка октетов в формате big endian, дополненная нулями в старших битах при необходимости выравнивания размера по модулю), а Ni и Nr — два значения nonce из любых заголовков.

Новая связь IKE_SA должна сбросить свои счётчики сообщений в 0.

SK_d, SK_ai, SK_ar, SK_ei и SK_er рассчитываются из SKEYSEED, как описано в параграфе 2.14.

2.19. Запрос внутреннего адреса удалённой сети

В наиболее распространённом сценарии с подключением конечной точки к защитному шлюзу конечной точке может потребоваться адрес IP из защищённой шлюзом сети; для такого адреса может также потребоваться динамическое выделение. Запрос на такой временный адрес может быть включён в любой запрос на создание CHILD_SA (включая неявный запрос в сообщении 3) с помощью элемента данных CP.

Эта функция обеспечивает выделение адреса для клиента IRAC³⁴, пытающегося организовать туннель в сеть, защищённую сервером удалённого доступа IRAS³⁵. Поскольку обмен IKE_AUTH создаёт связи IKE_SA и CHILD_SA, IRAC должен запрашивать контролируемый IRAS адрес (и, возможно, другую информацию о защищённой сети) в обмене IKE_AUTH. IRAS может предоставлять адрес для IRAC из любого числа источников адресов типа серверов DHCP/BOOTP или из собственного блока адресов.

       Инициатор                          Ответчик
      -----------                        ------------
       HDR, SK {IDi, [CERT,] [CERTREQ,]
        [IDr,] AUTH, CP(CFG_REQUEST),
        SAi2, TSi, TSr}              -->
                                     <--   HDR, SK {IDr, [CERT,] AUTH,
                                            CP(CFG_REPLY), Sar2, TSi, TSr}

Во всех случаях элемент данных CP должен помещаться перед элементом SA. В вариациях протокола с множеством обменов IKE_AUTH элементы CP должны помещаться в сообщения, содержащие элементы SA.

Элемент CP(CFG_REQUEST) должен содержать по крайней мере атрибут INTERNAL_ADDRESS (IPv4 или IPv6), но может включать любое число дополнительных атрибутов, которые инициатор пожелал получить в отклике.

Ниже показан пример сообщения от инициатора к ответчику.

      CP(CFG_REQUEST)=
        INTERNAL_ADDRESS(0.0.0.0)
        INTERNAL_NETMASK(0.0.0.0)
        INTERNAL_DNS(0.0.0.0)
      TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
      TSr = (0, 0-65535,0.0.0.0-255.255.255.255)

Примечание. Селекторы трафика TS содержат (протокол, диапазон портов, диапазон адресов).

Сообщение инициатору от ответчика:

      CP(CFG_REPLY)=
        INTERNAL_ADDRESS(192.0.2.202)
        INTERNAL_NETMASK(255.255.255.0)
        INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
      TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
      TSr = (0, 0-65535,192.0.2.0-192.0.2.255)

Все возвращаемые значения зависят от реализации. Как можно видеть из приведённого выше примера, IRAS может также передавать другие атрибуты, которые не были включены в CP(CFG_REQUEST) и могут игнорировать необязательные атрибуты, которые они не поддерживают.

Для ответчика недопустимо передавать CFG_REPLY, если не был до этого принят запрос CP(CFG_REQUEST) от инициатора, поскольку мы не хотим, чтобы IRAS выполнял ненужные просмотры конфигурации, если IRAC не может обработать REPLY. В тех случаях, когда конфигурация IRAS требует, использования CP для данного IDi, но IRAC не удалось передать CP(CFG_REQUEST), сервер IRAS должен отвергнуть запрос и прервать обмен IKE с возвратом ошибки FAILED_CP_REQUIRED.

2.20. Запрос версии партнёра

Узел IKE, желающий узнать номер версии программ своего партнёра IKE, может воспользоваться описанным ниже методом. Это пример конфигурационного запроса в рамках обмена INFORMATIONAL после создания IKE_SA и первой дочерней CHILD_SA.

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

       Инициатор                          Ответчик
      -----------                        ----------
      HDR, SK{CP(CFG_REQUEST)}      -->
                                    <--    HDR, SK{CP(CFG_REPLY)}
      CP(CFG_REQUEST)=APPLICATION_VERSION("")
      CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")

2.21. Обработка ошибок

При обработке IKE может происходить множество разных ошибок. Если принятый запрос имеет некорректный формат или неприемлем по соображениям политики (например, не соответствуют криптографические алгоритмы), отклик должен содержать элемент Notify, показывающий ошибку. Если ошибка произошла за пределами контекста запроса IKE (например, узел получает сообщения ESP на несуществующий SPI), узлу следует инициировать обмен INFORMATIONAL с элементом данных Notify, описывающим проблему.

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

Если узел получает сообщение в порт UDP с номером 500 или 4500 за пределами известного ему контекста IKE_SA (и это сообщение не является запросом на создание контекста), это может говорить о недавней аварии узла. Если сообщение отмечено, как отклик, узел может занести информацию о нем в журнал аудита, но отвечать на такое сообщение недопустимо. Если сообщение помечено, как запрос, отклик на него должен быть передан в адрес IP и порт, с которых запрос поступил, при этом значения IKE SPI и Message ID в отклике должны быть копиями этих полей из запроса. Недопустимо использовать для отклика криптографическую защиту и отклик должен содержать элемент Notify, показывающий INVALID_IKE_SPI.

Узлу, получившему такой незащищённый элемент Notify, недопустимо менять состояние существующих SA. Сообщение может быть обманным или может являться легитимного корреспондента, вовлечённого в передачу обманным путём. Узлу следует трактовать такое сообщение (а также сетевые сообщения типа ICMP destination unreachable), как намёк о возможности проблем с SA для данного адреса IP, а также следует выполнить проверку жизненности для всех таких IKE_SA. Реализациям следует ограничивать частоту таких проверок для предотвращения возможности их использования для организации атак на службы.

Узел, получивший подозрительное сообщение с IP-адреса, с которым он имеет IKE_SA, может передать элемент данных IKE Notify в обмене IKE INFORMATIONAL через имеющуюся SA. Получателю недопустимо менять состояние каких-либо SA в результате приёма такого сообщения, но следует записать событие в журнал аудита для упрощения диагностики. Узел должен ограничивать скорость передачи откликов на незащищённые сообщения.

2.22. Компрессия IPComp

Использование компрессии IP [IPCOMP] может быть согласовано на этапе создания CHILD_SA. Хотя компрессия IP включает дополнительный заголовок в каждом пакете и список параметров компрессии (CPI1), виртуальная «связь с компрессией» не существует за пределами содержащей её ESP или AH SA. «Связи с компрессией» исчезают при удалении соответствующей ESP или AH SA. Эти связи не упоминаются явно в элементах данных DELETE.

Согласование компрессии IP отделено от согласования криптографических параметров, связанных с CHILD_SA. Узел, запрашивающий создание CHILD_SA, может анонсировать поддержку одного или множества алгоритмов компрессии путём передачи одного или множества элементов Notify типа IPCOMP_SUPPORTED. Отклик может показывать приемлемость одного алгоритма компрессии с помощью элемента Notify типа IPCOMP_SUPPORTED. Такие элементы недопустимо включать в сообщения, не содержащие элементов SA.

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

Побочным эффектом раздельного согласования IPComp и криптографических параметров является невозможность предложить множество криптографических наборов и компрессию IP, которая будет использоваться с частью (но не со всеми) предложенных наборов.

2.23. Работа через NAT

Использование шлюзов с трансляцией сетевых адресов (NAT) является спорным вопросом. В этом параграфе кратко описаны такие шлюзы и их действия по отношению к трафику IKE. Многие враждебно относятся к NAT и считают, что не следует разрабатывать протоколы для улучшения работы через системы трансляции адресов. IKEv2 задаёт некоторые не вполне очевидные правила обработки для улучшения работы через NAT.

Основной причиной использования NAT является нехватка адресов IPv4. Узлы IP, находящиеся за шлюзами NAT используют адреса IP, которые не являются уникальными в глобальном масштабе и могут совпадать с адресами, которые применяются за другими шлюзами NAT. В общем случае узлы, расположенные за NAT, могут взаимодействовать с другими узлами за тем же шлюзом NAT и узлами с уникальными в глобальном масштабе адресами, не не с узлами, расположенными за другим шлюзом NAT. Из этого правила есть ряд исключений. Когда узлы, расположенные за NAT, соединяются с узлами в реальной сети Internet, шлюз NAT «преобразует» (транслирует) IP-адрес отправителя, меняя его на адрес, который будет маршрутизироваться обратно на этот шлюз. Полученные из Internet сообщения «транслируются» шлюзом с заменой адреса получателя на внутренний адрес соответствующего конечного узла.

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

Организация соединений IPsec через NAT вызывает определённые проблемы. Если соединение работает в транспортном режиме, изменение адресов IP в пакетах будет приводить к изменению контрольных сумм, которые NAT не сможет скорректировать, поскольку они криптографически защищены. Даже в туннельном режиме возникают проблемы с маршрутизацией, поскольку прозрачная трансляция адресов в пакетах AH и ESP требует реализации в NAT специальной логики, которая по своей природе эвристична и ненадёжна. По этим причинам IKEv2 использует инкапсуляцию пакетов IKE и ESP в UDP. Такой вариант слегка снижает эффективность, но проще для обработки в NAT. Кроме того, межсетевые экраны могут быть настроены на передачу трафика IPsec, инкапсулированного в UDP, но при этом блокировать ESP/AH и наоборот.

NAT обычно используется для трансляции портов TCP и UDP, наряду с адресами, и использования номеров портов из входящих пакетов для принятия решения об адресе локального узла, которому адресован пакет. По этой причине, хотя пакеты IKE должны отправляться через порт UDP с номером 500, необходимо принимать пакеты, исходящие из любого порта и отклики должны направляться в порт, из которого был получен запрос. Эти требования обусловлены тем, что номера портов могут меняться при прохождении пакетов через NAT. Аналогично, адреса IP конечных точек IKE обычно не включаются в элементы данных IKE, поскольку данные криптографически защищены и не могут прозрачно изменяться устройствами NAT.

Порт 4500 зарезервирован для инкапсуляции ESP и IKE в UDP. При работе через NAT в общем случае лучше передавать пакеты IKE через порт 4500, поскольку некоторые старые реализации NAT обрабатывают трафик IKE через порт 500 некорректно, пытаясь организовать прозрачное соединение IPsec между между конечными точками, которые сами по себе не поддерживают работу через NAT. Такие реализации NAT могут конфликтовать с прямым прохождением через NAT, описанным в этом документе, поэтому конечная точка IPsec, которая обнаружит NAT между собой и своим корреспондентом, должна передавать весь последующий трафик через порт 4500, который NAT не следует обрабатывать специальным способом (как это может происходить для порта 500).

Ниже перечислены специфические требования для прохождения через NAT [RFC3715]. Поддержка работы через NAT является необязательной. Приведённые в этом параграфе требования типа «должно» относятся только к реализациям, поддерживающим работу через NAT.

IKE должен прослушивать порты 4500 и 500. IKE должен отвечать по адресам IP и портам, с которых были приняты пакеты.

Как инициатор, так и ответчик IKE должны включать в свои пакеты IKE_SA_INIT элементы данных Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти элементы могут использоваться для детектирования наличия NAT между хостами и определения, какой из хостов находится за NAT. Эти элементы располагаются в пакетах IKE_SA_INIT после элементов Ni и Nr (перед необязательным элементом CERTREQ).

Если ни один из полученных элементов NAT_DETECTION_SOURCE_IP не соответствует хэшу IP-адреса и порта отправителя в заголовке IP содержащего элемент пакета, это означает, что другая сторона расположена за NAT (где-то на пути доставки адрес отправителя исходного пакета заменён на адрес устройства NAT). В таких случаях данной стороне следует разрешить динамическое обновление IP-адреса другой стороны, как описано ниже.

Если полученный элемент данных NAT_DETECTION_DESTINATION_IP не соответствует хэшу IP-адреса и номера порта получателя из заголовка IP пакета, содержащего элемент данных, это означает, что другая сторона расположена за NAT. В этом случае локальной стороне следует начать передачу пакетов keepalive, как описано в [Hutt05].

Инициатор IKE должен проверить наличие этих элементов данных и при несоответствии адресам во внешнем пакете должен туннелировать все будущие пакеты IKE и ESP, связанные с данной IKE_SA через порт UDP 4500.

При туннелировании пакетов IKE через порт UDP 4500 заголовок IKE имеет четыре октета нулей, следующих сразу после заголовка UDP. При туннелировании пакетов ESP через порт UDP 4500 заголовок ESP следует сразу после заголовка UDP. Поскольку первые четыре байта заголовка ESP содержат значение SPI, которое не может быть нулевым, это позволяет всегда легко различать сообщения ESP и IKE.

Исходные IP-адреса отправителя и получателя, которые нужны в транспортном режиме для расчёта контрольной суммы пакетов TCP и UDP (см. [Hutt05]), извлекаются из селекторов трафика, связанных с этим обменом. При работе через NAT селекторы трафика должны содержать в точности один адрес IP, который используется в качестве исходного адреса IP.

В некоторых случаях устройство NAT может удалить отображения, которые продолжают использоваться (например, интервал keepalive слишком велик или устройство NAT перезагружено). Для восстановления в таких случаях хостам, которые не расположены за NAT, следует передавать все пакеты (включая повторные) в адрес IP и порт из последнего корректно аутентифицированного пакета от другой стороны (т. е., динамически обновлять адрес). Расположенному за NAT хосту не следует делать так, поскольку это будет открывать возможность организации DoS-атак. Любой аутентифицированный пакет IKE или ESP, инкапсулированный в UDP, можно использовать для детектирования смены IP-адреса и номера порта. Отметим, что похожие, но, возможно, не совсем идентичные, действия требуется выполнять при работе IKE через Mobile IP, но этот вопрос выходит за пределы данного документа.

2.24. Явные уведомления о перегрузке (ECN)

При развёртывании туннелей IPsec в соответствии с исходной спецификацией [RFC2401], использование ECN во внешних заголовках IP было, по сути, невозможно, поскольку при декапсуляции туннеля индикаторы перегрузки ECN, появившиеся в сети, отбрасывались. Поддержка ECN для туннелей IPsec на базе IKEv1 требует множества режимов работы и согласований (см. [RFC3168]). IKEv2 упрощает ситуацию, вводя требование возможности использования ECN во внешних заголовках IP для всех IPsec SA в туннельном режиме, создаваемых IKEv2. В частности, точки инкапсуляции и декапсуляции туннельных SA, создаваемых IKEv2, должны поддерживать опцию полной функциональности ECN для туннелей, заданную в [RFC3168], а также должны реализовать инкапсуляцию и декапсуляцию в соответствии с [RFC4301] для предотвращения отбрасывания индикации перегрузки ECN.

3. Форматы заголовков и данных

3.1. Заголовок IKE

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Initiator's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Responder's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                          Message ID                           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                            Length                             !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат заголовка IKE.

Сообщения IKE используют протокол UDP через порты 500 и/или 4500, передаётся по одному сообщению IKE в дейтаграмме UDP. Информация от начала пакета до завершения заголовка UDP большей частью игнорируется, исключения составляют адреса IP и номера портов UDP в заголовках, которые сохраняются и используются для передачи ответных пакетов. При передаче через порт UDP 500 сообщение IKE начинается непосредственно после заголовка UDP. При передаче через порт UDP 4500 перед сообщением IKE помещается четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKE и не учитываются в размерах и контрольных суммах IKE. Каждое сообщение IKE начинается с заголовка IKE, обозначаемого в данном документе HDR. После заголовка следует один или множество элементов данных IKE, каждый из которых идентифицируется полем Next Payload в предыдущем элементе данных. Элементы данных обрабатываются в порядке их следования в сообщении IKE путём вызова соответствующей процедуры, согласно значению поля Next Payload в заголовке IKE, потом согласно значению Next Payload в первом элементе данных IKE и так далее, пока в поле Next Payload не будет обнаружено нулевое значение, показывающее отсутствие следующего элемента данных. При обнаружении элемента данных типа Encrypted этот элемент дешифруется и результат расшифровки разбирается, как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете и включать в зашифрованные элементы другие элементы типа Encrypted недопустимо.

Значение Recipient SPI в заголовке идентифицирует экземпляр защищённой связи IKE. Следовательно, один экземпляр IKE может мультиплексировать различные сессии с множеством партнёров.

Многооктетные поля, представляющие собой целые числа используют сетевой порядок байтов (или big endian — старший байт сначала).

Рисунок 4 показывает формат заголовка IKE.

• Initiator’s SPI (8 октетов) — значение, выбранное инициатором для уникальной аутентификации защищённой связи IKE. Нулевое значение недопустимо.

• Responder’s SPI (8 октетов) — значение, выбранное ответчиком для уникальной аутентификации защищённой связи IKE. Это значение должно быть нулевым в первом сообщении начального обмена IKE (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений нулевое значение недопустимо.

• Next Payload (1 октет) — показывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.

• Major Version (4 бита) — задаёт старшую часть номера версии используемого протокола IKE. Реализации на основе данной версии IKE, должны устанавливать Major Version=2. Реализации, основанные на предыдущих версиях IKE и ISAKMP, должны устанавливать Major Version=1. Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим 2.

• Minor Version (4 бита) — задаёт младшую часть номера версии IKE. Реализации на основе этого документа должны устанавливать Minor Version = 0 и игнорировать младшую часть номера в принимаемых сообщениях.

• Exchange Type (1 октет) — показывает тип обмена, который будет использоваться. Тип ограничивает набор элементов данных в каждом сообщении и порядок сообщений в обмене. Типы показаны в таблице.

  Тип обмена	Значение
  Резерв	0-33
  IKE_SA_INIT	34
  IKE_AUTH	35
  CREATE_CHILD_SA	36
  INFORMATIONAL	37
  Резерв IANA	38-239
  Резерв для частного использования	240-255

• Flags (1 октет) — показывает специфические опции, установленные для сообщения. Наличие опции указывается установкой соответствующего флага. Биты флагов начинаются с младшего, т. е. Бит 0 является младшим битом октета Flags. В приведённом ниже описании термин «установлен» означает значение бита 1, а термин «сброшен» — значение 0.