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

RFC 5737 IPv4 Address Blocks Reserved for Documentation

Опубликовано 15.01.2010 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                      J. Arkko
Request for Comments: 5737                                  Ericsson
Updates: 1166                                              M. Cotton
Category: Informational                                    L. Vegoda
ISSN: 2070-1721                                                ICANN
                                                        January 2010

Блок адресов IPv4, зарезервированных для документации

IPv4 Address Blocks Reserved for Documentation

PDF

Аннотация

Три блока индивидуальных (unicast) адресов IPv4 зарезервированы для использования в качестве примеров в спецификациях и других документах. В данном документе описано использование этих блоков.

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

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF¹ и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG². Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc5737.

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

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

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

В [RFC1166] зарезервирован первый из трех адресных блоков — 192.0.2.0/24. Два других блока были выделены недавно, прежде всего для упрощения подготовки примеров, включающих адресацию для множества сетей.

Прочие пространства идентификаторов для документации были определены IETF и включают префикс IPv6 для документации [RFC3849] и примеры доменных имен [RFC2606]. В документации могут также использоваться диапазоны адресов, определенные в [RFC1918].

2. Уровни требований

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

3. Блоки адресов для документации

Блоки адресов 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2) и 203.0.113.0/24 (TEST-NET-3) предназначены для использования в документации.

4. Влияние на работу

Адреса из блоков TEST-NET-1, TEST-NET-2 и TEST-NET-3 не следует применять в публичной сети Internet. Эти адреса могут использоваться без какой-либо координации с IANA или регистраторами Internet [RFC2050]. Сетевым операторам следует добавить эти блоки адресов в число немаршрутизируемых, а при использовании пакетных фильтров следует добавить эти адреса в списки фильтрации.

Блоки адресов не предназначены для локального использования и фильтры могут применяться как в локальном, так и в публичном контексте.

5. Статус блока 128.66.0.0/16

Отметим, что в прошлом для примеров иногда использовался блок адресов 128.66.0.0/16. Однако этот блок исключен из списка префиксов специального назначения [RFC3330] и, следовательно, больше не является зарезервированным для таких целей. При обычном использовании данного блока следует соблюдать осторожность.

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

Этот документ не оказывает влияния на безопасность.

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

Агентство IANA зафиксировало выделение трех описанных здесь блоков адресов IPv4 в реестре адресов. Эти адреса не выделены кому-либо конкретно.

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

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

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

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

[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, «Internet numbers», RFC 1166, July 1990.

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

[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, «INTERNET REGISTRY IP ALLOCATION GUIDELINES», BCP 12, RFC 2050, November 1996.

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

[RFC3330] IANA, «Special-Use IPv4 Addresses», RFC 3330 ⁴, September 2002.

[RFC3849] Huston, G., Lord, A., and P. Smith, «IPv6 Address Prefix Reserved for Documentation», RFC 3849, July 2004.

Приложение A. Благодарности

Авторы хотят выразить свою признательность регистратору APNIC, номинировавшему блоки 198.51.100.0/24 и 203.0.113.0/24 для использования в документации. Авторы также отмечают с благодарностью, что этот документ наследует материалы из [RFC3849].

Авторы благодарны Geoff Huston, Peter Koch, Ulf Olsson, John Klensin и другим людям за интересные дискуссии по теме.

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

Jari Arkko

Ericsson

Jorvas 02420

Finland

EMail: jari.arkko@piuha.net

Michelle Cotton

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey 90292

United States of America

Phone: +1-310-823-9358

EMail: michelle.cotton@icann.org

URI: http://www.iana.org/

Leo Vegoda

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey 90292

United States of America

Phone: +1-310-823-9358

EMail: leo.vegoda@icann.org

URI: http://www.iana.org/

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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

4В настоящее время этот документ утратил силу и заменен RFC 5735. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 5736 IANA IPv4 Special Purpose Address Registry

Опубликовано 15.01.2010 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                     G. Huston
Request for Comments: 5736                                     APNIC
Category: Informational                                    M. Cotton
ISSN: 2070-1721                                            L. Vegoda
                                                               ICANN
                                                        January 2010

Реестр IANA для адресов IPv4 специального назначения

IANA IPv4 Special Purpose Address Registry

PDF

Аннотация

В этом документе содержатся рекомендации агентству IANA по созданию и поддержке реестра адресов IPv4 специального назначения (IANA IPv4 Special Purpose Address Registry).

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

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc5736.

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

1. Введение

В этом документе содержатся рекомендации агентству [IANA] по созданию и поддержке реестра адресов IPv4 специального назначения (IANA IPv4 Special Purpose Address Registry). Реестр будет служить для записи выделенных IETF протокольных значений, начиная с блока 192.0.0.0/24 и продолжая новыми адресными префиксами, которые будут распределены впоследствии, как описано в разделе 3.

2. Блок адресов специального назначения IANA IPv4

В [RFC5735] указано выделение адресного префикса IPv4 агентством IANA для распределения протоколов IETF.

192.0.0.0/24 — этот блок зарезервирован IETF для протоколов.

Это выделение адресов агентству IANA предназначено для поддержки выделения протоколов IETF. Более общее рассмотрение роли IANA в части распределения адресов приведено в документе [RFC2860]:

4.3. […] Отметим, что […] (b) выделение специализированных адресных блоков (таких, как блоки для групповой или индивидуальной адресации), (c) экспериментальное выделение не относятся к вопросам политики и продолжают оставаться субъектом положений данного раздела 4 (в данном MOU термин «присваивание» включает и выделение).

Ссылка на раздел 4 приведена для указания на общую техническую роль IANA, как указано в [RFC2860]:

4.1. Агентство IANA будет выделять и регистрировать параметры протоколов Internet только в соответствии с критериями и процедурами, заданными в документах RFC, включая проекты — Proposed, Draft, законченные документы — Internet Standard и BCP³, а также любые другие RFC, где указано присваивание через IANA.

Этот документ служит руководством для IANA по выделению блока адресов специального назначения в соответствии с [RFC2860].

Этот документ запрашивает у IANA создание реестра адресов специального назначения IPv4 Special Purpose Address Registry для управления выделенными IANA адресными блоками. Регистрация адресов специального назначения будет осуществляться из этого реестра для присваивания протоколов IETF и иных специальных целей, как указано в рассмотренных IESG документах RFC в соответствии с условиями, приведенными в параграфе 4.1 документа [RFC2860].

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

IANA поддерживает реестр «IANA IPv4 Special Purpose Address Registry», содержащий текущее выделение блока адресов из поддерживаемого IANA пула адресов IPv4 специального назначения.

Эти рекомендации относятся к поддержке адресного пула, используемого IETF для присвоения протоколов, как указано в [RFC5735], а именно — блока 192.0.0.0/24. В соответствии с правилами, указанными в [RFC5226], дальнейшее выделение адресного пространства агентству IANA для последующего выделения адресных префиксов с указанными здесь целями следует выполнять только по процедуре IETF Review.

IANA может выделить адреса специального назначения для тестов и экспериментов, инициируемых IETF, или для специализированного применения указанного адресного блока в контексте (например, anycast), связанном с проектом стандартного протокола Internet. Все такие назначения адресов должны документироваться в разделе «Согласование с IANA (IANA Considerations), рассматриваемого IESG документа RFC.

Реестр IANA IPv4 Special Purpose Address Registry включает для текущего назначения адресов, выполненного IANA:

префикс назначенных адресов;
указание RFC, в котором запрошено у IANA назначение адресов;
дату назначения адресов;
дату прекращения использования (если адреса назначаются на ограниченный срок);
назначение выделенных адресов (например, эксперименты с unicast или протоколом anycast);
для экспериментальных приложений и в других случаях, когда это применимо, в реестре указывается идентификация объекта и контактные данные, связанные с назначением адресов;
в реестре для каждого выделения будет указываться также область маршрутизации адреса (локальная, приватная или глобальная маршрутизация);
в качестве даты указывается дата соответствующего действия IANA (например, дата выделения).

В данном реестре IANA в качестве комментария общего назначения указывается, что префиксы, перечисленные в реестре адресов специального назначения (IPv4 Special Purpose Address Registry) не обязательно будут маршрутизируемыми в любом конкретном приватном или глобальном контексте.

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

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

Безопасность системы маршрутизации Internet базируется на способности обеспечить контроль за уникальностью блоков адресов. Защитные меры основываются на контроле принадлежности блока адресов к известному выделенному блоку и наличия достоверной и уникальной ссылки на этот блок в адресном реестре IANA.

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

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

Этот документ основан на документе [RFC4773], подготовленном с участием Leslie Daigle, Brian Haberman, Bob Hinden, David Kessens, Kurt Lindqvist, Thomas Narten и Paul Wilson. Хотя не все из этих людей явно принимали явное участие в подготовке данного документа, благодарим их за участие в работе над исходным документом.

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

[IANA] IANA, «IANA Matrix for Protocol Parameter Assignment/Registration Procedures», <http://www.iana.org/numbers.html>.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860, June 2000.

[RFC4773] Huston, G., «Administration of the IANA Special Purpose IPv6 Address Block», RFC 4773, December 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5735] Cotton, M. and L. Vegoda, «Special Use IPv4 Addresses», BCP 153, RFC 5735, January 2010.

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

Geoff Huston

Asia Pacific Network Information Centre

PO Box 2131

Milton, QLD 4064

Australia

Phone: +61-7-3858-3100

EMail: gih@apnic.net

URI: http://www.apnic.net/

Michelle Cotton

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292-6601

USA

Phone: +1-310-823-9358

EMail: michelle.cotton@icann.org

URI: http://www.iana.org/

Leo Vegoda

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292-6601

USA

Phone: +1-310-823-9358

EMail: leo.vegoda@icann.org

URI: http://www.iana.org/

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Best Current Practice.

Рубрика: RFC | Оставить комментарий

RFC 5735 Special Use IPv4 Addresses

Опубликовано 15.01.2010 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                     M. Cotton
Request for Comments: 5735                                 L. Vegoda
BCP: 153                                                       ICANN
Obsoletes: 3330                                         January 2010
Category: Best Current Practice
ISSN: 2070-1721

Адреса IPv4 специального назначения

Special Use IPv4 Addresses

PDF

Аннотация

Этот документ служит заменой RFC 3330 и описывает блоки адресов IPv4 специального назначения, выделенные агентством IANA¹. Документ не рассматривает адресное пространство IPv4, выделяемое операторам и пользователям через региональные агентства RIR², а также адресное пространство IPv4, распределенное IANA до образования агентств RIR. Документ также не рассматривает распределения адресного пространства IPv6 и номеров автономных систем.

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

Этот документ относится к категории обмена опытом (Internet BCP³).

Документ является результатом работы IETF⁴ и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG⁵. Дополнительную информацию о серии документов BCP можно найти в разделе 2 документа RFC 5741.

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc5735.

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

1. Введение

В процессе развития сети Internet было организовано центральное агентство IANA, ответственное за распределение различных идентификаторов, требуемых для работы Internet [RFC1174]. В части адресного пространства IPv4 агентство IANA выделяет блоки адресов региональным агентствам (RIR) в соответствии с их потребностями. Региональные агентства отвечают за распределение полученных блоков адресов между операторами и пользователями в рамках своего региона.

Агентство IANA было на постоянной основе назначено IETF выполнять распределение в поддержку процессов стандартизации Internet [RFC2860]. Сам процесс распределения описан в разделе 4 указанного документа.

Небольшие фрагменты адресного пространства IPv4 были выделены IANA для использования в качестве адресов специального назначения. Факты такого выделения адресного пространства зафиксированы в различных RFC и других документах. Задачей этого документа является сбор воедино этих разрозненных распределений и составление единого списка адресов IPv4 специального назначения.

Этот документ является пересмотром RFC 3330 [RFC3330], который утрачивает силу; основной целью пересмотра является учет изменений в списке выделенных адресов IPv4 специального назначения, которые произошли с момента публикации RFC 3330⁶. Аналогичные задачи для адресов специального назначения IPv6 решены в [RFC5156].

2. Уровни требований

3. Блоки адресов специального назначения

0.0.0.0/8 — адреса этого блока указывают хосты-отправители из данной сети (this network). Адрес 0.0.0.0/32 может использоваться в качестве адреса отправителя «данный хост данной сети» (this host on this network), а прочие адреса из блока 0.0.0.0/8 могут указывать на конкретные хосты данной сети ([RFC1122], параграф 3.2.1.3).

10.0.0.0/8 — этот блок предназначен для использования в приватных сетях. Его применение документировано в [RFC1918], где указано, что адреса из данного блока не являются легитимными в публичной сети Internet. Этот блок адресов может использоваться без согласования с IANA или регистраторами Internet.

127.0.0.0/8 — этот блок предназначен для использования в качестве loopback-адресов хостов Internet. Дейтаграмма, переданная протоколом вышележащего уровня по адресу из этого блока, не покинет этот хост (вернется ему же). Изначально этот процесс был реализован с использованием одного адреса 127.0.0.1/32. Как указано в [RFC1122] (параграф 3.2.1.3), адреса из блока 127.0.0.0/8 не могут легитимно появляться где-либо в сети.

169.254.0.0/16 — этот блок используется для «локального» канала (link local). Как указано в [RFC3927], адреса из этого блока выделяются для связи между хостами, подключенными к одному каналу. Хосты получают такие адреса через процедуры автоматического конфигурирования, если не удается обнаружить сервер DHCP⁷.

172.16.0.0/12 — этот блок предназначен для использования в приватных сетях. Его применение документировано в [RFC1918], где указано, что адреса из данного блока не являются легитимными в публичной сети Internet. Этот блок адресов может использоваться без согласования с IANA или регистраторами Internet.

192.0.0.0/24 — этот блок зарезервирован IETF для протоколов. На момент подготовки данного документа каких-либо адресов из этого блока не было распределено. Процедура выделения адресов из данного блока описана в [RFC5736].

192.0.2.0/24 — этот блок выделен, как тестовая сеть TEST-NET-1 для использования в документации и примерах кода. Зачастую этот блок используется вместе с именами типа example.com или example.net в документации на оборудование и протоколы. Как указано в [RFC5737], адреса из этого блока не являются легитимными для публичной сети Internet и могут использоваться без согласования с IANA или регистраторами Internet (см. [RFC1166]).

192.88.99.0/24 — этот блок выделен для использования в качестве индивидуальных адресов при трансляции 6to4 [RFC3068]. В отличии от описанных ранее блоков пакеты, адресованные в этот блок, могут появляться в публичной сети Internet. В параграфе 7 документа [RFC3068] описано практическое использование этих адресов с учетом предотвращения злоупотреблений адресами из данного блока в протоколах маршрутизации.

192.168.0.0/16 — этот блок предназначен для использования в приватных сетях. Его применение документировано в [RFC1918], где указано, что адреса из данного блока не являются легитимными в публичной сети Internet. Этот блок адресов может использоваться без согласования с IANA или регистраторами Internet.

198.18.0.0/15 — этот блок выделен для использования при тестировании производительности устройств межсетевого взаимодействия. В [RFC2544] указано, что этот блок выделен с целью минимизации вероятности возникновения конфликтов при тестировании, когда проверяемое устройство может оказаться подключенным к сети Internet. Пакеты с адресами отправителя из этого блока не пересылаются через Internet.

198.51.100.0/24 — этот блок выделен, как тестовая сеть TEST-NET-2 для использования в документации и примерах кода. Зачастую этот блок используется вместе с именами типа example.com или example.net в документации на оборудование и протоколы. Как указано в [RFC5737], адреса из этого блока не являются легитимными для публичной сети Internet и могут использоваться без согласования с IANA или регистраторами Internet.

203.0.113.0/24 — этот блок выделен, как тестовая сеть TEST-NET-3 для использования в документации и примерах кода. Зачастую этот блок используется вместе с именами типа example.com или example.net в документации на оборудование и протоколы. Как указано в [RFC5737], адреса из этого блока не являются легитимными для публичной сети Internet и могут использоваться без согласования с IANA или регистраторами Internet.

224.0.0.0/4 — этот блок, известный ранее, как пространство адресов класса D, был выделен для использования в качестве групповых (multicast) адресов IPv4. Рекомендации IANA по использованию адресов из этого блока даны в [RFC3171].

240.0.0.0/4 — этот блок, известный ранее, как пространство адресов класса E, зарезервирован для использования в будущем (см. параграф 4 [RFC1112]).

Единственным исключением из этого блока является адрес «ограниченного широковещания» (limited broadcast) 255.255.255.255. Как указано в [RFC0919] и [RFC0922], пакеты с таким адресом получателя не пересылаются на уровне IP.

4. Таблица выделенных блоков

Блок адресов	Назначение	Документ
0.0.0.0/8	Данная сеть	RFC 1122, параграф 3.2.1.3
10.0.0.0/8	Использование в приватных сетях	RFC 1918
127.0.0.0/8	Loopback-интерфейс	RFC 1122, параграф 3.2.1.3
169.254.0.0/16	Локальное соединение (Link Local)	RFC 3927
172.16.0.0/12	Использование в приватных сетях	RFC 1918
192.0.0.0/24	Резерв IETF для протоколов	RFC 5736
192.0.2.0/24	Тестовая сеть TEST-NET-1	RFC 5737
192.88.99.0/24	Индивидуальный адрес для трансляции 6to4	RFC 3068
192.168.0.0/16	Использование в приватных сетях	RFC 1918
198.18.0.0/15	Тестирование производительности устройств межсетевого взаимодействия	RFC 2544
198.51.100.0/24	Тестовая сеть TEST-NET-2	RFC 5737
203.0.113.0/24	Тестовая сеть TEST-NET-3	RFC 5737
224.0.0.0/4	Групповая адресация	RFC 3171
240.0.0.0/4	Резерв для использования в будущем	RFC 1112, раздел 4
255.255.255.255/32		RFC 919, раздел 7, RFC 922, раздел 7

5. Выделение блоков адресов IPv4 для обычного использования

Агентство IANA отвечает за распределение параметров протоколов, используемых в сети Internet, в соответствии с требованиями документа Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority [RFC2860]. Наряду с прочим, [RFC2860] требует, чтобы протокольные параметры выделялись в соответствии с критериями и процедурами, указанными в документах серии RFC, включая проекты — Proposed, Draft и завершенные документы Internet Standards, Best Current Practice, а также любых других RFC, связанных с распределением через агентство IANA.

С пространствами доменных имен и адресов IP связаны вопросы политики (правил), наряду с техническими вопросами, поэтому требования [RFC2860] в общем случае неприменимы к этим пространствам. Тем не менее, IANA отвечает за распределение адресов IPv4 в соответствии с процессом стандартизации Internet⁸. Когда часть пространства адресов IPv4 запрашивается тем или иным RFC, в соответствии с [RFC5226] требуется описание технических требований (например, размер блока, длина префикса). Непосредственно перед публикацией RFC агентство IANA, консультируясь с региональными регистраторами (RIR), выделяет требуемые адреса и уведомляет редактора документа (RFC Editor) о публикации RFC.

В соответствии с требованиями [RFC2860], IANA также распределяет адреса IPv4 для экспериментов, консультируясь с RIR.

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

В этом документе описана прошлая и современная практика IANA в части выделения адресов и не запрашивается какого-либо нового выделения пространства от IANA.

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

Практическое выделение адресов IPv4 специального назначения, каталогизированное в этом документе, не порождает непосредственно проблем безопасности. Тем не менее, в сети Internet нет средств защиты от злоупотреблений такими адресами. Например, если вы предполагаете, что все пакеты из вашего приватного адресного пространства (скажем, 10.0.0.0/8 или 169.254.0.0/16) исходят из вашей сети, все маршрутизаторы на периметре сети должны фильтровать пакеты от внешних отправителей с такими адресами. Возможна организация атак, основанных на неожиданном использовании таких адресов.

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

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

Множество людей предоставило свои отклики на предварительные версии этого документа. Авторы особо хотят отметить и поблагодарить Scott Bradner, Randy Bush, Harald Alvestrand, Peter Koch, Alfred Hoenes и Jari Arkko за их конструктивные замечания и комментарии. Отдельная благодарность от авторов агентству APNIC, включившему в документ блоки адресов 198.51.100.0/24 и 203.0.113.0/24.

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

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

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

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

[RFC0919] Mogul, J., «Broadcasting Internet Datagrams», STD 5, RFC 919, October 1984.

[RFC0922] Mogul, J., «Broadcasting Internet datagrams in the presence of subnets», STD 5, RFC 922, October 1984.

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

[RFC1122] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, «Internet numbers», RFC 1166, July 1990.

[RFC1174] Cerf, V., «IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet «connected» status», RFC 1174, August 1990.

[RFC1700] Reynolds, J. and J. Postel, «Assigned Numbers», RFC 1700¹⁰, October 1994.

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

[RFC2544] Bradner, S. and J. McQuaid, «Benchmarking Methodology for Network Interconnect Devices», RFC 2544, March 1999.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860, June 2000.

[RFC3068] Huitema, C., «An Anycast Prefix for 6to4 Relay Routers», RFC 3068, June 2001.

[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, «IANA Guidelines for IPv4 Multicast Address Assignments», BCP 51, RFC 3171, August 2001.

[RFC3330] IANA, «Special-Use IPv4 Addresses», RFC 3330, September 2002.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, «Dynamic Configuration of IPv4 Link-Local Addresses», RFC 3927, May 2005.

[RFC5156] Blanchet, M., «Special-Use IPv6 Addresses», RFC 5156, April 2008.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5736] Huston, G., Cotton, M., and L. Vegoda, «IANA IPv4 Special Purpose Address Registry», RFC 5736, January 2010.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, January 2010.

Приложение A. Отличия от RFC 3330

Блоки адресов, которые были зарезервированы в RFC 3330 для специального применения, но перестали быть таковыми, исключены из разделов 4 и 5. В результате этого стали доступны следующие блоки:

14.0.0.0/8 больше не используется для распределения в международных системах передачи данных, как было указано ранее на стр. 181 [RFC1700]; в настоящее время этот блок доступен для распределения региональным агентствам RIR;
24.0.0.0/8 больше не принадлежит американскому агентству ARIN¹¹ (с 2001 года);
39.0.0.0/8 передан для обычного распределения региональным агентствам RIR в 2001 году;
128.0.0.0/16 больше не является резервным и предназначен для нормального распределения региональным агентствам RIR;
191.255.0.0/16 больше не является резервным и предназначен для нормального распределения региональным агентствам RIR;
198.51.100.0/24 выделен в качестве тестовой сети TEST-NET-2 для использования в документации и примерах кода;
203.0.113.0/24 выделен в качестве тестовой сети TEST-NET-3 для использования в документации и примерах кода;
223.255.255.0/24 больше не является резервным и предназначен для нормального распределения региональным агентствам RIR.

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

Michelle Cotton

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292

USA

Phone: +1-310-823-9358

EMail: michelle.cotton@icann.org

URI: http://www.iana.org/

Leo Vegoda

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292

USA

Phone: +1-310-823-9358

EMail: leo.vegoda@icann.org

URI: http://www.iana.org/

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

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

nmalykh@gmail.com

1Internet Assigned Numbers Authority.

2Regional Internet Registry.

3Best Current Practice.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6После публикации данного документа был выделен еще один блок адресов специального назначения, описанный в документе RFC 6598. Прим. перев.

7И адрес не задан статически в параметрах конфигурации хоста. Прим. перев.

8Internet Standards Process.

10В соответствии с RFC 3232 этот документ утратил силу. Реестры выделенных идентификаторов доступны по ссылкам на сайте IANA. Прим. перев.

11American Registry for Internet Numbers.

Рубрика: RFC | Оставить комментарий

RFC 5652 Cryptographic Message Syntax (CMS)

Опубликовано 22.09.2009 автором Nikolai Malykh

Network Working Group                                         R. Housley
Request for Comments: 5652                                Vigil Security
Obsoletes: 3852                                           September 2009
Category: Standards Track

Синтаксис криптографических сообщений (CMS)

Cryptographic Message Syntax (CMS)

PDF

Аннотация

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

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

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

Авторские права и лицензирование

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

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

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

CMS может поддерживать множество вариантов архитектуры основанного на сертификатах распространения ключей (таких, как архитектура, разработанная группой PKIX² [PROFILE]).

Значения CMS генерируются с применением нотации ASN.1 [X.208-88], использующей представление BER [X.209-88]. Значения обычно представляются в форме строк октетов. Хотя многие системы способны обеспечивать надежную передачу произвольных строк октетов, известно, что многие системы не обеспечивают этого. В этом документе не рассматриваются механизмы кодирования строк октетов для гарантированной передачи в подобных средах.

1.1. Развитие CMS

CMS происходит от PKCS #7 версии 1.5, документированной в RFC 2315 [PKCS#7]. PKCS #7 версии 1.5 была разработана без участия IETF и опубликована изначально как RSA Laboratories Technical Note в ноябре 1993 г. С этого момента ответственность за разработку и поддержку CMS перешла к IETF. В настоящее время несколько важных протоколов, стандартизируемых IETF, используют CMS.

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

1.1.1. Отличия от PKCS #7 версии 1.5

RFC 2630 [CMS1] содержал первую версию CMS, включенную в процесс стандартизации IETF. Везде, где это было возможно, обеспечивалась совместимость с PKCS #7 версии 1.5, однако были внесены изменения для согласования с переносом сертификата атрибутов версии 1 и поддержки независимого от алгоритма управления ключами. PKCS #7 версии 1.5 включена только для поддержки транспортировки ключей. В RFC 2630 добавлена поддержка согласования ключей и методы шифрования с использованием заранее распространенных симметричных ключей.

1.1.2. Отличия от RFC 2630

RFC 3369 [CMS2] отменяет действие RFC 2630 [CMS1] и RFC 3211 [PWRI]. Управление ключами на основе паролей включено в спецификацию CMS и задан механизм расширения для поддержки новых схем управления ключами без внесения изменений в CMS. Совместимость со старыми версиями RFC 2630 и RFC 3211 сохранена, однако добавлен перенос сертификатов атрибутов версии 2, а применение сертификатов версии 1 запрещено.

Подписи S/MIME³ v2 [MSG2], основанные на PKCS#7 версии 1.5, совместимы с подписями S/MIME v3 [MSG3] и S/MIME v3.1 [MSG3.1]. Однако возникают незначительные проблемы совместимости с подписями на основе PKCS #7 версии 1.5. Эти вопросы рассматриваются в параграфе 5.2.1. Проблемы сохранились и в текущей версии CMS.

Конкретные криптографические алгоритмы не рассматриваются в этом документе, но они рассмотрены в RFC 2630. Обсуждение конкретных криптографических алгоритмов вынесено в отдельный документ [CMSALG]. Такое разделение позволяет IETF независимо обновлять каждый документ. Эта спецификация не требует реализации каких-либо конкретных алгоритмов. Вместо этого в CMS предполагается, что протоколы будут выбирать подходящие алгоритмы для работы в среде протокола. Эти алгоритмы могут выбираться из [CMSALG] или иных документов.

1.1.3. Отличия от RFC 3369

RFC 3852 [CMS3] отменяет действие RFC 3369 [CMS2]. Как отмечено в предыдущем параграфе, в RFC 3369 добавлен механизм расширения для поддержки схем управления ключами без внесения дополнительных изменений в CMS. RFC 3852 добавляет похожий механизм расширения для поддержки дополнительных форматов сертификатов и информации о статусе отзыва без внесения изменений в CMS. Эти расширения документированы в параграфах 10.2.1 и 10.2.2. Сохранена совместимость с предыдущими версиями CMS.

Использование номеров версий описано в параграфе 1.3.

С момента публикации RFC 3369 в документе был обнаружен ряд ошибок, указанных на сайте RFC Editor. В данном документе эти ошибки исправлены.

Прояснен текст параграфа 11.4, описывающего не подписанный атрибут countersignature. Будем надеяться, что новый текст более четко описывает часть подписи SignerInfo, которая покрывается countersignature.

1.1.4. Отличия от RFC 3852

Этот документ отменяет действие RFC 3852 [CMS3]. Основной причиной появления этого документа является продвижение CMS по пути стандартизации.

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

С момента публикации RFC 3852 в документе был обнаружен ряд ошибок, указанных на сайте RFC Editor. В данном документе эти ошибки исправлены.

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

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

1.3. Номера версий

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

Большинство исходных номеров версий было выделено в рамках PKCS #7 версии 1.5. Другие значения выделялись при определении соответствующих структур данных. При обновлении структур выделялось большее значение номера версии. Однако для обеспечения взаимодействия старший номер версии меняется лишь в случаях изменения синтаксиса. Т. е., выбирается наименьший номер версии, которая поддерживает используемый синтаксис.

2. Общий обзор

Синтаксис CMS является достаточно общим для поддержки разных типов содержимого сообщений. В этом документе для защиты содержимого определяется ContentInfo. Метод ContentInfo инкапсулирует один указанный тип содержимого, а этот тип может поддерживать дополнительную инкапсуляцию. В документе определены 6 типов содержимого — данные (data), подписанные данные (signed-data), вложенные данные (enveloped-data), данные с цифровой подписью (digested-data), шифрованные данные (encrypted-data) и аутентифицированные данные (authenticated-data). Дополнительные типы содержимого могут быть определены в других документах.

Реализация, соответствующая требованиям этого документа, должна реализовать ContentInfo, а также должна поддерживать типы data, signed-data и enveloped-data. Могут поддерживаться также другие типы содержимого.

В качестве общего подхода для каждого типа содержимого возможна однопроходная обработка и использованием представления BER⁴ с неопределенным размером. Однопроходные операции особенно хороши для содержимого большого размера, сохраняемого на лентах или получаемого от других процессов через «конвейер» (pipe). Однако такие операции имеют один существенный недостаток — для них сложно выполнить представление с использованием правил DER⁵ [X.509-88] в один проход, поскольку размеры различных компонент заранее могут быть не известны. Однако подписанные атрибуты в типе signed-data (подписанные данные) и аутентифицированные атрибуты в типе authenticated-data требуется передавать в формате DER, чтобы получатели могли проверить наличие в содержимом нераспознанных атрибутов. Из числа используемых в CMS атрибутов представление DER требуется только для подписанных и аутентифицированных атрибутов.

3. Базовый синтаксис

Приведенный ниже идентификатор указывает тип информации в содержимом.

      id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

CMS связывает идентификатор типа содержимого с самим содержимым. Синтаксис должен использовать тип ContentInfo в представлении ASN.1.

      ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

      ContentType ::= OBJECT IDENTIFIER

Смысл полей ContentInfo разъяснен ниже.

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

content представляет собой связанное с объектом содержимое. Тип содержимого может быть уникально определен из contentType. Типы содержимого для data, signed-data, enveloped-data, digested-data, encrypted-data и authenticated-data определены в настоящем документе. При определении в других документах дополнительных типов содержимого определяемому типу ASN.1 не следует быть типом CHOICE.

4. Тип содержимого data

Ниже приведен идентификатор типа содержимого data (данные).

      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

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

S/MIME использует id-data для идентификации представленного в формате MIME содержимого. Использование этого идентификатора типа определено в RFC 2311 для S/MIME v2 [MSG2], RFC 2633 для S/MIME v3 [MSG3] и RFC 3851 для S/MIME v3.1 [MSG3.1].

Содержимое типа data обычно инкапсулируется в тип signed-data, enveloped-data, digested-data, encrypted-data или authenticated-data.

5. Тип содержимого Signed-data

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

Типовым применением типа signed-data являются данные с цифровой подписью содержимого типа data. Другим вариантом применения этого типа является распространение сертификатов и списков отзыва сертификатов (CRL⁶).

Процесс создания типа signed-data включает несколько этапов, перечисленных ниже.

Для каждого подписывающего лица рассчитывается значение цифровой подписи или хэш-сумма для содержимого с использованием специфического для данного подписывающего алгоритма. Если подписывается какая-либо информация кроме содержимого, создается цифровая подпись для содержимого и этой информации с использованием алгоритма подписывающего лица (см. параграф 5.4) и результат называется «отпечатком сообщения» (message digest).
Для каждого подписывающего отпечаток сообщения подписывается с использованием секретного ключа подписывающего лица.
Для каждого подписывающего лица значение подписи и другая специфическая для данного лица информация собираются в значение SignerInfo, как описано в параграфе 5.3. Сертификаты и списки CRL для каждого подписывающего, а также не соответствующие никому из подписавших собираются на этом этапе.
Алгоритмы расчета отпечатков для всех подписавших, а также значения SignerInfo для них собираются в значение SignedData, как описано в параграфе 5.1.

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

При наличии множества подписей подтверждение пригодности одной подписи, связанной с данным лицом, обычно трактуется, как приемлемая подпись этого лица. Однако в некоторых прикладных средах требуются иные правила. Когда простого соответствия идентификатора подписавшего не достаточно для подтверждения создания подписи именно этим лицом, спецификация приложения должна указать способ определения подписей, которые были созданы данным лицом. Множество подписей одного лица включается прежде всего для поддержки различных групп (сообществ) получателей. Например, тип signed-data может включать подписи, созданные с использованием алгоритма RSA и алгоритма ECDSA⁷. Это позволяет получателям проверить подпись с помощью одного или другого алгоритма.

Этот раздел поделен на 6 частей, описывающих типы верхнего уровня SignedData, EncapsulatedContentInfo, SignerInfo для подписавшего, а также расчет отпечатка сообщения, генерацию подписи и ее проверку.

5.1. Тип SignedData

Приведенный ниже идентификатор указывает содержимое типа signed-data.

      id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

Тип signed-data должен иметь форму ASN.1 SignedData

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

      SignerInfos ::= SET OF SignerInfo

Значение полей типа SignedData описаны ниже.

version указывает номер версии синтаксиса. Набор допустимых значений определяется полями certificates, eContentType и SignerInfo. Значение version должно присваиваться по следующему алгоритму:

         IF ((имеется поле certificates) AND
            (присутствуют какие-либо сертификаты типа other)) OR
            ((присутствует crls) AND
            (присутствуют любые crls типа other))
         THEN version ДОЛЖНО иметь значение 5
         ELSE
            IF (имеется поле certificates) AND
               (присутствуют любые сертификаты атрибутов версии 2)
            THEN version ДОЛЖНО иметь значение 4
            ELSE
               IF ((имеется поле certificates) AND
                  ( присутствуют любые атрибуты сертификатов версии 1)) OR
                  (все структуры SignerInfo имеют версию 3) OR
                  (encapContentInfo eContentType отличается от id-data)
               THEN version ДОЛЖНО иметь значение 3
               ELSE version ДОЛЖНО иметь значение 1

digestAlgorithms — набор идентификаторов алгоритмов расчета отпечатка сообщения, который может содержать любое (включая 0) число элементов. Каждый элемент определяет алгоритм создания отпечатка (вместе со связанными с ним параметрами), используемого кем-либо из подписавших. Набор содержит список алгоритмов, используемых всеми подписавшими, в произвольном порядке для реализации однопроходной проверки подписей. Разработчики могут отказаться от проверки подписей, использующих алгоритмы, не включенные в список. Процесс создания отпечатков сообщений описан в параграфе 5.4.

encapContentInfo — подписанное содержимое, состоящее из идентификатора типа и собственно содержимого. Подробное описание типа EncapsulatedContentInfo приведено в параграфе 5.2.

certificates — набор сертификатов, включающий множество сертификатов, достаточное для поддержки путей сертификации от признанного «корня» (root) или агентства верхнего уровня (top-level certification authority) ко всем подписавшим из поля signerInfos. Набор может содержать избыточные сертификаты, а также может содержать сертификаты для поддержки путей к двум и более независимым агентствам верхнего уровня. Число сертификатов может быть меньше необходимого, если предполагается наличие у получателей других способов получения необходимых сертификатов (например, из предыдущего набора сертификатов). Могут включаться сертификаты подписавших. Использование сертификатов атрибутов версии 1 строго запрещено.

crls — набор информации о статусе отзывов. Предполагается, что этих данных предназначено для проверки пригодности сертификатов, указанных в поле certificates, но такое соответствие не является обязательным. Списки CRL являются первичным источником информации о статусе отзыва сертификатов. Поле может содержать избыточное число CRL, но может включать и недостаточное для проверки число списков.

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

5.2. Тип EncapsulatedContentInfo

Тип EncapsulatedContentInfo имеет структуру

      EncapsulatedContentInfo ::= SEQUENCE {
        eContentType ContentType,
        eContent [0] EXPLICIT OCTET STRING OPTIONAL }

      ContentType ::= OBJECT IDENTIFIER

Поля EncapsulatedContentInfo описаны ниже.

eContentType — идентификатор объекта, уникально задающий тип содержимого.

eContent — собственно содержимое, передаваемое в виде строки октетов. Для eContent не требуется представление DER.

Поле eContent может отсутствовать в EncapsulatedContentInfo, что обеспечивает возможность создания «внешних подписей». В случае внешней подписи подписываемое содержимое отсутствует в EncapsulatedContentInfo, включаемом в тип signed-data. Если значение eContent отсутствует в EncapsulatedContentInfo, signatureValue рассчитывается и значение eContentType назначается как при наличии значения eContent.

В вырожденном случае отсутствия подписавших лиц значение EncapsulatedContentInfo не будет относиться к делу. В такой ситуации «подписываемый» тип содержимого в EncapsulatedContentInfo должен быть id-data (см. раздел 4), а поле содержимого в EncapsulatedContentInfo должно быть опущено.

5.2.1. Совместимость с PKCS #7

В этом параграфе приводится предупреждение для разработчиков, желающих поддерживать SignedData для типов данных CMS и PKCS #7 [PKCS#7] одновременно. Оба типа CMS и PKCS #7 указывают инкапсулированное содержимое с идентификатором объекта, но тип ASN.1 самого содержимого является переменным для PKCS #7 SignedData.

PKCS #7 определяет content как

      content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

CMS определяет eContent как

      eContent [0] EXPLICIT OCTET STRING OPTIONAL

Определение CMS значительно проще в использовании для большинства приложений и совместимо с обоими форматами S/MIME v2 и S/MIME v3. Подписанные сообщения S/MIME, использующие CMS и PKCS #7, совместимы, поскольку форматы подписанных сообщений заданы идентично в RFC 2311 для S/MIME v2 [MSG2], RFC 2633 для S/MIME v3 [MSG3] и RFC 3851 для S/MIME v3.1 [MSG3.1]. S/MIME v2 инкапсулирует содержимое MIME в тип Data (строка октетов — OCTET STRING), передаваемые в SignedData contentInfo любого поля, а S/MIME v3 передает содержимое MIME в строке октетов SignedData encapContentInfo eContent. Следовательно, в S/MIME v2, S/MIME v3 и S/MIME v3.1 содержимое MIME помещается в OCTET STRING и отпечаток сообщения рассчитывается для идентичных частей содержимого. Т. е., отпечаток сообщения рассчитывается по октетам OCTET STRING без учета октетов тегов и размера.

Между типами CMS и PKCS #7 для SignedData имеется несовместимость, когда инкапсулированное содержимое не форматировано с использованием типа Data. Например, когда подписанная с использованием RFC 2634 [ESS] информация инкапсулируется в тип CMS SignedData, последовательность Receipt SEQUENCE представляется строкой октетов SignedData encapContentInfo eContent, а отпечаток сообщения рассчитывается с использованием всей последовательности Receipt (включая октеты тега, размера и значения). Однако, если подписанное в соответствии с RFC 2634 содержимое инкапсулируется в тип PKCS #7 SignedData, последовательность Receipt представляется в формате DER [X.509-88] SignedData contentInfo любого поля (SEQUENCE не является OCTET STRING). Следовательно, отпечаток сообщения рассчитывается только для октетов последовательности Receipt.

Показанный ниже метод может использоваться для обеспечения совместимости с PKCS #7 при обработке содержимого типа SignedData. Если реализаций не способна выполнить декодирование ASN.1 для типа SignedData, использующего синтаксис строки октетов CMS SignedData encapContentInfo eContent, она может попытаться декодировать тип SignedData используя синтаксис PKCS #7 SignedData contentInfo и рассчитывая соответствующим образом подпись сообщения.

Приведенный ниже метод может использоваться для обеспечения совместимости с PKCS #7 при создании содержимого типа SignedData, в котором инкапсулируемые данные не форматированы с применением типа Data. Реализация может проверить значение eContentType и подправить ожидаемое DER-представление eContent на основе значения идентификатора объекта. Например, для поддержки Microsoft Authenticode [MSAC] можно выполнить следующее:

eContentType Object Identifier устанавливается в { 1 3 6 1 4 1 311 2 1 4 }
eContent содержит информацию Authenticode в представлении DER.

5.3. Тип SignerInfo

Информация для каждого подписавшего представляется типом SignerInfo.

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

      SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY

      SignatureValue ::= OCTET STRING

Поля SignerInfo описаны ниже.

version — номер версии синтаксиса. Если в SignerIdentifier используется выбор (CHOICE) issuerAndSerialNumber, для номера версии должно устанавливаться значение 1. Если SignerIdentifier представляет собой subjectKeyIdentifier, должен устанавливаться номер версии 3.

sid указывает сертификат (и, следовательно, открытый ключ) подписавшего. Открытый ключ подписавшего требуется получателю для проверки подписи. SignerIdentifier обеспечивает два варианта указания открытого ключа подписавшего. Вариант issuerAndSerialNumber идентифицирует ключ по имени эмитента и порядковому номеру сертификата, вариант subjectKeyIdentifier — по идентификатору ключа. При указании сертификата X.509 идентификатор ключа соответствует значению расширения X.509 subjectKeyIdentifier. При указании других форматов документ, задающий формат и использование сертификата с CMS, должен включать детали идентификатора соответствующего ключа в подходящем поле сертификата. Реализации должны поддерживать восприятие форм issuerAndSerialNumber и subjectKeyIdentifier для SignerIdentifier. При генерации SignerIdentifier реализация может поддерживать лишь одну из этих форм (issuerAndSerialNumber или subjectKeyIdentifier) и всегда применять ее, а может также произвольно смешивать применение этих двух форм. Однако должен применяться идентификатор subjectKeyIdentifier для указания открытого ключа, содержащегося в сертификате, отличном от X.509.

digestAlgorithm идентифицирует алгоритм цифровой подписи сообщения и все связанные с ними параметры, использованные подписавшим. Отпечаток (подпись) сообщения рассчитывается для подписываемого содержимого или для содержимого вместе с атрибутами подписи, как описано в параграфе 5.4. Алгоритм подписи сообщения следует указывать в поле digestAlgorithms связанных с ним данных SignerData. Реализации могут отказываться от проверки подписей, использующих не включенный в SignedData digestAlgorithms алгоритм.

SignedAttrs представляет набор подписанных атрибутов. Поле является необязательным, но оно должно присутствовать, если подписываемое значение EncapsulatedContentInfo не является id-data. SignedAttributes должно представляться в формате DER даже при использовании для остальной структуры представления BER. Полезные типы атрибутов (такие, как время подписания) определены в разделе 11. Если данное поле присутствует, оно должно содержать по крайней мере два приведенных ниже атрибута:

content-type в качестве своего значения использует тип содержимого EncapsulatedContentInfo подписываемого значения. Атрибут content-type описан в параграфе 11.1. Однако атрибут content-type недопустимо применять как часть не подписанного атрибута countersignature, определенного в параграфе 11.4.

message-digest в качестве своего значения использует отпечаток сообщения для содержимого. Атрибут message-digest определен в параграфе 11.2.

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

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

unsignedAttrs — набор атрибутов, которые не были подписаны. Это поле является необязательным. Полезные типы атрибутов (например, countersignatures) описаны в разделе 11.

Значения полей типов SignedAttribute и UnsignedAttribute описаны ниже.

attrType указывает тип атрибута и является идентификатором объекта.

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

5.4. Процесс расчета отпечатка сообщения

В процессе расчета отпечатка сообщения учитывается лишь само подписываемое сообщение или сообщение вместе с подписанными атрибутами. В любом случае исходной информацией для процесса расчета отпечатка является «значение» инкапсулируемого содержимого, которое будет подписано. В частности, исходной информацией служит строка октетов (OCTET STRING) encapContentInfo eContent, к которой применяется процесс подписания. Для алгоритма цифровой подписи сообщения входной информацией служат только строка октетов eContent без тегов и поля размера.

Результат процесса расчета отпечатка сообщения зависит от наличия поля signedAttrs. В отсутствие этого поля результатом будет просто отпечаток сообщения, как описано выше. Если же поле имеется, результатом будет отпечаток полного DER-представления значения SignedAttrs, содержащегося в поле signedAttrs. Поскольку значение SignedAttrs (при его наличии) должно содержать атрибуты content-type и message-digest, их значения также опосредованно включаются в результат. Атрибут content-type недопустимо включать в неподписанный атрибут countersignature, как описано в параграфе 11.4. При расчете отпечатка выполняется раздельное представление поля signedAttrs. Тег IMPLICIT [0] в signedAttrs не используется для представления DER и взамен применяется тег EXPLICIT SET OF. Т. е. в расчет должно включаться DER-представление тега EXPLICIT SET OF (а не IMPLICIT [0]) вместе с октетами размера и содержимого SignedAttributes.

При отсутствии поля signedAttrs для расчета отпечатка сообщения используется только строка октетов SignedData encapContentInfo eContent (например, содержимое файла). Преимущество этого заключается в том, что не требуется заранее знать размер подписываемого содержимого при генерации подписи.

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

5.5. Процесс создания подписи

Входные данные для процесса генерации подписи включают результат процесса создания отпечатка сообщения (message digest) и секретный ключ подписывающего. Детали процесса генерации подписи зависят от применяемого алгоритма. Идентификатор объекта вместе со всеми параметрами, задающими алгоритм, используемый подписывающим, передаются в поле signatureAlgorithm. Значение подписи, созданное подписывающим, должно представляться в форме строки октетов (OCTET STRING) и передаваться в поле signature.

5.6. Процесс проверки подписи

Входные данные для процесса проверки подписи включают результат процесса расчета отпечатка сообщения и открытый ключ подписавшего. Получатель может получить корректный открытый ключ подписавшего разными способами, но предпочтительно использовать метод из сертификата в поле SignedData certificates. Выбор и проверка пригодности ключа подписавшего могут базироваться на проверке пути сертификации (см. [PROFILE]), а также на иных способах, но этот вопрос выходит за рамки данного документа. Детали проверки подписи зависят от использованного алгоритма.

Получателю недопустимо полагаться на какие-либо значения отпечатка сообщения, рассчитанные его создателем. Если поле SignedData signerInfo включает signedAttributes, отпечаток содержимого сообщения должен быть рассчитан в соответствии с параграфом 5.4. Для того, чтобы подпись считалась действительной, рассчитанный отпечаток должен совпасть со значением атрибута messageDigest, включенным в поле signedAttributes структуры SignedData signerInfo.

Если SignedData signerInfo включает signedAttributes, значение атрибута content-type должно совпадать со значением SignedData encapContentInfo eContentType.

6. Тип содержимого Enveloped-data

Содержимое типа enveloped-data состоит из зашифрованных данных любого типа и зашифрованных ключей шифрования содержимого (encrypted content-encryption key) для одного или множества получателей. Комбинация шифрованного содержимого и шифрованного ключа шифрования содержимого для получателя представляет собой «цифровой конверт» (digital envelope) для данного получателя. Содержимое любого типа может быть упаковано в конверты для произвольного числа получателей с использованием любого из поддерживаемых методов управления ключами для каждого из получателей.

Типовым применением содержимого типа enveloped-data служит представление «цифровых конвертов» для одного или множества получателей с содержимым типа data или signed-data.

Этапы создания цифрового конверта enveloped-data перечислены ниже.

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

key transport (доставка ключей) — ключ шифрования содержимого шифруется с помощью открытого ключа получателя;

key agreement (согласование ключей) — используются открытый ключ получателя и секретный ключ отправителя для генерации симметричного ключа, который применяется для шифрования ключей шифрования содержимого;

symmetric key-encryption keys (шифрование с симметричным ключом) — ключ шифрования содержимого шифруется с использованием заранее полученного симметричного ключа, известного и получателю;

passwords (пароль) — ключ шифрования содержимого шифруется с помощью ключа, генерируемого из пароля и некого заранее известного сторонам секретного значения.
Для каждого получателя зашифрованный ключ шифрования содержимого и другая информация для конкретного получателя собираются в значение RecipientInfo, как описано в параграфе 6.2.
Содержимое шифруется с использованием ключа content-encryption. При этом в зависимости от применяемого ключа и алгоритма может потребоваться дополнение шифруемого содержимого для выравнивания по размеру блока шифрования (см. параграф 6.3).
Значения RecipientInfo для всех получателей собираются вместе с зашифрованным содержимым в структуру EnvelopedData, описанную в параграфе 6.1.

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

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

6.1. Тип EnvelopedData

Тип содержимого enveloped-data указывает идентификатор

      id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

Тип enveloped-data должен иметь форму ASN.1 EnvelopedData

      EnvelopedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

      OriginatorInfo ::= SEQUENCE {
        certs [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }

      RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

      EncryptedContentInfo ::= SEQUENCE {
        contentType ContentType,
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

      EncryptedContent ::= OCTET STRING

      UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

Значения полей EnvelopedData описаны ниже.

version — номер версии синтаксиса. Значение зависит от полей originatorInfo, RecipientInfo и unprotectedAttrs и должно присваиваться по следующему алгоритму:

         IF (присутствует originatorInfo) AND
            ((присутствуют любые сертификаты типа other) OR
            (присутствуют любые crls типа other))
         THEN устанавливается version = 4
         ELSE
            IF ((присутствует originatorInfo) AND
               (присутствуют любые сертификаты атрибутов версии 2)) OR
               (любая из структур RecipientInfo включает pwri) OR
               (любая из структур RecipientInfo включает ori)
            THEN устанавливается version = 3
            ELSE
               IF (originatorInfo отсутствует) AND
                  (unprotectedAttrs отсутствует) AND
                  (все структуры RecipientInfo имеют версию 0)
               THEN устанавливается version = 0
               ELSE устанавливается version = 2

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

certs — набор сертификатов, который может содержать сертификаты инициатора, связанные с несколькими разными алгоритмами управления ключами. Поле certs может также содержать сертификаты атрибутов, связанные с инициатором. Сертификаты в certs предназначены для того, чтобы обеспечить всем получателям возможность построения пути от признаваемого корня (root) или удостоверяющего центра верхнего уровня (top-level certification authority). Однако certs может содержать избыточные сертификаты, позволяющие построить несколько путей для двух и более удостоверяющих центров. Возможна и нехватка сертификатов в поле certs, если у получателя имеются другие способы получения требуемых сертификатов (например, предшествующий набор сертификатов).

crls — набор списков отзыва сертификатов (CRL). Это поле содержит информацию, которой может быть достаточно для проверки действительности сертификатов, указанных в поле certs, но эта достаточность не требуется. Это поле может содержать избыточное или недостаточное число списков CRL.

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

encryptedContentInfo — зашифрованное содержимое.

unprotectedAttrs — необязательный набор незашифрованных атрибутов. Полезные типы атрибутов определены в разделе 11.

Поля типа EncryptedContentInfo имеют приведенные ниже значения

contentType указывает тип содержимого.

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

encryptedContent — результат шифрования содержимого. Это поле является необязательным и при его отсутствии шифрованное содержимое должно доставляться иным способом.

Поле recipientInfos размещается перед полем encryptedContentInfo, что позволяет обрабатывать значение EnvelopedData за один проход.

6.2. Тип RecipientInfo

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

Поскольку не каждая реализация будет поддерживать все возможные алгоритмы управления ключами, все реализации должны корректно обрабатывать нереализованные алгоритмы, которые могут встречаться. Например, если получателю приходит ключ шифрования содержимого, зашифрованный с использованием его открытого ключа RSA и RSA-OAEP⁸, а реализация поддерживает только RSA PKCS #1 v1.5, в ней должна быть реализована процедура корректного отказа.

Реализации должны поддерживать доставку ключей (key transport), согласование ключей (key agreement) и применение известных симметричных ключей, представленные ktri, kari и kekri, соответственно. Реализации могут поддерживать управление ключами на основе пароля, представляемое pwri. Реализации также могут поддерживать любой другой метод управления ключами, представляемый ori. Поскольку каждый получатель может использовать свой метод управления ключами, а будущие спецификации могут добавлять новые методы, все реализации должны корректно обрабатывать не реализованные в них варианты RecipientInfo CHOICE и должны корректно обрабатывать не реализованные версии поддерживаемых вариантов CHOICE, а также должны корректно обрабатывать неизвестные или не реализованные варианты ori.

      RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo,
        pwri [3] PasswordRecipientinfo,
        ori [4] OtherRecipientInfo }

      EncryptedKey ::= OCTET STRING

6.2.1. KeyTransRecipientInfo

Информация для получателей, использующих доставку ключей (key transport), представляется типом KeyTransRecipientInfo. Каждый экземпляр KeyTransRecipientInfo переносит ключ шифрования содержимого для одного получателя.

      KeyTransRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- всегда устанавливается 0 или 2
        rid RecipientIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

      RecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

Поля типа KeyTransRecipientInfo описаны ниже.

version — номер версии синтаксиса. Если RecipientIdentifier представляет собой CHOICE issuerAndSerialNumber, номер версии должен иметь значение 0. Если RecipientIdentifier представляет собой subjectKeyIdentifier, номер версии должен быть 2.

rid указывает сертификат или ключ получателя, который отправитель применил для защиты ключа шифрования содержимого путем шифрования с помощью открытого ключа получателя. RecipientIdentifier поддерживает два варианта указания сертификата и, соответственно, открытого ключа получателя. Сертификат получателя должен содержать открытый ключ для транспортировки ключей. Следовательно, сертификат получателя X.509 версии 3, содержащий расширение использования ключей (key usage), должен иметь флаг keyEncipherment. Вариант issuerAndSerialNumber указывает сертификат получателя по отличительному имени эмитента и номеру сертификата, а subjectKeyIdentifier — по идентификатору ключа. При указании сертификата X.509 идентификатор ключа соответствует значению расширения X.509 subjectKeyIdentifier. При указании сертификатов иного формата документ, задающий формат сертификата и его использование с CMS, должен включать детали сопоставления идентификатора ключа с подходящим полем сертификата. На стороне получателя реализации должны поддерживать оба варианта указания сертификата получателя, на стороне отправителя должен поддерживаться хотя бы один из этих вариантов.

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

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

6.2.2. KeyAgreeRecipientInfo

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

      KeyAgreeRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- всегда устанавливается значение 3
        originator [0] EXPLICIT OriginatorIdentifierOrKey,
        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        recipientEncryptedKeys RecipientEncryptedKeys }

      OriginatorIdentifierOrKey ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier,
        originatorKey [1] OriginatorPublicKey }

      OriginatorPublicKey ::= SEQUENCE {
        algorithm AlgorithmIdentifier,
        publicKey BIT STRING }

      RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

      RecipientEncryptedKey ::= SEQUENCE {
        rid KeyAgreeRecipientIdentifier,
        encryptedKey EncryptedKey }

      KeyAgreeRecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        rKeyId [0] IMPLICIT RecipientKeyIdentifier }

      RecipientKeyIdentifier ::= SEQUENCE {
        subjectKeyIdentifier SubjectKeyIdentifier,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }

      SubjectKeyIdentifier ::= OCTET STRING

Поля типа KeyAgreeRecipientInfo описаны ниже.

version — номер версии синтаксиса. Всегда должен иметь значение 3.

originator представляет собой выбор (CHOICE) из трех вариантов указания открытого ключа отправителя для согласования ключей. Отправитель использует соответствующий секретный ключ и открытый ключ получателя для генерации парного ключа, с помощью которого шифруется ключ шифрования содержимого. Вариант issuerAndSerialNumber задает сертификат отправителя и, следовательно, его открытый ключ путем указания отличительного имени эмитента сертификата и порядкового номера сертификата. Вариант subjectKeyIdentifier указывает сертификат и ключ отправителя с помощью идентификатора ключа. Для сертификата X.509 идентификатор ключа соответствует значению расширения X.509 subjectKeyIdentifier. Для других форматов сертификата документ со спецификацией этого формата и его применения в CMS должен подробно описывать сопоставление идентификатора подходящему полю сертификата. Вариант originatorKey указывает идентификатор алгоритма и открытый ключ отправителя для согласования ключей. Этот метод обеспечивает анонимность инициатора, поскольку открытый ключ не сертифицируется. Реализации должны поддерживать все три варианта указания открытого ключа отправителя.

ukm является не обязательным. Для некоторых алгоритмов согласования ключей отправитель представляет ключевой материал UKM⁹, чтобы гарантировать создание нового ключа каждый раз при взаимодействии с тем же партнером. Реализации должны воспринимать последовательности KeyAgreeRecipientInfo, включающие поле ukm. Реализации, не поддерживающие алгоритмы согласования ключей с использованием UKM, должны аккуратно обрабатывать наличие UKM.

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

recipientEncryptedKeys включает идентификатор получателя и зашифрованный ключ для одного или множества получателей. KeyAgreeRecipientIdentifier представляет собой выбор (CHOICE) из двух вариантов задания сертификата получателя и, следовательно, его открытого ключа, который был использован отправителем для генерации парного ключа для зашифровки ключа шифрования содержимого. Сертификат получателя должен содержать открытый ключ, применяемый для согласования ключей. Следовательно, сертификат получателя X.509 версии 3 с расширением key usage должен иметь установленный бит keyAgreement. Ключ шифрования содержимого шифруется с использованием парного ключа. Вариант issuerAndSerialNumber указывает сертификат получателя по отличительному имени эмитента и порядковому номеру сертификата, тип RecipientKeyIdentifier описан ниже. encryptedKey представляет собой результат зашифровки ключа шифрования содержимого с помощью парного ключа, генерируемого с использованием алгоритма согласования ключей. Реализации должны поддерживать оба варианта указания сертификата получателя.

Поля типа RecipientKeyIdentifier описаны ниже.

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

date — необязательное поле, которое указывает получателю дату предшествующего распространения ключевого материала UKM, который был использован отправителем.

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

6.2.3. KEKRecipientInfo

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

      KEKRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- всегда устанавливается 4
        kekid KEKIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

      KEKIdentifier ::= SEQUENCE {
        keyIdentifier OCTET STRING,
        date GeneralizedTime OPTIONAL,
        other OtherKeyAttribute OPTIONAL }

Поля типа KEKRecipientInfo описаны ниже

version — номер версии синтаксиса. Всегда должен иметь значение 4.

kekid указывает симметричный ключ, которым зашифрован ключ шифрования содержимого, заранее переданный отправителю и одному или множеству получателей.

keyEncryptionAlgorithm указывает алгоритм шифрования ключа и все связанные с ним параметры, которые нужны для расшифровки ключа шифрования содержимого. Процесс шифрования ключей описан в параграфе 6.4.

encryptedKey — результат зашифровки ключа шифрования содержимого с помощью симметричного ключа.

Поля типа KEKIdentifier описаны ниже.

keyIdentifier — указывает ключ шифрования ключей, который был заранее передан отправителю и одному или множеству получателей.

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

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

6.2.4. PasswordRecipientInfo

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

Тип PasswordRecipientInfo задан в RFC 3211 [PWRI]. Структура PasswordRecipientInfo приведена здесь лишь для полноты.

      PasswordRecipientInfo ::= SEQUENCE {
        version CMSVersion,   -- всегда устанавливается значение 0
        keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey }

Поля типа PasswordRecipientInfo описаны ниже.

version — номер версии синтаксиса. Всегда должен иметь значение 0.

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

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

encryptedKey — результат зашифровки ключа шифрования содержимого с помощью ключа шифрования ключей.

6.2.5. OtherRecipientInfo

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

      OtherRecipientInfo ::= SEQUENCE {
        oriType OBJECT IDENTIFIER,
        oriValue ANY DEFINED BY oriType }

Поля типа OtherRecipientInfo описаны ниже.

oriType указывает метод управления ключами.

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

6.3. Процесс шифрования содержимого

Случайным образом генерируется ключ шифрования содержимого для нужного алгоритма. Защищаемые данные дополняются в соответствии с приведенным ниже описанием и после этого шифруются с использованием созданного ключа. Операция шифрования отображает произвольную строку октетов (исходные данные) в другую строку октетов (шифрованные данные) с использованием ключа шифрования содержимого. Зашифрованные данные включаются в строку октетов EnvelopedData encryptedContentInfo encryptedContent.

В некоторых алгоритмах шифрования предполагается, что размер исходных данных кратен некому целому числу k, где k больше 1. Для таких алгоритмов к входным данным в конце будут добавляться октеты заполнения со значениями k — (lth mod k) в количестве k — (lth mod k), где lth — размер исходных данных. Иными словами, после исходных данных будут добавляться последовательности

                     01 -- если lth mod k = k-1
                  02 02 -- если lth mod k = k-2
                      .
                      .
                      .
            k k ... k k -- если lth mod k = 0

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

6.4. Процесс шифрования ключа

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

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

7. Тип содержимого Digested-data

Тип содержимого digested-data включает данные любого типа с отпечатком (message digest) для них.

Обычно тип digested-data используется для защиты целостности содержимого и результат процесса создания подписанных данных служит входной информацией для создания типа enveloped-data.

Создание типа digested-data включает два этапа:

рассчитывается отпечаток (хэш) содержимого с использованием алгоритма message-digest;
алгоритм message-digest и отпечаток сообщения вместе с подписанным содержимым объединяются в структуру DigestedData.

Получатель проверяет отпечаток сообщения, сравнивая полученное значение с рассчитанным им самим отпечатком.

Ниже приведен идентификатор объекта для содержимого типа digested-data.

      id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

Тип digested-data должен иметь форму ASN.1 DigestedData:

      DigestedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithm DigestAlgorithmIdentifier,
        encapContentInfo EncapsulatedContentInfo,
        digest Digest }

      Digest ::= OCTET STRING

Поля типа DigestedData описаны ниже.

version — номер версии синтаксиса. Если инкапсулировано содержимое типа id-data, для номера версии должно быть указано значение 0, однако для остальных типов должно устанавливаться значение 2.

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

encapContentInfo — подписываемое содержимое, как определено в параграфе 5.2.

digest — результат процесса создания подписи для сообщения.

Порядок размещения полей digestAlgorithm, encapContentInfo и digest делает возможной обработку значения DigestedData за один проход.

8. Тип содержимого Encrypted-data

Тип encrypted-data содержит зашифрованные данные любого типа. В отличие от enveloped-data тип encrypted-data не включает ни получателей, ни зашифрованных ключей шифрования содержимого. Управление ключами должно осуществляться иным способом.

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

Ниже показан идентификатор объекта для содержимого типа encrypted-data.

      id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

Тип encrypted-data должен иметь форму ASN.1 EncryptedData

      EncryptedData ::= SEQUENCE {
        version CMSVersion,
        encryptedContentInfo EncryptedContentInfo,
        unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

Поля типа EncryptedData описаны ниже

version — номер версии синтаксиса. При наличии unprotectedAttrs номер версии должен иметь значение 2, при отсутствии unprotectedAttrs должно указываться значение 0.

encryptedContentInfo — зашифрованное содержимое, как описано в параграфе 6.1.

unprotectedAttrs — набор атрибутов, которые не шифруются. Это поле не является обязательным. Полезные типы атрибутов определены в разделе 11.

9. Тип содержимого Authenticated-data

Тип authenticated-data включает содержимое произвольного типа, код аутентификации сообщения (MAC¹⁰) и зашифрованные ключи аутентификации для одного или множества получателей. Комбинация MAC и одного из зашифрованных ключей аутентификации требуется получателю для проверки целостности содержимого. Защита целостности может обеспечиваться для любого типа содержимого и произвольного числа получателей.

Процесс создания authenticated-data включает перечисленные ниже шаги.

Случайным образом генерируется ключ аутентификации сообщения для конкретного алгоритма аутентификации.
Ключ аутентификации сообщения шифруется для каждого получателя. Детали этого шифрования зависят от используемого алгоритма управления ключами.
Для каждого получателя зашифрованный ключ аутентификации сообщения вместе с другой, относящейся к этому получателю, информацией собираются в значение RecipientInfo, как описано в параграфе 6.2.
Используя ключ аутентификации сообщения, инициатор рассчитывает значение MAC для содержимого. Если инициатор в дополнение к содержимому сообщения аутентифицирует какую-либо информацию (см. параграф 9.2), рассчитывается отпечаток (подпись) для содержимого, а затем этот отпечаток и дополнительные данные аутентифицируются с использованием ключа аутентификации и результат служит значением MAC.

9.1. Тип AuthenticatedData

Ниже приведен идентификатор объекта для содержимого типа authenticated-data.

      id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

Тип authenticated-data должен иметь форму ASN.1 AuthenticatedData.

      AuthenticatedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        macAlgorithm MessageAuthenticationCodeAlgorithm,
        digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
        encapContentInfo EncapsulatedContentInfo,
        authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
        mac MessageAuthenticationCode,
        unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }

      AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

      MessageAuthenticationCode ::= OCTET STRING

Поля типа AuthenticatedData описаны ниже.

version — номер версии синтаксиса. Значение version должно устанавливаться по приведенным ниже правилам

         IF (присутствует originatorInfo) AND
            ((присутствуют любые сертификаты типа other) OR
            (присутствуют любые crls типа other))
         THEN version = 3
         ELSE
            IF ((присутствует originatorInfo) AND
               (присутствуют любые сертификаты атрибутов версии 2))
            THEN version = 1
            ELSE version = 0

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

recipientInfos — набор информации для получателей, как определено в параграфе 6.1. Набор должен включать не менее 1 элемента.

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

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

encapContentInfo — аутентифицируемое содержимое, как определено в параграфе 5.2.

authAttrs — набор аутентифицируемых атрибутов. Структура authAttrs является необязательной, но она должна присутствовать, если тип содержимого для значения EncapsulatedContentInfo, которое аутентифицируется, отличается от id-data. При наличии поля authAttrs должно присутствовать также поле digestAlgorithm. Для структуры AuthAttributes должно использоваться представление DER, даже если остальная часть структуры задана в представлении BER. Полезные типы атрибутов определены в разделе 11. При наличии поля authAttrs оно должно содержать по крайней мере два перечисленных ниже атрибута:

content-type использует в качестве своего значения тип аутентифицируемого значения EncapsulatedContentInfo. Атрибут content-type определен в параграфе 11.1.

message-digest использует в качестве своего значения цифровую подпись (дайджест) содержимого. Атрибут message-digest определен в параграфе 11.2.

mac — код аутентификации сообщения.

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

9.2. Генерация MAC

В процессе расчета MAC вычисляется код аутентификации сообщения (MAC) для аутентифицируемого содержимого или отпечатка аутентифицируемого содержимого вместе с аутентифицируемыми атрибутами инициатора.

Если поле authAttrs отсутствует, входными данными для процесса расчета MAC служит строка октетов encapContentInfo eContent. В расчете MAC используются только октеты строки eContent без учета октетов тега и размера. Это позволяет рассчитывать значение MAC для строк, размер которых не известен заранее процессу MAC.

При наличии поля authAttrs должны учитываться атрибуты content-type (параграф 11.1) и message-digest (параграф 11.2), а входной информацией для процесса расчета MAC служит DER-представление authAttrs. Для расчета цифровой подписи сообщения выполняется отдельное кодирование поля authAttrs. Тег IMPLICIT [2] в поле authAttrs не используется для представления DER, взамен его применяется тег EXPLICIT SET OF. Т. е. в расчет цифровой подписи вместо DER-представления тега IMPLICIT [2] включается представление тега SET OF вместе с октетами размера и содержимого authAttrs.

Процесс расчета цифровой подписи вычисляет отпечаток аутентифицируемого сообщения. Исходными данными для процесса является «значение» инкапсулированного содержимого, которое будет аутентифицироваться. А именно, входными данными служит строка октетов encapContentInfo eContent, к которой применяется процесс аутентификации. Алгоритм расчета цифровой подписи учитывает только значение encapContentInfo eContent без октетов тега и размера. Это позволяет рассчитать цифровую подпись для содержимого, размер которого не известен заранее. Хотя октеты тега и размера encapContentInfo eContent не включаются в расчет цифровой подписи, они защищаются другими средствами. Октеты размера защищаются самой природой алгоритма цифровой подписи, поскольку найти два варианта содержимого произвольного размера, которые имели бы одинаковые отпечатки, не представляется возможным.

Входные данные процесса расчета MAC включают определенные выше входные данные MAC и ключ аутентификации, передаваемый в структуре recipientInfo. Детали расчета MAC зависят от используемого алгоритма MAC (например, HMAC¹¹). Идентификатор объекта вместе со всеми параметрами, определяющими использованный инициатором алгоритм MAC, передаются в поле macAlgorithm. Значение MAC, созданное инициатором, передается в форме строки октетов (OCTET STRING) в поле mac.

9.3. Проверка MAC

Входом для процесса проверки MAC служат входные данные (определяются на основе наличия или отсутствия поля authAttrs, как указано в параграфе 9.2) и ключ аутентификации, передаваемый в recipientInfo. Детали процесса проверки MAC зависят от используемого алгоритма MAC.

Получателю недопустимо опираться на любые значения MAC или цифровой подписи, рассчитанные инициатором. Содержимое аутентифицируется в соответствии с описанием параграфа 9.2. Если инициатор включил аутентифицируемые атрибуты, содержимое authAttrs аутентифицируется в соответствии с параграфом 9.2. Для того, чтобы аутентификация считалась пройденной, значение MAC, рассчитанное получателем, должно совпасть со значением поля mac. Аналогично для успешной аутентификации при наличии поля authAttrs значение цифровой подписи, рассчитанное получателем, должно совпадать со значением атрибута message-digest в authAttrs.

Если AuthenticatedData включает authAttrs, значение атрибута content-type должно соответствовать значению AuthenticatedData encapContentInfo eContentType.

10. Полезные типы

Этот раздел состоит из двух частей — в первой определены идентификаторы алгоритмов, а во второй другие полезные типы.

10.1. Типы идентификаторов алгоритма

10.1. Algorithm Identifier Types

Все идентификаторы алгоритмов используют один тип:

AlgorithmIdentifier — определение заимствовано из X.509 [X.509-88].

Для каждого типа алгоритма имеется множество вариантов.

10.1.1. DigestAlgorithmIdentifier

Тип DigestAlgorithmIdentifier указывает алгоритм message-digest, примерами могут служить алгоритмы SHA-1, MD2, MD5. Алгоритм message-digest отображает строку октетов (содержимое) в другую строку октетов (отпечаток).

      DigestAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.2. SignatureAlgorithmIdentifier

Тип SignatureAlgorithmIdentifier указывает алгоритм подписи и может также указывать алгоритм отпечатка (message digest). Примерами могут служить RSA, DSA, DSA с SHA-1, ECDSA и ECDSA с SHA-256. Алгоритм подписи поддерживает операции создания и проверки подписи. При генерации подписи используется отпечаток сообщения и секретный ключ подписывающего. При проверке подписи используется отпечаток сообщения и открытый ключ подписавшего для проверки пригодности полученной подписи. Выполняемая операция определяется контекстом.

      SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.3. KeyEncryptionAlgorithmIdentifier

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

Детали шифрования и расшифровки зависят от используемого алгоритма управления ключами. Поддерживаются доставка (key transport) и согласование (key agreement) ключей, заранее известные симметричные ключи и ключи, создаваемые из паролей.

      KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.4. ContentEncryptionAlgorithmIdentifier

Тип ContentEncryptionAlgorithmIdentifier указывает алгоритм шифрования содержимого (примерами могут служить Triple-DES и RC2). Алгоритм шифрования содержимого поддерживает операции шифрования и расшифровки. Операция шифрования отображает строку октетов (открытый текст) на другую строку октетов (шифрованный текст) с использованием ключа шифрования содержимого. Операция расшифровки выполняет обратное преобразование. Выбор операции определяется контекстом.

      ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.5. MessageAuthenticationCodeAlgorithm

Тип MessageAuthenticationCodeAlgorithm указывает алгоритм для кода аутентификации сообщения (MAC) — примерами могут служить DES-MAC и HMAC-SHA-1. Алгоритм MAC поддерживает операции создания и проверки кода, в которых используется один и тот же симметричный ключ. Выбор операции определяется контекстом.

      MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

10.1.6. KeyDerivationAlgorithmIdentifier

Тип KeyDerivationAlgorithmIdentifier определен в RFC 3211 [PWRI] и здесь это определение повторено для полноты.

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

      KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

10.2. Другие полезные типы

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

10.2.1. RevocationInfoChoices

Тип RevocationInfoChoices дает набор вариантов информации о статусе отзыва. Предполагается, что такой набор содержит информацию, достаточную для идентификации связанных с набором сертификатов и сертификатов атрибутов, которые отозваны. Однако в наборе может содержаться избыточная информация о статусе отзыва, а также набор может не включать всей требуемой информации. Списки отзыва сертификатов X.509 (CRL) [X.509-97] являются основным источником информации о статусе отзыва, но могут поддерживаться иные форматы такой информации. Обеспечивается вариант OtherRevocationInfoFormat для поддержки любых других форматов информации об отзыве без дополнительного изменения CMS. Например, с помощью OtherRevocationInfoFormat могут поддерживаться отзывы протокола OCSP¹² [OCSP].

CertificateList может содержать список CRL, ARL¹³, Delta CRL или Attribute CRL. Все эти списки используют общий синтаксис.

Тип CertificateList указывает список отзыва сертификатов (CRL). Эти списки определены в X.509 [X.509-97] и заданы для использования в Internet документом RFC 5280 [PROFILE].

Ниже приведено определение CertificateList из X.509.

      RevocationInfoChoices ::= SET OF RevocationInfoChoice

      RevocationInfoChoice ::= CHOICE {
        crl CertificateList,
        other [1] IMPLICIT OtherRevocationInfoFormat }

      OtherRevocationInfoFormat ::= SEQUENCE {
        otherRevInfoFormat OBJECT IDENTIFIER,
        otherRevInfo ANY DEFINED BY otherRevInfoFormat }

10.2.2. CertificateChoices

Тип CertificateChoices задает расширенный сертификат PKCS #6 [PKCS#6], сертификат X.509, сертификат атрибута X.509 версии 1 (ACv1) [X.509-97], сертификат атрибута X.509 версии 2 (ACv2) [X.509-00] или сертификат иного формата. Расширенные сертификаты PKCS #6 считаются устаревшими и поддерживаются лишь для совместимости со старыми версиями, поэтому применять их не следует. Сертификаты ACv1 также являются устаревшими, включены лишь для совместимости со старыми версиями и применять их не следует. Профиль Internet для сертификатов X.509 задан в документе Internet X.509 Public Key Infrastructure: Certificate and CRL Profile [PROFILE], профиль для сертификатов ACv2 — в документе An Internet Attribute Certificate Profile for Authorization [ACPROFILE]. Вариант OtherCertificateFormat служит для поддержки других форматов сертификатов без изменения CMS.

Определение Certificate заимствовано из X.509.

Определения AttributeCertificate заимствованы из X.509-1997 и X.509-2000 — определение из X.509-1997 обозначено AttributeCertificateV1 (см. параграф 12.2), а определение из X.509-2000 — AttributeCertificateV2.

      CertificateChoices ::= CHOICE {
       certificate Certificate,
       extendedCertificate [0] IMPLICIT ExtendedCertificate, -- отменено
       v1AttrCert [1] IMPLICIT AttributeCertificateV1,       -- отменено
       v2AttrCert [2] IMPLICIT AttributeCertificateV2,
       other [3] IMPLICIT OtherCertificateFormat }

      OtherCertificateFormat ::= SEQUENCE {
        otherCertFormat OBJECT IDENTIFIER,
        otherCert ANY DEFINED BY otherCertFormat }

10.2.3. CertificateSet

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

Точное значение термина «путь сертификации» выходит за рамки данной спецификации. Однако [PROFILE] включает определения для сертификатов X.509. Некоторые приложения могут ограничивать сверху размер пути сертификации, а другие могут предъявлять те или иные требования к связям между субъектами и эмитентами в пути сертификации.

      CertificateSet ::= SET OF CertificateChoices

10.2.4. IssuerAndSerialNumber

Тип IssuerAndSerialNumber указывает сертификат и, таким образом, субъекта и его открытый ключ по отличительному имени (distinguished name) эмитента и порядковому номеру сертификата.

Определение поля Name заимствовано из X.501 [X.501-88], а поля CertificateSerialNumber — из X.509 [X.509-97].

      IssuerAndSerialNumber ::= SEQUENCE {
        issuer Name,
        serialNumber CertificateSerialNumber }

      CertificateSerialNumber ::= INTEGER

10.2.5. CMSVersion

Тип CMSVersion указывает номер версии синтаксиса для обеспечения совместимости с будущими версиями этой спецификации.

      CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

10.2.6. UserKeyingMaterial

Тип UserKeyingMaterial указывает синтаксис для пользовательского ключевого материала (UKM¹⁴). Некоторым алгоритмам согласования ключей UKM требуется для генерации разных ключей в каждом случае согласования между данной парой сторон. Отправитель предоставляет UKM для использования с конкретным алгоритмом согласования ключей.

      UserKeyingMaterial ::= OCTET STRING

10.2.7. OtherKeyAttribute

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

      OtherKeyAttribute ::= SEQUENCE {
        keyAttrId OBJECT IDENTIFIER,
        keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

11. Полезные атрибуты

В этом разделе определены атрибуты, которые могут использоваться с содержимым типов signed-data, enveloped-data, encrypted-data, authenticated-data. Синтаксис Attribute совместим с X.501 [X.501-88] и RFC 5280 [PROFILE]. Некоторые из описанных в этом разделе атрибутов были определены в PKCS #9 [PKCS#9], а другие — в предыдущей версии этой спецификации [CMS1]. Атрибуты перечислены без какого-либо упорядочения.

Из числа атрибутов, определенных в других документах, следует отметить спецификацию S/MIME версии 3.1 [MSG3.1] и расширенные средства защиты для S/MIME [ESS], которые включают также рекомендации по размещению этих атрибутов.

11.1. Тип содержимого

Атрибут content-type указывает тип содержимого ContentInfo в signed-data или authenticated-data. Атрибут content-type должен присутствовать при наличии подписанных атрибутов в signed-data или аутентифицированных атрибутов в authenticated-data. Значение атрибута content-type должно соответствовать значению encapContentInfo eContentType в signed-data или authenticated-data.

Атрибут content-type должен быть подписанным (signed) или аутентифицированным (authenticated) атрибутом, для него недопустимо быть неподписанным (unsigned), неаутентифицированным (unauthenticated) или незащищенным (unprotected) атрибутом.

Ниже приведен идентификатор объекта для атрибута content-type.

      id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

Значения атрибута content-type имеют тип ASN.1 ContentType

      ContentType ::= OBJECT IDENTIFIER

Хотя синтаксис определен, как SET OF AttributeValue, атрибут content-type должен иметь единственное значение, отсутствие или несколько экземпляров AttributeValue не допускается.

Синтаксис SignedAttributes и AuthAttributes определяет их как SET OF Attributes. В SignedAttributes поля signerInfo недопустимо включать множество экземпляров атрибута content-type. Аналогично, в AuthAttributes поля AuthenticatedData недопустимо включать множество экземпляров атрибута content-type.

11.2. Отпечаток сообщения

Тип атрибута message-digest задает отпечаток (message digest) строки октетов encapContentInfo eContent, подписанной в signed-data (см. параграф 5.4) или аутентифицированной в authenticated-data (см. параграф 9.2). Для signed-data отпечаток рассчитывается с использованием алгоритма хэширования подписывающей стороны. Для authenticated-data отпечаток рассчитывается с использованием алгоритма хэширования инициатора.

В signed-data тип атрибута message-digest должен присутствовать при наличии любых подписанных атрибутов. В authenticated-data тип атрибута message-digest должен присутствовать при наличии любых аутентифицированных атрибутов.

Атрибут message-digest должен быть подписанным (signed) или аутентифицированным (authenticated), недопустимо использование неподписанного (unsigned), неаутентифицированного (unauthenticated) или незащищенного (unprotected) атрибута.

Ниже приведен идентификатор объекта для атрибута message-digest.

      id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

Атрибут message-digest должен иметь тип ASN.1 MessageDigest

      MessageDigest ::= OCTET STRING

Атрибут message-digest должен иметь единственное значение, несмотря на то, что его синтаксис определен, как SET OF AttributeValue. Недопустимо отсутствие или наличие множества экземпляров AttributeValue.

Синтаксис SignedAttributes и AuthAttributes определяет их как SET OF Attributes. В SignedAttributes поля signerInfo недопустимо включать множество экземпляров атрибута message-digest. Аналогично, в AuthAttributes поля AuthenticatedData недопустимо включать множество экземпляров атрибута message-digest.

11.3. Время подписи

Атрибут signing-time указывает время, когда подписавший (предположительно) «поставил свою подпись». Этот атрибут предназначен для использования в signed-data.

Атрибут signing-time должен быть подписанным (signed) или аутентифицированным (authenticated), недопустимо использование неподписанного (unsigned), неаутентифицированного (unauthenticated) или незащищенного (unprotected) атрибута.

Ниже приведен идентификатор объекта для атрибута signing-time.

      id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

Значения атрибута signing-time имеют тип ASN.1 SigningTime.

      SigningTime ::= Time

      Time ::= CHOICE {
        utcTime UTCTime,
        generalizedTime GeneralizedTime }

Примечание. Определение Time соответствует версии X.509 от 1997 года [X.509-97].

Даты между 1 января 1950 г. и 31 декабря 2049 г. (включительно) должны представляться в формате UTCTime. Даты до 1950 г. и после 2049 г. должны представляться в формате GeneralizedTime.

Значения UTCTime должны указываться по времени Coordinated Universal Time (ранее, гринвичское время — Greenwich Mean Time или GMT, а также время Zulu) и должны включать секунды (т. е., использовать формат YYMMDDHHMMSSZ), даже если число секунд равно 0. Полночь должна представляться в виде YYMMDD000000Z. Информация о столетии является неявной и должна определяться следующим образом:

при YY не меньше 50 значение года должно интерпретироваться, как 19YY;

при YY < 50 значение года должно интерпретироваться, как 20YY.

Значения GeneralizedTime должны представляться во времени Coordinated Universal Time и должны включать секунды (т. е., использовать формат YYYYMMDDHHMMSSZ), даже если число секунд равно 0. В значения GeneralizedTime недопустимо включать доли секунд.

Атрибут signing-time должен иметь единственное значение, несмотря на синтаксис определения SET OF AttributeValue. Недопустимо отсутствие или множество экземпляров AttributeValue.

Синтаксис SignedAttributes и AuthAttributes определяет их как SET OF Attributes. В SignedAttributes поля signerInfo недопустимо включать множество экземпляров атрибута signing-time. Аналогично, в AuthAttributes поля AuthenticatedData недопустимо включать множество экземпляров атрибута signing-time.

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

11.4. Заверяющая подпись

Тип атрибута countersignature указывает одну или множество подписей для строки октетов содержимого signature в значении SignerInfo для signed-data. Т. е., отпечаток сообщения рассчитывается для октетов, представляющих значение OCTET STRING, без октетов тега и размера. Таким образом, тип атрибута countersignature «заверяет» (еще раз подписывает) другую подпись.

Атрибут countersignature должен быть неподписанным (unsigned), недопустимо использование подписанных (signed), аутентифицированных (authenticated), неаутентифицированных (unauthenticated) и незащищенных (unprotected) атрибутов.

Ниже приведен идентификатор объекта для атрибута countersignature.

      id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

Значения атрибута countersignature имеют тип ASN.1 Countersignature

      Countersignature ::= SignerInfo

Значения countersignature имеют такой же смысл, как значения SignerInfo для обычных подписей, за исключением отмеченных ниже различий.

В поле signedAttributes недопустимо включать атрибут content-type — для заверяющих подписей нет типа содержимого.
Поле signedAttributes должно включать атрибут message-digest, если в нем есть какие-либо другие атрибуты.
Входными данными для процесса создания отпечатка сообщения являются октеты содержимого DER-представления поля signatureValue в значении SignerInfo, с которым связан атрибут.

Атрибут countersignature может иметь множество значений. Синтаксис определен, как SET OF AttributeValue и должен присутствовать хотя бы один экземпляр AttributeValue.

Синтаксис UnsignedAttributes определен, как SET OF Attributes. UnsignedAttributes в signerInfo может включать множество экземпляров атрибута countersignature.

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

12. Модули ASN.1

В параграфе 12.1 приведен модуль ASN.1 для CMS, а в параграфе 12.2 — для сертификата атрибутов версии 1.

12.1. Модуль CMS ASN.1

   CryptographicMessageSyntax2004
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- Экспортируется все
   -- Типы и значения, определенные в этом модуле, экспортируются для использования 
   -- в других модулях ASN.1. Их могут применять для своих целей другие приложения.

   IMPORTS

     -- Импорт из RFC 5280 [PROFILE], Приложение A.1
           AlgorithmIdentifier, Certificate, CertificateList,
           CertificateSerialNumber, Name
              FROM PKIX1Explicit88
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) pkix1-explicit(18) }

     -- Импорт из RFC 3281 [ACPROFILE], Приложение B
           AttributeCertificate
              FROM PKIXAttributeCertificate
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) attribute-cert(12) }

     -- Импорт из Приложения B к данному документу
           AttributeCertificateV1
              FROM AttributeCertificateVersion1
                   { iso(1) member-body(2) us(840) rsadsi(113549)
                     pkcs(1) pkcs-9(9) smime(16) modules(0)
                     v1AttrCert(15) } ;

   -- Синтаксис криптографического сообщения

   ContentInfo ::= SEQUENCE {
     contentType ContentType,
     content [0] EXPLICIT ANY DEFINED BY contentType }

   ContentType ::= OBJECT IDENTIFIER

   SignedData ::= SEQUENCE {
     version CMSVersion,
     digestAlgorithms DigestAlgorithmIdentifiers,
     encapContentInfo EncapsulatedContentInfo,
     certificates [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
     signerInfos SignerInfos }

   DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

   SignerInfos ::= SET OF SignerInfo

   EncapsulatedContentInfo ::= SEQUENCE {
     eContentType ContentType,
     eContent [0] EXPLICIT OCTET STRING OPTIONAL }

   SignerInfo ::= SEQUENCE {
     version CMSVersion,
     sid SignerIdentifier,
     digestAlgorithm DigestAlgorithmIdentifier,
     signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
     signatureAlgorithm SignatureAlgorithmIdentifier,
     signature SignatureValue,
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

   SignerIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier }

   SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

   UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

   Attribute ::= SEQUENCE {
     attrType OBJECT IDENTIFIER,
     attrValues SET OF AttributeValue }

   AttributeValue ::= ANY

   SignatureValue ::= OCTET STRING

   EnvelopedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo,
     unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

   OriginatorInfo ::= SEQUENCE {
     certs [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT RevocationInfoChoices OPTIONAL }

   RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

   EncryptedContentInfo ::= SEQUENCE {
     contentType ContentType,
     contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
     encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

   EncryptedContent ::= OCTET STRING

   UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute

   RecipientInfo ::= CHOICE {
     ktri KeyTransRecipientInfo,
     kari [1] KeyAgreeRecipientInfo,
     kekri [2] KEKRecipientInfo,
     pwri [3] PasswordRecipientInfo,
     ori [4] OtherRecipientInfo }

   EncryptedKey ::= OCTET STRING

   KeyTransRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- всегда устанавливается значение 0 или 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   RecipientIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier }

   KeyAgreeRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- всегда устанавливается 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys }

   OriginatorIdentifierOrKey ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier,
     originatorKey [1] OriginatorPublicKey }

   OriginatorPublicKey ::= SEQUENCE {
     algorithm AlgorithmIdentifier,
     publicKey BIT STRING }

   RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey

   RecipientEncryptedKey ::= SEQUENCE {
     rid KeyAgreeRecipientIdentifier,
     encryptedKey EncryptedKey }

   KeyAgreeRecipientIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     rKeyId [0] IMPLICIT RecipientKeyIdentifier }

   RecipientKeyIdentifier ::= SEQUENCE {
     subjectKeyIdentifier SubjectKeyIdentifier,
     date GeneralizedTime OPTIONAL,
     other OtherKeyAttribute OPTIONAL }

   SubjectKeyIdentifier ::= OCTET STRING

   KEKRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- всегда устанавливается значение 4
     kekid KEKIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   KEKIdentifier ::= SEQUENCE {
     keyIdentifier OCTET STRING,
     date GeneralizedTime OPTIONAL,
     other OtherKeyAttribute OPTIONAL }

   PasswordRecipientInfo ::= SEQUENCE {
     version CMSVersion,   -- всегда устанавливается 0
     keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
                                OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

   OtherRecipientInfo ::= SEQUENCE {
     oriType OBJECT IDENTIFIER,
     oriValue ANY DEFINED BY oriType }

   DigestedData ::= SEQUENCE {
     version CMSVersion,
     digestAlgorithm DigestAlgorithmIdentifier,
     encapContentInfo EncapsulatedContentInfo,
     digest Digest }

   Digest ::= OCTET STRING

   EncryptedData ::= SEQUENCE {
     version CMSVersion,
     encryptedContentInfo EncryptedContentInfo,
     unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

   AuthenticatedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     macAlgorithm MessageAuthenticationCodeAlgorithm,
     digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
     encapContentInfo EncapsulatedContentInfo,
     authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
     mac MessageAuthenticationCode,
     unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL }

   AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

   UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

   MessageAuthenticationCode ::= OCTET STRING

   DigestAlgorithmIdentifier ::= AlgorithmIdentifier

   SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

   KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

   ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

   MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier

   KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier

   RevocationInfoChoices ::= SET OF RevocationInfoChoice

   RevocationInfoChoice ::= CHOICE {
     crl CertificateList,
     other [1] IMPLICIT OtherRevocationInfoFormat }

   OtherRevocationInfoFormat ::= SEQUENCE {
     otherRevInfoFormat OBJECT IDENTIFIER,
     otherRevInfo ANY DEFINED BY otherRevInfoFormat }

   CertificateChoices ::= CHOICE {
     certificate Certificate,
     extendedCertificate [0] IMPLICIT ExtendedCertificate,  -- отменено
     v1AttrCert [1] IMPLICIT AttributeCertificateV1,        -- отменено
     v2AttrCert [2] IMPLICIT AttributeCertificateV2,
     other [3] IMPLICIT OtherCertificateFormat }

   AttributeCertificateV2 ::= AttributeCertificate

   OtherCertificateFormat ::= SEQUENCE {
     otherCertFormat OBJECT IDENTIFIER,
     otherCert ANY DEFINED BY otherCertFormat }

   CertificateSet ::= SET OF CertificateChoices

   IssuerAndSerialNumber ::= SEQUENCE {
     issuer Name,
     serialNumber CertificateSerialNumber }

   CMSVersion ::= INTEGER  { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

   UserKeyingMaterial ::= OCTET STRING

   OtherKeyAttribute ::= SEQUENCE {
     keyAttrId OBJECT IDENTIFIER,
     keyAttr ANY DEFINED BY keyAttrId OPTIONAL }

   -- Идентификаторы типа содержимого

   id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

   id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

   id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }

   id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }

   id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

   id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 }

   -- Атрибуты CMS

   MessageDigest ::= OCTET STRING

   SigningTime  ::= Time

   Time ::= CHOICE {
     utcTime UTCTime,
     generalTime GeneralizedTime }

   Countersignature ::= SignerInfo

   -- Идентификаторы атрибутов объекта

   id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }

   id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }

   id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }

   id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }

   -- Отменяет синтаксис Extended Certificate из PKCS #6

   ExtendedCertificateOrCertificate ::= CHOICE {
     certificate Certificate,
     extendedCertificate [0] IMPLICIT ExtendedCertificate }

   ExtendedCertificate ::= SEQUENCE {
     extendedCertificateInfo ExtendedCertificateInfo,
     signatureAlgorithm SignatureAlgorithmIdentifier,
     signature Signature }

   ExtendedCertificateInfo ::= SEQUENCE {
     version CMSVersion,
     certificate Certificate,
     attributes UnauthAttributes }

   Signature ::= BIT STRING

   END -- для CryptographicMessageSyntax2004

12.2. Модуль ASN.1 для сертификата атрибутов версии 1.

   AttributeCertificateVersion1
       { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   -- Экспортируется все

   IMPORTS

     -- Импорт из RFC 5280 [PROFILE], Приложение A.1
           AlgorithmIdentifier, Attribute, CertificateSerialNumber,
           Extensions, UniqueIdentifier
              FROM PKIX1Explicit88
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) pkix1-explicit(18) }

     -- Импорт из RFC 5280 [PROFILE], Приложение A.2
           GeneralNames
              FROM PKIX1Implicit88
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) pkix1-implicit(19) }

     -- Импорт из RFC 3281 [ACPROFILE], Приложение B
           AttCertValidityPeriod, IssuerSerial
              FROM PKIXAttributeCertificate
                   { iso(1) identified-organization(3) dod(6)
                     internet(1) security(5) mechanisms(5) pkix(7)
                     mod(0) attribute-cert(12) } ;

   -- Определения взяты из X.509-1997 [X.509-97], но используются другие имена
   -- в целях предотвращения конфликтов.

   AttributeCertificateV1 ::= SEQUENCE {
     acInfo AttributeCertificateInfoV1,
     signatureAlgorithm AlgorithmIdentifier,
     signature BIT STRING }

   AttributeCertificateInfoV1 ::= SEQUENCE {
     version AttCertVersionV1 DEFAULT v1,
     subject CHOICE {
       baseCertificateID [0] IssuerSerial,
         -- связано с сертификатом открытого ключа
       subjectName [1] GeneralNames },
         -- связано с именем
     issuer GeneralNames,
     signature AlgorithmIdentifier,
     serialNumber CertificateSerialNumber,
     attCertValidityPeriod AttCertValidityPeriod,
     attributes SEQUENCE OF Attribute,
     issuerUniqueID UniqueIdentifier OPTIONAL,
     extensions Extensions OPTIONAL }

   AttCertVersionV1 ::= INTEGER { v1(0) }

   END -- для AttributeCertificateVersion1

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

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

[ACPROFILE] Farrell, S. and R. Housley, «An Internet Attribute Certificate Profile for Authorization», RFC 3281, April 2002.

[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

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

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

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

[X.501-88] CCITT. Recommendation X.501: The Directory — Models, 1988.

[X.509-88] CCITT. Recommendation X.509: The Directory — Authentication Framework, 1988.

[X.509-97] ITU-T. Recommendation X.509: The Directory — Authentication Framework, 1997.

[X.509-00] ITU-T. Recommendation X.509: The Directory — Authentication Framework, 2000.

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

[CMS1] Housley, R., «Cryptographic Message Syntax», RFC 2630, June 1999.

[CMS2] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3369, August 2002.

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

[CMSALG] Housley, R., «Cryptographic Message Syntax (CMS) Algorithms», RFC 3370, August 2002.

[CMSMSIG] Housley, R., «Cryptographic Message Syntax (CMS) Multiple Signer Clarification», RFC 4853, April 2007.

[DH-X9.42] Rescorla, E., «Diffie-Hellman Key Agreement Method», RFC 2631, June 1999.

[ESS] Hoffman, P., Ed., «Enhanced Security Services for S/MIME», RFC 2634, June 1999.

[MSAC] Microsoft Development Network (MSDN) Library, «Authenticode», April 2004 Release.

[MSG2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, «S/MIME Version 2 Message Specification», RFC 2311, March 1998.

[MSG3] Ramsdell, B., Ed., «S/MIME Version 3 Message Specification», RFC 2633, June 1999.

[MSG3.1] Ramsdell, B., Ed., «Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification», RFC 3851, July 2004.

[NEWPKCS#1] Kaliski, B. and J. Staddon, «PKCS #1: RSA Cryptography Specifications Version 2.0», RFC 2437, October 1998.

[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, «X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP», RFC 2560, June 1999.

[PKCS#1] Kaliski, B., «PKCS #1: RSA Encryption Version 1.5», RFC 2313, March 1998.

[PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993.

[PKCS#7] Kaliski, B., «PKCS #7: Cryptographic Message Syntax Version 1.5», RFC 2315, March 1998.

[PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, Version 1.1. November 1993.

[PWRI] Gutmann, P., «Password-based Encryption for CMS», RFC 3211, December 2001.

[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

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

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

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

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

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

Метод управления ключами, используемый для распространения ключей аутентификации сообщений, сам по себе должен обеспечивать аутентификацию источников, поскольку в противном случае будут доставляться целостные сообщения из неизвестных источников. Алгоритмы RSA [PKCS#1[, [NEWPKCS#1] и Ephemeral-Static Diffie-Hellman [DH-X9.42] не обеспечивают требуемой аутентификации источников. Алгоритм Static-Static Diffie-Hellman [DH-X9.42] обеспечивает требуемую аутентификацию, когда ключи инициатора и получателя оба привязаны к приемлемой идентификации в сертификатах X.509.

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

Реализации должны генерировать случайные значения ключей шифрования содержимого, ключей аутентификации сообщений, векторов инициализации (IV) и заполнения. Генерация ключевых пар «открытый-секретный» также основана на случайных значениях. Использование некачественных генераторов псевдослучайных чисел (PRNG¹⁵) при создании криптографических ключей может приводить к снижению уровня или полной утрате защиты. Атакующему может оказаться гораздо проще воспроизвести среду PRNG, в которой создавались ключи, перебрав сравнительно небольшой набор вариантов, нежели использовать средства подбора (brute force) во всем пространстве возможных ключей. Генерация качественных случайных чисел достаточно сложна. В RFC 4086 [RANDOM] представлены важные рекомендации по решению таких задач.

При использовании алгоритмов согласования ключей или заранее известных ключей шифрования ключей, такие ключи служат для шифрования ключей, которые, в свою очередь, применяются для шифрования содержимого. Если для шифрования ключей и содержимого применяются разные алгоритмы, эффективный уровень защиты определяется наиболее слабым из этих двух алгоритмов. Если, например, содержимое шифруется с помощью алгоритма Triple-DES с использованием 168-битового ключа, а для ключа шифрования ключей применяется алгоритм RC2 с 40-битовым ключом, уровень защиты будет соответствовать 40-битовому ключу. Тривиальный поиск для определения 40-битового ключа RC2 позволит расшифровать ключ Triple-DES, который после этого может использоваться для расшифровки содержимого. Следовательно, разработчики должны гарантировать, что для шифрования ключей используется алгоритм не менее (а возможно и более) сильный, нежели для шифрования содержимого.

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

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

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

Этот документ включает результаты работы многих профессионалов. Автор отмечает значительный вклад всех членов рабочей группы IETF S/MIME. Отдельные благодарности Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, Dave Solo, Paul Timmel и Sean Turner за поддержку с их стороны.

Спасибо Tim Polk за помощь в продвижении этой спецификации по пути стандартизации. Дополнительная благодарность Jan Vilhuber за внимательное чтение, которое привело в сообщению RFC Errata 1744.

Адрес автора

Russell Housley

Vigil Security, LLC

918 Spring Knoll Drive

Herndon, VA 20170

USA

EMail: housley@vigilsec.com

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

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

nmalykh@gmail.com

1Cryptographic Message Syntax.

2Public Key Infrastructure using X.509 — инфраструктура открытых ключей с использованием X.509.

3Secure/Multipurpose Internet Mail Extensions — защищенные/многоцелевые расширения электронной почты Internet.

4Basic Encoding Rules — базовые правила представления.

5Distinguished Encoding Rules — правила «изысканного» представления.

6Certificate revocation list.

7Elliptic Curve Digital Signature Algorithm — алгоритм цифровой подписи на основе эллиптической кривой.

8Optimal Asymmetric Encryption Padding.

9User Keying Material — пользовательский ключевой материал.

10Message authentication code.

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

12Online Certificate Status Protocol — протокол интерактивной информации о статусе сертификата.

13Authority Revocation List — список отзыва УЦ.

14User keying material.

15Pseudo-random number generators.

Рубрика: RFC | Комментарии отключены

RFC 5681 TCP Congestion Control

Опубликовано 15.09.2009 автором Nikolai Malykh

Network Working Group                                      M. Allman
Request for Comments: 5681                                 V. Paxson
Obsoletes: 2581                                                 ICSI
Category: Standards Track                                 E. Blanton
                                                   Purdue University
                                                      September 2009

Контроль насыщения в TCP

TCP Congestion Control

PDF

Аннотация

В этом документе определены 4 связанных между собой алгоритма контроля насыщения¹ для протокола TCP — slow start², congestion avoidance³, fast retransmit⁴ и fast recovery⁵. Кроме того, в документе указано, как протоколу TCP следует начинать передачу после сравнительно долгого периода бездействия, а также рассмотрены различные методы генерации подтверждений. Данный документ служит заменой RFC 2581.

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

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

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

Этот документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

В этом документе даны спецификации четырех алгоритмов контроля насыщения для протокола TCP [RFC793]: slow start, congestion avoidance, fast retransmit и fast recovery. Эти алгоритмы были опубликованы в документах [Jac88] и [Jac90]. Использование алгоритмов с протоколом TCP стандартизовано в [RFC1122].

Отметим, что в документе [Ste94] приводятся примеры реального использования описанных здесь алгоритмов, а [WS95] содержит пояснения к исходному коду реализации этих алгоритмов в BSD.

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

Этот документ отменяет действие [RFC2581], который, в свою очередь, отменил [RFC2001].

Глава данного документа 2 содержит определения используемых в документе терминов. В главе 3 приведены спецификации алгоритмов контроля насыщения. Глава 4 посвящена ситуациям, связанным с алгоритмами контроля насыщения, а в главе 5 обсуждаются вопросы безопасности.

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

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

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

SEGMENT — сегмент

Сегментом является любой пакет данных или подтверждение TCP/IP.

SENDER MAXIMUM SEGMENT SIZE (SMSS) — максимальный размер сегмента для отправителя

SMSS представляет собой размер самого большого сегмента, который может быть передан отправителем. Это значение может определяться на основе максимального блока данных, передаваемого через сеть, алгоритма определения Path MTU [RFC1191, RFC4821], RMSS (см. следующее определение) и других факторов. Размер не включает заголовков и опций TCP/IP.

RECEIVER MAXIMUM SEGMENT SIZE (RMSS) — максимальный размер сегмента для получателя

RMSS — размер максимального сегмента, который желает принимать получатель. Это значение задается в опции MSS, передаваемой хостом при организации соединения. Если опция MSS при организации соединения не была задана, используется значение 536 байтов [RFC1122]. Размер не включает заголовков и опций TCP/IP.

FULL-SIZED SEGMENT — полноразмерный сегмент

Сегмент, содержащий максимально допустимое количество данных (т. е., SMSS байтов).

RECEIVER WINDOW (rwnd) — размер окна принимающей стороны

Последнее анонсированное значение размера окна принимающей стороны.

CONGESTION WINDOW (cwnd) — размер окна насыщения

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

INITIAL WINDOW (IW) — начальный размер окна

Начальным размером окна является размер окна насыщения отправителя после завершения трехэтапного согласования параметров.

LOSS WINDOW (LW) — размер окна потерь

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

RESTART WINDOW (RW) — размер окна перезапуска

Размер окна насыщения после того, как TCP возобновит передачу из состояния бездействия (для случая использования алгоритма slow start см. параграф 4.1).

FLIGHT SIZE — размер звена

Количество данных, которые уже переданы, но еще не подтверждены кумулятивно.

DUPLICATE ACKNOWLEDGMENT — дубликат подтверждения

Подтверждение считается «дубликатом» в описанных здесь алгоритмах, если (a) получатель ACK имеет остающиеся для передачи данные, (b) входящее подтверждение не содержит каких-либо данных, (c) оба флага SYN и FIN сброшены, (d) номер подтверждения равен или превышает значение наибольшего номера подтверждения, полученного в данном соединении (TCP.UNA из [RFC793]) и (e) анонсируемое во входящем подтверждении окно равно окну, анонсированному в последнем входящем подтверждении.

В дополнение к этому TCP, использующий селективные подтверждения (SACK⁶) [RFC2018, RFC2883], может применять информацию SACK для определения дубликатов подтверждений (содержит ли ACK ранее неизвестную информацию SACK).

3. Алгоритмы контроля насыщения

В этой главе определены четыре алгоритма контроля насыщения — slow start, congestion avoidance, fast retransmit и fast recovery, разработанные в [Jac88] и [Jac90]. В некоторых случаях для отправителя TCP предпочтительно быть более консервативным, нежели позволяют алгоритмы, но для TCP недопустимо быть более агрессивным, чем позволяют алгоритмы (т. е., недопустимо передавать данные, когда рассчитанное с помощью алгоритмов значение cwnd не разрешает передачу).

Отметим также, что описанные в этом документе алгоритмы рассчитаны на использование потери пакетов в качестве индикации перегрузки (насыщения). Можно также использовать механизм явных уведомлений о насыщении (ECN⁷), описанный в [RFC3168].

3.1 Алгоритмы Slow Start и Congestion Avoidance

Алгоритмы замедленного старта (slow start) и предотвращения перегрузки (congestion avoidance) должны использоваться отправителем TCP для контроля за передачей в сеть остающихся неотправленными данных. Для реализации этих алгоритмов в состояние соединения TCP добавлены две переменных — размер окна насыщения (cwnd) — задаваемый на стороне отправителя предел для количества данных, которые отправитель может передать в сеть до получения подтверждения (ACK), и анонсируемое получателем окно (rwnd), которое определяет установленный на приемной стороне предел размера остающихся данных. Передачей управляет меньшее из двух значений cwnd и rwnd.

Еще одна переменная состояния ssthresh⁸ используется для определения момента, когда следует использовать алгоритм замедленного старта или предотвращения перегрузки в соответствии с приведенными ниже описаниями.

Начало передачи в сеть с неизвестными условиями требует от TCP достаточно медленной проверки сети с целью определения доступной «емкости» для того, чтобы избежать насыщения сети избыточным потоком данных. Алгоритм slow start используется для решения этой задачи на начальном этапе передачи или после восстановления в результате потери пакетов, обнаруженной с помощью таймера повторной передачи. Этот алгоритм служит также для запуска процесса ACK-синхронизации, который используется отправителем TCP для отправки данных в сети при использовании алгоритмов замедленного старта, предотвращения перегрузки и восстановления после потерь.

IW — начальное значение cwnd — должно устанавливаться с использованием приведенных рекомендаций для максимального значение:

   Если SMSS > 2190 байтов
      IW = 2 * SMSS байтов; недопустимо превышать размер 2 сегментов
   Если (SMSS > 1095 байтов) и (SMSS <= 2190 байтов)
      IW = 3 * SMSS байтов; недопустимо превышать размер 3 сегментов
   Если SMSS <= 1095 байтов
      IW = 4 * SMSS байтов; недопустимо превышать размер 4 сегментов

Как сказано в [RFC3390], на основании SYN/ACK и подтверждения SYN/ACK недопустимо увеличивать размер окна насыщения. Более того, даже при потере SYN или SYN/ACK начальный размер окна, используемый отправителем после корректно переданного SYN должен быть равен одному сегменту, содержащему не более SMSS байтов.

Детальное обоснование и обсуждение установки значения IW приведено в работе [RFC3390]⁹.

Когда начальное окно размером более 1 сегмента реализуется вместе с Path MTU Discovery [RFC1191] и обнаружено, что используемое значение MSS слишком велико, значение окна насыщения cwnd следует уменьшить для предотвращения «выброса» большого числа мелких сегментов. Конкретно значение cwnd следует уменьшать SHOULD на отношение старого размера сегмента к новому размеру сегмента.

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

Алгоритм замедленного старта используется в тех случаях, когда cwnd < ssthresh, а при cwnd > ssthresh применяется алгоритм предотвращения перегрузки. Если cwnd = ssthresh отправитель может использовать любой из этих алгоритмов.

При замедленном старте TCP увеличивает размер окна cwnd не более, чем на SMSS байтов для каждого пакета ACK, кумулятивно подтверждающего доставку новой порции данных. Замедленный старт завершается, когда размер окна насыщения cwnd превышает порог ssthresh (или становится равным этому порогу), а также при возникновении перегрузки. Хотя традиционные реализации TCP увеличивают cwnd ровно на SMSS байтов при получении ACK, подтверждающего новые данные, рекомендуется увеличивать значение cwnd, как показано в уравнении

cwnd += min (N, SMSS) (2)

где N — число ранее не подтвержденных байтов, подтверждаемых входящим ACK. Это уточнение является частью процедуры Appropriate Byte Counting¹⁰ [RFC3465] и обеспечивает устойчивость к некорректному поведению получателей, которые могут пытаться спровоцировать отправителя на искусственное повышение cwnd с использованием механизма ACK Division [SCWA99]. Этот способ воздействия заключается в том, что получатель передает для одного сегмента данных TCP множество сегментов ACK, каждый из которых подтверждает только часть данных. В этом случае реализация TCP, увеличивающая cwnd на SMSS для каждого такого ACK будет недопустимо повышать объем данных, отправляемых в сеть.

В процессе предотвращения перегрузки размер окна cwnd увеличивается на 1 полноразмерный сегмент за каждый период кругового обхода RTT¹¹. Предотвращение насыщения продолжается до тех пор, пока насыщение наблюдается. Основными рекомендациями для увеличения cwnd при предотвращении перегрузки являются следующие:

можно увеличивать cwnd на SMSS байтов;
следует увеличивать cwnd в соответствии с уравнением (2) один раз за период RTT;
недопустимо увеличивать cwnd более, чем на SMSS байтов.

Отметим, что [RFC3465] разрешает увеличивать cwnd более, чем на SMSS байтов для входящих подтверждений в процессе замедленного старта в качестве экспериментов. Однако такое поведение недопустимо в качестве стандартного.

Рекомендуется увеличивать cwnd во время предотвращения перегрузки на число байтов, которые были подтверждены сегментами ACK для новых данных (недостатком этой рекомендации является необходимость поддержки дополнительной переменной состояния). Когда число подтвержденных данных достигает значения cwnd, последнее может быть увеличено на значение до SMSS байтов. Отметим, что в процесс предотвращения перегрузки недопустимо увеличивать размер окна насыщения более, чем на SMSS байтов за период RTT. Этот метод позволяет реализациям TCP увеличивать cwnd на 1 сегмент за период RTT в случаях задержки ACK и обеспечивает устойчивость к атакам Division.

Другим общепринятым способом, с помощью которого TCP может менять значение cwnd в процессе предотвращения перегрузки, является уравнение (3):

cwnd += SMSS*SMSS/cwnd (3)

Это изменение выполняется на каждый входящий сегмент ACK, который подтверждает новые данные. Уравнение (3) обеспечивает подходящее приближение для лежащего в основе принципа увеличения cwnd на 1 полноразмерный сегмент за период RTT (отметим, что для соединений, в которых получатель подтверждает каждый второй пакет, уравнение (3) обеспечивает менее агрессивное поведение — увеличение cwnd примерно на каждые два периода RTT).

Примечание для разработчиков. Поскольку в реализациях TCP обычно используется целочисленная арифметика, выражение (3) может не приводить к увеличению размера окна cwnd, когда окно насыщения очень велико (больше, чем SMSS*SMSS). Если выражение (3) дает нулевой результат, его следует «округлять» до 1 байта.

Примечание для разработчиков. В старых реализациях используется дополнительная положительная константа в правой части выражения (3). Такой подход некорректен и может вести к снижению производительности [RFC2525].

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

Когда отправитель TCP обнаруживает потерю сегмента с помощью таймера повтора передачи, для переменной ssthresh должно устанавливаться значение, не превышающее значение выражения 4:

ssthresh = max (FlightSize / 2, 2*SMSS) (4)

Как было отмечено выше, FlightSize показывает количество данных, которые еще находятся в сети (переданы, но не подтверждены).

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

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

Более того, при возникновении тайм-аута (как указано в [RFC2988]) необходимо устанавливать для размера окна насыщения cwnd значение, не превышающее размер окна потерь LW¹², которое равно 1 полноразмерному сегменту (независимо от значения IW). Следовательно, после повтора передачи отброшенного сегмента отправитель TCP использует замедленный старт для увеличения окна от 1 полноразмерного сегмента до нового значения ssthresh, после чего снова включается механизм предотвращения перегрузки.

Как показано в [FF96] и [RFC3782], основанное на замедленном старте восстановление после тайм-аута может приводить необоснованным повторам передачи, ведущей к дублированию подтверждений. Реакция на прием таких дубликатов ACK в реализациях TCP существенно различается. Этот документ не задает способа трактовки таких подтверждений, но здесь отмечается, что могут быть получены некоторые преимущества в результате проведения дополнительных исследований и спецификации такого поведения.

3.2 Алгоритмы Fast Retransmit и Fast Recovery

Получателю TCP следует незамедлительно передавать дубликат ACK при получении сегмента с нарушением порядка доставки. Это делается для того, чтобы с помощью пакета ACK информировать отправителя о том, что сегмент был получен с нарушением порядка и указать порядковый номер ожидаемого сегмента. С точки зрения отправителя дубликат ACK может быть вызван различными проблемами в сети. Во-первых, причиной может служить отбрасывание сегментов. В этом случае все сегменты после отброшенного будут порождать дубликаты ACK. Во-вторых, дубликаты ACK могут быть обусловлены нарушением порядка доставки сегментов (например, при доставке по разным путям [Pax97]). Наконец, причиной появления дубликатов ACK может быть репликация пакетов ACK или сегментов данных в сети. В дополнение к сказанному получателю TCP следует незамедлительно передавать подтверждение ACK при получении сегмента, который полностью или частично заполняет пропуски в порядковых номерах. Это позволит предоставить своевременную информацию отправителю, выполняющему восстановление после потери с использованием тайм-аута повторной передачи (retransmission timeout), быстрого повтора (fast retransmit) или улучшенного алгоритма восстановления (loss recovery), описанного в параграфе 4.3.

Отправителю TCP следует использовать алгоритм быстрого повтора для детектирования потери и исправления ошибки с использованием входящих дубликатов ACK. Алгоритм быстрого повтора использует прибытие 3 дубликатов ACK (как определено в параграфе 2, без каких-либо промежуточных сегментов ACK, вызывающих смещение SND.UNA), как индикацию потери сегмента. После получения 3 дубликатов ACK протокол TCP выполняет повторную передачу сегмента, который представляется потерянным, без ожидания завершения отсчета таймера повтора передачи.

После того, как алгоритм быстрого повтора передаст те данные, которые представляются включенными в отсутствующий сегмент, алгоритм «быстрого восстановления» (fast recovery) регулирует передачу новых данных, пока не будет получено подтверждение ACK, не являющееся дубликатом. Алгоритм замедленного старта не используется по той причине, что получение дубликатов ACK не только указывает на потерю сегмента, но и говорит о высокой вероятности того, что сегменты покинули сеть (хотя массированное дублирование сегментов в сети может сделать такое допущение некорректным). Иными словами, поскольку получатель может генерировать дубликат ACK только при получении сегмента, считается, что этот сегмент покинул сеть и находится в приемном буфере, более не потребляя ресурсов сети. Более того, поскольку «синхронизация» ACK сохраняется [Jac88], отправитель TCP может продолжать передачу новых сегментов (хотя и со сниженным значением cwnd).

Алгоритмы быстрого повтора и быстрого восстановления обычно реализуются вместе, как описано ниже.

При получении отправителем первого и второго дубликата ACK TCP следует передать сегмент не переданных ранее данных в соответствии с [RFC3042] — эта возможность обеспечивается тем, что при анонсируемом получателем окне приема выполняется условие FlightSize ≤ cwnd + 2*SMSS и имеются новые данные для передачи. В дальнейшем отправителю TCP недопустимо изменять значение cwnd для отражения этих двух сегментов [RFC3042]. Отметим, что отправителям, использующим SACK [RFC2018], недопустимо передавать новые данные, пока входящие дубликаты подтверждений содержат новую информацию SACK.
При получении третьего дубликата ACK TCP должен установить значение ssthresh, которое не превышает значения выражения (4). При использовании [RFC3042] ограниченную передачу дополнительных данных недопустимо учитывать в этом расчете.
Потерянный сегмент, начиная с SND.UNA, должен быть передан заново, а для cwnd устанавливается значение ssthresh + 3*SMSS. Это искусственно «увеличивает» размер окна насыщения на число сегментов (три), которые покинули сеть и буферизованы получателем.
Для каждого принятого дополнительного дубликата ACK (после третьего) значение cwnd должно увеличиваться на SMSS. Это искусственно увеличивает окно насыщения для того, чтобы отразить выход из сети дополнительных сегментов.

Примечание. В работе [SCWA99] рассмотрена атака со стороны получателя, в которой отправителю передается множество фальшивых дубликатов ACK с целью расширения cwnd и соответствующего повышения скорости отправки с передающей стороны. TCP может, следовательно, ограничивать кратность расширения cwnd в процессе восстановления после потерь до числа остающихся в сети сегментов (или близкого значения).

Примечание. Если расширенный механизм восстановления (типа описанного в параграфе 4.3) не используется, такое увеличение FlightSize может (в соответствии с уравнением (4)) вызывать незначительное расширение cwnd и ssthresh, поскольку несколько сегментов между SND.UNA и SND.NXT, предполагающиеся вышедшими из сети, по прежнему будут отражены в значении FlightSize.
При наличии новых не переданных данных, если позволяет новое значение cwnd и анонсированное получателем окно, TCP следует передать 1*SMSS байтов ранее не передававшихся данных.
При получении следующего пакета ACK, подтверждающего ранее не подтвержденные данные TCP должен установить cwnd = ssthresh (значение порога, заданное в п. 2). Это называется «уменьшением» размера окна насыщения.

Этому пакету ACK следует быть подтверждением, вызванным повтором в п. 3 в течение одного периода RTT после повтора (хотя подтверждение может прийти быстрей при наличии существенного нарушения порядка доставки сегментов данных на приемной стороне). Кроме того, этому пакету ACK следует подтверждать все промежуточные сегменты, переданные между потерянным сегментом и получением третьего дубликата ACK, если ни один из этих сегментов не был потерян.

Примечание: Известно, что этот алгоритм в общем случае не обеспечивает достаточно эффективного восстановления при множественных потерях в одном «звене¹³» пакетов [FF96]. Решение этой проблемы описана в параграфе 4.3.

4. Дополнительные вопросы

4.1 Перезапуск соединения

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

Документ [Jac88] рекомендует использовать замедленный старт для восстановления передачи после сравнительно долгого простоя. Замедленный старт позволяет восстановить ACK-синхронизацию, как это делается на начальном этапе работы соединения. Этот механизм довольно широко распространен и работает следующим образом. Когда TCP не получает сегмент в течение времени, превышающего тайм-аут повторной передачи, размер окна насыщения cwnd уменьшается до значения RW¹⁴ перед началом передачи.

В данном стандарте мы определяем RW = min(IW,cwnd).

Использование принятого последним сегмента для решения вопроса об уменьшении cwnd не приводит к снижению размера окна насыщения cwnd в распространенном случае для продолжительных соединений HTTP [HTH98]. В таких случаях Web-сервер получает запрос до передачи данных Web-клиенту. Получение запроса ведет к отрицательному результату при проверке бездействия соединения и позволяет TCP начать передачу со значением cwnd, которое может оказаться недопустимо большим.

Поэтому протоколу TCP следует устанавливать перед началом передачи для окна cwnd значение, не превышающее RW, если протокол TCP не передавал данных в течение времени, превышающего тайм-аут повтора передачи.

4.2 Генерация подтверждений

На приемной стороне следует использовать алгоритм задержки подтверждений, описанный в [RFC1122]. При использовании этого алгоритма для получателя недопустима избыточная задержка генерации подтверждений. В частности, пакеты ACK следует генерировать по крайней мере для каждого второго полноразмерного сегмента и генерация подтверждения должна происходить в течение не более 500 мсек с момента доставки первого неподтвержденного пакета.

Требование, в соответствии с которым пакеты ACK следует генерировать по крайней мере для каждого второго полноразмерного пакета, в документе [RFC1122] указано в одном месте как следует, в в другом – как должно. Ввиду неоднозначности мы будет использовать трактовку следует. Подчеркнем также, что уровень следует означает, что разработчик может отказаться от выполнения этого требования лишь после тщательной оценки возможных последствий. Обсуждение проблем, связанных с невыполнением требования генерации подтверждений не реже, чем для каждого второго полноразмерного сегмента, приводится в параграфе Stretch ACK violation документа [RFC2525].

В некоторых случаях между отправителем и получателем может отсутствовать согласие по поводу того, что собой представляет полноразмерный сегмент. Реализация протокола считается совместимой с требованиями этого параграфа, если она передает по крайней мере одно подтверждение каждый раз по получении 2*RMSS байтов новых данных от отправителя (RMSS – максимальный размер сегмента, указанный получателем отправителю, или принятое по умолчанию значение 536 байтов [RFC1122], если получатель не указал опцию MSS при организации соединения). Отправитель может быть вынужден использовать сегменты меньшего, чем RMSS, размера в результате ограничения MTU, path MTU или воздействия иных факторов. В качестве примера рассмотрим случай, когда получатель анонсирует RMSS = X, но отправитель использует сегменты меньшего размера Y (Y < X) вследствие ограничения path MTU или значения MTU на стороне отправителя. Получатель будет генерировать подтверждения ACK более редко, если он будет дожидаться доставки 2*X перед генерацией ACK. Очевидно, что подтверждения для 2 сегментов по Y байтов передавались бы чаще. Следовательно, несмотря на то, что не определен специфический алгоритм, для получателя желательно попытаться предотвратить подобные ситуации (например, путем подтверждения каждого второго сегмента независимо от их размера). Повторим еще раз, что недопустима задержка передачи ACK более чем на 500 мсек в результате ожидания доставки второго полноразмерного сегмента.

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

Для получателя TCP недопустимо генерировать более одного подтверждения ACK для каждого входящего сегмента, если это подтверждение не является обновлением предлагаемого размера окна в тех случаях, когда принимающее приложение забирает новые данные [[RFC813] и стр. 42[RFC793].

4.3 Механизмы восстановления при потерях

Исследователями TCP было предложено и опубликовано в RFC множество алгоритмов восстановления при потере сегментов, повышающих эффективность работы алгоритмов fast retransmit и fast recovery. Некоторые из таких алгоритмов (например, [FF96], [MM96a], [MM96b] b [RFC3517]) основаны на использовании опции селективных подтверждений (SACK¹⁵) [RFC2018], а для других (например, [Hoe96], [FF96] и [RFC3782]) SACK не требуется. Алгоритмы, работающие без SACK, используют «частичные подтверждения¹⁶» (пакеты ACK, которые подтверждают новые данные, но не подтверждают пропущенные при наличии потерь) для включения механизма повтора передачи. Хотя данный документ не стандартизует ни один из алгоритмов, которые могут повышать эффективность fast retransmit/fast recovery, такие алгоритмы неявно разрешены, если они соответствуют общим принципам базовых алгоритмов, описанных выше.

Т. е., при обнаружении первой потери в окне для ssthresh должно быть установлено значение, не превышающее значение уравнения (4). Далее, пока все сегменты в окне данных не будут восстановлены, число сегментов, передаваемых в течение каждого периода RTT, должно быть не более половины от числа остававшихся на момент обнаружения потери сегментов. И, наконец, после успешной передачи всех потерянных сегментов в данном окне для параметра cwnd должно быть установлено значение, не превышающее ssthresh, и для дальнейшего увеличения cwnd должен использоваться механизм предотвращения перегрузки. Потери в двух последовательных окнах данных или потерю при повторе передачи следует трактовать как двухкратную индикацию насыщения и, следовательно, значения cwnd и ssthresh должны в таких случаях уменьшаться дважды.

Мы рекомендуем разработчикам реализаций TCP применять ту или иную форму улучшенного восстановления после потерь, способную справиться с множественными потерями в одном окне данных. Алгоритмы, описанные подробно в [RFC3782] и [RFC3517] соответствуют приведенным выше общим принципам. Отметим, что набор соответствующих общим принципам алгоритмов не исчерпывается двумя указанными, однако эта пара алгоритмов была проверена на практике и в настоящее время стандартизуется.

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

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

С учетом атак ACK division, описанных в [SCWA99], данная спецификация рекомендует увеличивать размер окна насыщения на основе числа байтов, недавно подтвержденных в каждом поступающем сегменте ACK вместо увеличения на постоянное значение при каждом поступлении сегмента ACK (как описано в параграфе 3.1).

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

6. Различия между RFC 2001 и RFC 2581

[RFC2001] был подвергнут существенной редакторской правке, не позволяющей, по сути, создать список различий между [RFC2001] и [RFC2581]. Целью подготовки [RFC2581] было не изменение рекомендаций, содержащихся в [RFC2001], а разъяснение вопросов, которые не были детально рассмотрены в [RFC2001]. В частности, [RFC2581] содержит рекомендации в части поведения соединений TCP после сравнительно долгого бездействия, а также спецификации и разъяснения по некоторым вопросам генерации TCP ACK. Кроме того, была вдвое (с одного сегмента до 2) увеличена верхняя граница начального размера окна насыщения.

7. Отличия от RFC 2581

Добавлено определение дубликатов подтверждений на основе определения, используемого в BSD TCP.

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

Изменены требования к начальному размеру окна, чтобы позволить больший размер¹⁷, стандартизованный в [RFC3390]. В дополнение к этому было детализировано поведение для случаев, когда значение начального размера окна оказывается слишком большим в результате определения Path MTU [RFC1191].

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

В процессе замедленного старта явно рекомендовано использование Appropriate Byte Counting [RFC3465] с L=1*SMSS. Метод увеличения cwnd, заданный в [RFC2581], по-прежнему явно допускается. Рекомендуется использовать подсчет байтов в процессе предотвращения перегрузки (congestion avoidance), хотя метод из [RFC2581] и другие безопасные методы остаются допустимыми.

Прояснена трактовка ssthresh при тайм-ауте повтора передачи. В частности, указано, что при первом повторе передачи данного сегмента для ssthresh должно устанавливаться значение, равное половине FlightSize, которое остается постоянным в случае дополнительных повторов передачи того же сегмента.

Разъяснено описание ускоренного повтора (fast retransmit) и ускоренного восстановления (fast recovery), а также рекомендовано применение ограниченной передачи¹⁸ [RFC3042].

Реализациям TCP можно ограничивать число дубликатов ACK, которые могут искусственно завышать значение cwnd при восстановлении в случаях потери, числом сегментов, остающихся для передачи, с целью предотвращения атак на базе обманных подтверждений, описанных в [SCWA99].

Изменено значение окна при перезапуске (restart window) с IW на min(IW,cwnd). Такое поведение было отмечено в [RFC2581], как экспериментальное.

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

Обновлено рассмотрение вопросов безопасности с учетом атак ACK division и рекомендацией использовать подсчет байтов для предотвращения таких атак.

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

Основные алгоритмы, описанные здесь, разработал Van Jacobson [Jac88, Jac90]. В дополнение к ним совместно с Hari Balakrishnan и Sally Floyd был разработан алгоритм Limited Transmit¹⁹ [RFC3042]. Начальное значение окна насыщения, указанное в этом документе, получено в результате работы с Sally Floyd и Craig Partridge [RFC2414, RFC3390].

W. Richard (Рич) Stevens написал первую версию этого документа [RFC2001] и был соавтором второй версии [RFC2581]. В настоящем документе многие вопросы были разъяснены, благодаря вкладу Рича в понимание контроля насыщения TCP, а также его помощи по многим вопросам, относящимся к сетям.

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

Часть текста данного документа заимствована из книг «TCP/IP Illustrated, Volume 1: The Protocols» Ричарда Стивенса (W. Richard Stevens) (Addison-Wesley, 1994) и «TCP/IP Illustrated, Volume 2: The Implementation» Гери Райта (Gary R. Wright) и Ричарда Стивенса (Addison-Wesley, 1995). Этот материал включен с разрешения издательства Addison-Wesley.

Anil Agarwal, Steve Arden, Neal Cardwell, Noritoshi Demizu, Gorry Fairhurst, Kevin Fall, John Heffner, Alfred Hoenes, Sally Floyd, Reiner Ludwig, Matt Mathis, Craig Partridge и Joe Touch внесли множество полезных предложений.

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

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

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

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

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

[CJ89] Chiu, D. and R. Jain, «Analysis of the Increase/Decrease Algorithms for Congestion Avoidance in Computer Networks»²¹, Journal of Computer Networks and ISDN Systems, vol. 17, no. 1, pp. 1-14, June 1989.

[FF96] Fall, K. and S. Floyd, «Simulation-based Comparisons of Tahoe, Reno and SACK TCP», Computer Communication Review, July 1996, ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.

[Hoe96] Hoe, J., «Improving the Start-up Behavior of a Congestion Control Scheme for TCP»²², In ACM SIGCOMM, August 1996.

[HTH98] Hughes, A., Touch, J., and J. Heidemann, «Issues in TCP Slow-Start Restart After Idle», Work in Progress, March 1998.

[Jac88] Jacobson, V., «Congestion Avoidance and Control», Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

[Jac90] Jacobson, V., «Modified TCP Congestion Avoidance Algorithm», end2end-interest mailing list, April 30, 1990. ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.

[MM96a] Mathis, M. and J. Mahdavi, «Forward Acknowledgment: Refining TCP Congestion Control», Proceedings of SIGCOMM’96, August, 1996, Stanford, CA. Доступна по ссылке http://www.psc.edu/networking/papers/papers.html

[MM96b] Mathis, M. and J. Mahdavi, «TCP Rate-Halving with Bounding Parameters», Technical report. Доступна по ссылке http://www.psc.edu/networking/papers/FACKnotes/current.

[Pax97] Paxson, V., «End-to-End Internet Packet Dynamics»²⁴, Proceedings of SIGCOMM ’97, Cannes, France, Sep. 1997.

[RFC813] Clark, D., «Window and Acknowledgement Strategy in TCP», RFC 813, July 1982.

[RFC2001] Stevens, W., «TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms», RFC 2001, January 1997.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018¹, October 1996.

[RFC2414] Allman, M., Floyd, S., and C. Partridge, «Increasing TCP’s Initial Window», RFC 2414, September 1998.

[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, «Known TCP Implementation Problems», RFC 2525, March 1999.

[RFC2581] Allman, M., Paxson, V., and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, «An Extension to the Selective Acknowledgement (SACK) Option for TCP», RFC 2883, July 2000.

[RFC2988] Paxson, V. and M. Allman, «Computing TCP’s Retransmission Timer», RFC 2988, November 2000.

[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, «Enhancing TCP’s Loss Recovery Using Limited Transmit», RFC 3042, January 2001.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC3390] Allman, M., Floyd, S., and C. Partridge, «Increasing TCP’s Initial Window», RFC 3390, October 2002.

[RFC3465] Allman, M., «TCP Congestion Control with Appropriate Byte Counting (ABC)», RFC 3465, February 2003.

[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, «A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP», RFC 3517, April 2003.

[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, «The NewReno Modification to TCP’s Fast Recovery Algorithm», RFC 3782, April 2004.

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, March 2007.

[SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, «TCP Congestion Control With a Misbehaving Receiver»²⁵, ACM Computer Communication Review, 29(5), October 1999.

[Ste94] Stevens, W., «TCP/IP Illustrated, Volume 1: The Protocols», Addison-Wesley, 1994.

[WS95] Wright, G. and W. Stevens, «TCP/IP Illustrated, Volume 2: The Implementation», Addison-Wesley, 1995.

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

Mark Allman

International Computer Science Institute (ICSI)

1947 Center Street

Suite 600

Berkeley, CA 94704-1198

Phone: +1 440 235 1792

EMail: mallman@icir.org

http://www.icir.org/mallman/

Vern Paxson

International Computer Science Institute (ICSI)

1947 Center Street

Suite 600

Berkeley, CA 94704-1198

Phone: +1 510/642-4274 x302

EMail: vern@icir.org

http://www.icir.org/vern/

Ethan Blanton

Purdue University Computer Sciences

305 North University Street

West Lafayette, IN 47907

EMail: eblanton@cs.purdue.edu

http://www.cs.purdue.edu/homes/eblanton/

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

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

электронная почта: nmalykh@protokols.ru

сайт: http://www.nmalykh.org

1При переводе термина “congestion” термин “перегрузка” использовался наряду с термином “насыщение”. Прим. перев.

2Замедленный старт.

3Предотвращение насыщения.

4Ускорение повторной передачи.

5Ускоренное восстановление.

6Selective acknowledgment.

7Explicit Congestion Notification.

8Порог замедленного старта.

9В RFC Errata предложено дополнение этого абзаца, содержащее следующий текст: «Значение IW для случаев, когда 1095 < SMSS ≤ 2190 байтов, будет отличаться от рекомендаций [RFC3390]. Новое определение будет сохранять предшествующее значение cwnd, кратное SMSS, и предотвращать передачу неполных сегментов.». Прим. перев.

10Appropriate Byte Counting — подходящий учет байтов.

11Round-trip time.

12Loss window.

13Группа пакетов, одновременно находящихся в сети между отправителем и получателем. Прим. перев.

14Restart window – окно рестарта.

15TCP selective acknowledgment.

16Partial acknowledgment.

17Larger Initial Window.

18Строго говоря, явная рекомендация использования «» в документе отсутствует. В параграфе 3.2 лищь сказано: «При использовании [RFC3042] ограниченную передачу дополнительных данных недопустимо учитывать в этом расчете.». Прим. перев.

19Ограниченная передача.

21Эта статья доступна по ссылке http://pages.cs.wisc.edu/~suman/courses/740/papers/chiu89isdn.pdf. Прим. перев.

22Эта статья доступна по ссылке http://conferences.sigcomm.org/sigcomm/1996/papers/hoe.pdf. Прим. перев.

24Эта статья доступна по ссылке http://conferences.sigcomm.org/sigcomm/1997/papers/p086.pdf. Прим. перев.

25Эта статья доступна по ссылке http://www.cs.washington.edu/homes/tom/pubs/CCR99.pdf. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)

Опубликовано 25.08.2009 автором Nikolai Malykh

Network Working Group                                          A. Morton
Request for Comments: 5618                                     AT&T Labs
Updates: 5357                                                 K. Hedayat
Category: Standards Track                                           EXFO
                                                             August 2009

Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)

Смешанный режим защиты для протокола TWAMP

PDF

Аннотация

Этот документ описывает простое расширение протокола двухстороннего активного измерения (Two-Way Active Measurement Protocol или TWAMP), добавляющее опция использования различных механизмов защиты в протоколах TWAMP-Control и TWAMP-Test одновременно. Документ также описывает новый ррестр IANA для дополнительных функций (TWAMP Modes).

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

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

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

1. Введение

Протокол TWAMP [RFC5357] является расширением протокола односторонних активных измерений (One-Way Active Measurement Protocol или OWAMP) [RFC4656]. Спецификация TWAMP прошла широкое обсуждение, в процессе которого были предложены несколько рекомендаций по новым функциям TWAMP. В настоящее время число реализаций TWAMP растет и ожидается их широкое использование. Разработаны даже устройства, предназначенные для проверки соответствия реализаций протоколу.

В этом документе описано простое расширение TWAMP — опция для использования разных режимов защиты в протоколах TWAMP-Control и TWAMP-Test (смешанная защита). Документ также описывает новый реестр IANA для дополнительных функций, названный TWAMP Modes.

Когда Server и Control-Client согласовали использование смешанного режима защиты в процессе организации соединения, Control-Client, Server, Session-Sender и Session-Reflector должны соответствовать требованиям к этому режиму, указанным в разделах 3 — 5.

Этот документ обновляет [RFC5357].

1.1. Уровни требований

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

2. Назначение и область действия

Назначение этого документа состоит в описании и спецификации расширения для протокола TWAMP [RFC5357] и запросе на создание реестра для будущих расширений TWAMP.

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

Расширение режимов работы путем выделения нового значения поля Modes (параграф 3.1 в [RFC4656]) при сохранении совместимости с имеющимися реализациями TWAMP [RFC5357]. Это значение добавляет необязательную возможность применять разные режимы защиты для протоколов TWAMP-Control и TWAMP-Test. Расширение предназначено для обеспечения протоколу TWAMP-Control, имеющему низкую скорость передачи пакетов, возможности применять более строгую защиту по сравнению с используемой TWAMP-Test.

3. Расширения TWAMP-Control

Протокол TWAMP-Control основан на OWAMP-Control и координирует двухсторонние измерения. Все сообщения TWAMP-Control, за исключением отмеченных в TWAMP [RFC5357] и последующих параграфах, похожи по формату на сообщения, определенные в разделе 3 [RFC4656], и следуют рекомендациям указанного документа.

Все сообщения OWAMP-Control, за исключением команды Fetch-Session, применимы к протоколу TWAMP-Control.

3.1. Организация расширенного управляющего соединения

При организации управляющих соединений TWAMP-Control используется процедура, описанная в параграфе 3.1 [RFC4656]. Это расширенный режим использует дополнительный бит, позволяющий разрешить протоколу TWAMP-Test работать в режме без аутентификации (Unauthenticated), тогда как протокол TWAMP-Control работает в режиме с шифрованием (Encrypted). Полный набор значений TWAMP Mode с учетом этого расширения показан в таблице.

Значение	Описание	Определение семантики
0	Резерв
1	Unauthenticated	RFC 4656, параграф 3.1
2	Authenticated	RFC 4656, параграф 3.1
4	Encrypted	RFC 4656, параграф 3.1
8	Unauthenticated для протокола Test, Encrypted для Control	Новая битовая позиция (3)

В исходном поле Modes протоколов OWAMP и TWAMP установка бита 0, 1 или 2 задает режим защиты для протокола управления (Control), а протокол тестирования (Test) наследует этот режим (раздел 4 в [RFC4656]).

В этом расширении TWAMP при установке клиентом (Control-Client) в поле Modes битп 3, клиенту нужно предотвратить наследование режима защиты протоколом Test, при этом для каждого из протоколов нужно устанавливать режим в соответствии с приведенным ниже описанием. Если для протокола TWAMP-Test нужен такой же режим защиты как для сеанса управления, клиенту нужно устанавливать соответствующий режим (биты 0 — 2) в поле Modes. Приведенная ниже таблица показывает различные комбинации режимов защиты целостности, доступные в TWAMP с этим расширением. Протоколам TWAMP-Control и TWAMP-Test нужно применять режим, указанный в столбце, соответствующем битам поля Modes.

Протокол	Возможные комбинации режимов (биты Modes)
Control	Unauthenticated (0)	Authenticated == Encrypted (1,2,3)
Test	Unauthenticated (0)	Unauthenticated (3)
		Authenticated (1)
		Encrypted (2)

Отметим, что меры защиты протокола TWAMP-Control идентичны в режимах Authenticated и Encrypted, поэтому для смешанного режима достаточно одной битовой позиции (3).

Значение поля Modes передаются сервером в сообщении Server-Greeting как результат объединения (OR) битов для режимов, которые будут поддерживаться в этой сессии. В результате используются 4 последних бита 32-битового поля Modes. Когде ни используется никаких иных функций, первые 28 битов должны быть сброшены (0). Клиент, соответствующий данному расширению [RFC5357], может игнорировать первые 28 битов поля Modes или может поддерживать другие функции, указываемые этими битами.

Другие способы расширения в TWAMP протокола OWAMP описаны в [RFC5357].

4. Расширенный протокол TWAMP-Test

Протокол TWAMP-Test подобен OWAMP-Test [RFC4656] за исключением того, что Session-Reflector передает пакеты отправителю (Session-Sender) в ответ на каждый принятый пакет. TWAMP [RFC5357] определяет два формата тестовых пакетов, один из которых использует при передаче Session-Sender, другой — Session-Reflector. Как и в протоколе OWAMP-Test, здесь поддерживается 3 режима защиты, которые влияют на формат пакетов, — без аутентификации, с аутентификацией и с шифрованием. Данное расширение TWAMP делает возможным использование режима TWAMP-Test Unauthenticated независимо от режима протокола TWAMP-Control.

Это расширение требуется, когда Server указал возможность поддержки смешанного режима защиты, Control-Client выбрал этот режим в своем сообщении Set-Up-Response и сервер ответил сообщением Server-Start с Accept = 0.

4.1. Поведение отправителя

В этом параграфе описаны расширения в поведении TWAMP Session-Sender.

4.1.1. Тактирование пакетов

Планирование передачи не применяется в TWAMP и этот документ не задает расширений.

4.1.2. Формат и содержимое пакетов

Формат и содержимое пакетов Session-Sender должны следовать процедуре и рекомендациям параграфов 4.1.2 в [RFC4656] и 4.1.2 в [RFC5357] с учетом отмеченных ниже исключений:

планирование передачи не применяется;
Session-Sender должен поддерживать смешанный режим (Unauthenticated TEST, Encrypted CONTROL, значение 8, бит 3), определенный в параграфе 3.1 этого документа.

4.2. Поведение рефлектора

От TWAMP Session-Reflector требуется следовать процедуре и рекомендациям параграфа 4.2 в [RFC5357] с одним исключением:

Session-Reflector должен поддерживать смешанный режим (Unauthenticated TEST, Encrypted CONTROL, значение 8, бит 3), определенный в параграфе 3.1 этого документа.

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

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

К этому документу применимы вопросы безопасности, связанные с активными измерениями в работающих сетях (см. [RFC4656] и [RFC5357]).

6. Взаимодействие с IANA

Этот документ добавляет бит (и значение) выбора режима защиты в дополнение к указанным в спецификации OWAMP-Control [RFC4656] и определяет поведение при использовании этого режима. В соответствии с этим документом создан реестр IANA для поля TWAMP Modes, признанного механизмом расширения для протокола TWAMP.

6.1. Спецификация реестра

Агентство IANA создало реестр TWAMP Modes. Значение TWAMP Modes указывается в сообщениях TWAMP Server Greeting и Set-up Response, соответствующих параграфам 3.1 в [RFC4656] и 3.1 в [RFC5357] и расширенных этим документом. Режимы в настоящее время устанавливаются отдельными битами 32-битового поля Modes. Однако в будущем кодирование может быть усложнено. Таким образом, реестр может включать до 2³² разных значений.

6.2. Управление реестром

Поскольку реестр TWAMP Modes может включать до 2³² значений, а TWAMP является протоколом IETF, обновление реестра выполняется по процедуре IETF Review, описанной в [RFC5226] (RFC с документированием использования реестра, одобренный IESG). Для реестра TWAMP Modes предполагается выделение значений с ростом битовой позиции (0-31), если не будет веской причины использовать другой подход (более сложное кодирование, которое может быть выбрано в будущем для доступа ко всему пространству из 2³² значений).

6.3. Экспериментальные значения

В настоящее время реестр Modes не включает экспериментальных значений.

6.4. Начальное содержимое реестра

Реестр TWAMP Modes показан в таблице.

Значение	Описание	Определение семантики
0	Резерв	RFC 5618
1	Unauthenticated	RFC 4656, параграф 3.1
2	Authenticated	RFC 4656, параграф 3.1
4	Encrypted	RFC 4656, параграф 3.1
8	Unauthenticated TEST, Encrypted CONTROL	RFC 5618, параграф 3.1

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

Авторы благодарят Len Ciavattone и Joel Jaeggli за полезные комментарии и рецензии.

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

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

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, September 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, October 2008.

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

Al Morton

AT&T Labs

200 Laurel Avenue South

Middletown, NJ 07748

USA

Phone: +1 732 420 1571

Fax: +1 732 368 1192

EMail: acmorton@att.com

URI: http://home.comcast.net/~acmacm/

Kaynam Hedayat

EXFO

285 Mill Road

Chelmsford, MA 01824

USA

Phone: +1 978 367 5611

Fax: +1 978 367 5700

EMail: kaynam.hedayat@exfo.com

URI: http://www.exfo.com/

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

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

nmalykh@protokols.ru

Рубрика: RFC | Комментарии отключены

RFC 5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)

Опубликовано 27.06.2009 автором Nikolai Malykh

Network Working Group                                         M. Thomson
Request for Comments: 5573                                        Andrew
Category: Experimental                                         June 2009

Асинхронные каналы для протокола BEEP

Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)

PDF

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

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

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

Аннотация

Протокол BEEP¹ обеспечивает протокольную модель для разработки прикладных протоколов. В этом документе определяется функция (свойство) BEEP, обеспечивающая асинхронный обмен для отдельных каналов.

1. Введение

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

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

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

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

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

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

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

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

2. Асинхронные каналы BEEP

Этот документ определяет функцию BEEP, позволяющую применять асинхронные каналы. Асинхронным каналом является канал BEEP, к которому не применяются ограничения параграфа 2.6.1 из [RFC3080] в части упорядочения откликов. Запросы могут обрабатываться, а отклики на них передаваться обслуживающим партнером в любом порядке.

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

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

2.1. Асинхронная функция

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

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

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

L: <ожидание входящего соединения>
I: <организация соединения>
L: RPY 0 0 . 0 133
L: Content-Type: application/beep+xml
L:
L: <greeting features="async x-foo">
L:    <profile uri="http://example.com/beep/APP" />
L: </greeting>
L: END
I: RPY 0 0 . 0 69
I: Content-Type: application/beep+xml
I:
I: <greeting features="async" />
I: END

Рисунок 1. Приветствие BEEP с асинхронной функцией.

Регистрационный шаблон для функций BEEP приведен в разделе 5.

2.2. Организация асинхронного канала

Для создания асинхронного канала параметр async=true включается в запрос start. Если параметр опущен или установлено значение false, канал не будет асинхронным.

На рисунке 2 показано как можно использовать атрибут async для старта асинхронного канала.

C: MSG 0 1 . 52 130
C: Content-Type: application/beep+xml
C:
C: <start number="1" async="true">
C:    <profile uri="http://example.org/protocol"/>
C: </start>
C: END
S: RPY 0 1 . 221 102
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://example.org/protocol"/>
S: END

Рисунок 2. Старт асинхронного канала.

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

C: MSG 0 1 . 52 128
C: Content-Type: application/beep+xml
C:
C: <start number="1" async="true">
C:    <profile uri="http://example.org/serial"/>
C: </start>
C: END
S: ERR 0 1 . 221 152
S: Content-Type: application/beep+xml
S:
S: <error code="553">Profile &lt;http://example.org/serial&gt;
S: cannot be used for asynchronous channels.</error>
S: END

Рисунок 3. Ошибка при старте асинхронного канала.

2.3. Поведение асинхронного канала

Асинхронный канал отличается от обычных каналов BEEP лишь в том, что к нему не применяются ограничения параграфа 2.6.1 из [RFC3080] в части порядка обработки и откликов. Обслуживающий партнер может обрабатывать запросы и отвечать на них в выбранном им порядке.

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

Сообщения MSG, переданные в асинхронный канал, могут параллельно обрабатываться обслуживающим партнером. Отклики (сообщения RPY, ANS, NUL, ERR) могут передаваться в любом порядке. Разные сообщения ANS, передаваемые в обменах «один со многими», могут чередоваться с другими сообщениями MSG.

Асинхронный канал должен соблюдать правила [RFC3080] в части сегментированных сообщений. Каждое сообщение должно быть завершено до того, как можно будет передать через тот же канал другое сообщение.

Примечание. Исключение из этого правила сделано в [RFC3080] для чередующихся сегментов ANS, передаваемых в ответ на одно сообщение MSG. Партнерам BEEP рекомендуется не генерировать чередующихся сегментов ANS.

Канал управления BEEP (канал 0) никогда не бывает асинхронным.

2.4. Обработка ошибок

BEEP не предоставляет никакого механизма для управления узлом, не отвечающим на запрос. Синхронные каналы невозможно использовать и даже закрыть, если партнер не предоставляет отклика на запрос. Единственным доступным способом остается разрыв транспортного соединения. Хотя асинхронный канал невозможно закрыть, он все еще может использоваться для дальнейших запросов. Однако остающиеся запросы продолжают потреблять ресурсы состояний. Партнеры-клиенты могут избавиться от таких состояний по истечении настроенного интервала, но должны быть готовы отказаться в таких случаях от нераспознанных откликов.

3. Альтернативы

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

3.1. Повышение пропускной способности

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

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

Окно управления потоком данных, применяемое в отображении TCP [RFC3081] может вносить ограничения на пропускную способность отдельных каналов. Выбор размера окна TCP также ограничивает пропускную способность (см. [RFC1323]). Чтобы избежать ограничений, принимающие партнеры могут увеличивать окно, а передающие партнеры могут создавать дополнительные каналы с тем же профилем. Корректное управление потоком данных также применимо к асинхронным каналам.

3.2. Асинхронность в прикладном протоколе

При внесении изменений в прикладные протоколы последовательные канала можно использовать для асинхронного обмена. Асинхронность может быть обеспечена на уровне протокола выше BEEP путем разделения запросов и откликов. Это требует добавления фирменных заголовков MIME или изменения прикладного протокола.

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

Этот метод не является предпочтительным, поскольку требует от прикладного протокола решать задачу сопоставления откликов с запросами. BEEP стремится обеспечить основу для создания прикладного протокола и отсутствие сопоставления откликов с запросами будет ограничивать его полезность. Использования заголовка MIME возможно, но msgno обеспечивает более элегантное решение.

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

Разрешение асинхронного обмена сообщениями для канала потенциально требует поддержки дополнительной информации о состоянии. Не отвечающий на сообщения обслуживающий партнер может вызвать скопление состояний на стороне партнера-клиента. Если такая информация о состоянии не была ограничена, это может быть использовано для DoS²-атаки. Эта проблема уже имеется в BEEP, но ее значение возрастает из-за характера обработки на обслуживающем узле запросов, полученных по асинхронному каналу. Уровень отказов в обслуживании ограничен тем, что воспринимает обслуживающий партнер — число остающихся не выполненными до конца запросов можно ограничить для защиты от накопления избыточных данных о состоянии.

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

Узлы, обслуживающие запросы на асинхронных каналах, также накапливают информацию о состоянии при восприятии запроса для обработки. Обслуживающие узлы тоже могут ограничивать число одновременно обрабатываемых запросов. По достижении заданного предела принимающий партнер может остановить считывание новых запросов или начать отклонять их, возвращая сообщения об ошибках. Дополнительно может применяться управление потоком данных [RFC3081] — кадры SEQ могут быть подавлены, что позволит закрыть окно управления потоком данных и предотвратить получение новых запросов.

5. Взаимодействие с IANA

Этот раздел регистрирует функцию BEEP async в реестре параметров BEEP в соответствии с шаблоном, представленным в параграфе 5.2 [RFC3080].

Идентификация функции — async

Семантика функции — эта функция позволяет создавать асинхронные каналы (см. раздел 2 в RFC 5573).

Контактные данные — Martin Thomson <martin.thomson@andrew.com>

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

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

[RFC3080] Rose, M., «The Blocks Extensible Exchange Protocol Core», RFC 3080, March 2001.

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

[RFC3081] Rose, M., «Mapping the BEEP Core onto TCP», RFC 3081, March 2001.

[RFC1323] Jacobson, V., Braden, B., and D. Borman, «TCP Extensions for High Performance», RFC 1323, May 1992.

Адрес автора

Martin Thomson

Andrew

PO Box U40

Wollongong University Campus, NSW 2500

Phone: +61 2 4221 2915

EMail: martin.thomson@andrew.com

URI: http://www.andrew.com/

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

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

nmalykh@gmail.com

1Blocks Extensible Exchange Protocol — расширяемый протокол обмена блоками.

2Denial of service — отказ в обслуживании.

Рубрика: RFC | Комментарии отключены

RFC 5586 MPLS Generic Associated Channel

Опубликовано 25.06.2009 автором Nikolai Malykh

Network Working Group                                      M. Bocci, Ed.
Request for Comments: 5586                             M. Vigoureux, Ed.
Updates: 3032, 4385, 5085                                 Alcatel-Lucent
Category: Standards Track                                 S. Bryant, Ed.
                                                           Cisco Systems
                                                               June 2009

Связанный канал MPLS

MPLS Generic Associated Channel

PDF

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

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

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

Аннотация

Этот документ обобщает применимость заголовков связанных каналов псевдопровода (PW ACH¹), разрешая реализацию канала управления, связанного с MPLS LSP² и MPLS Section в дополнение к MPLS pseudowire. Для идентификации присутствия заголовка ACH в стеке меток данный документ выделяет одну из резервных меток MPLS в качестве GAL³ для использования в качестве механизма исключения по меткам.

1. Введение

Существует потребность в механизмах OAM⁴, пригодных для обнаружения отказов, диагностики, поддержки и других функций на псевдопроводах (PW) и путях с коммутацией по меткам (LSP). Эти функции могут применяться между любыми двумя маршрутизаторами LER/LSR⁵ или T-PE/S-PE⁶ на пути LSP или PW, соответственно [MPLS-TP]. Некоторые из таких функций могут поддерживаться с использованием имеющихся средств типа VCCV⁷ [RFC5085], BFD-MPLS⁸ [BFD-MPLS], LSP-Ping [RFC4379], BFD-VCCV [BFD-VCCV]. Однако были отмечены требования в части усиления этого набора функций поддержки и, в частности, при использовании сетей MPLS для услуг доставки пакетов и операций транспортных сетей [OAM-REQ]. Примеры таких функций включают мониторинг производительности, автоматическую защитную коммутацию, а также поддержку коммуникационных каналов для сигнализации и управления. Такие средства должны быть подходящими и работать одинаково (с операционной точки зрения) для MPLS PW, MPLS LSP и MPLS Section. Они также должны работать в основной полосе (in-band) PW или LSP, чтобы не зависеть от маршрутизации PSN⁹ или пользовательского трафика, зависимость от функций динамического уровня управления недопустима.

VCCV [RFC5085] может использовать ACH¹⁰ для обеспечения связанного с PW канала управления между конечными точками PW, через который будут передаваться сообщения OAM и другие управляющие сообщения. Этот документ обобщает применимость ACH для обеспечения возможности применения того же механизма связанного канала управления, который применяется для Section, LSP и PW. Обобщенный связанный канал управления называется G-ACh¹¹. ACH, описанные в RFC 4385 [RFC4385], могут применяться с дополнительными кодами для поддержки добавочных функций поддержки MPLS через G-ACh.

Обобщение применимости ACH к LSP и Sections также требует метода идентификации пакетов, в которых за ACH следуют не относящиеся к сервису данные (non-service payload). Следовательно, этот документ определяет также механизм исключения на основе меток, который служит для информирования LSR (или LER) о том, что пакет, полученный в LSP или Section, относится к связанному каналу управления. Используемая для этого метка относится к резервным меткам MPLS и обозначается GAL¹². Механизм GAL определен для использования с ACH на LSP и MPLS Section.

RFC 4379 [RFC4379] и BFD-MPLS [BFD-MPLS] определяют сигнальные механизмы, которые позволяют MPLS LSR идентифицировать и обрабатывать пакеты MPLS OAM, инкапсулированные в заголовки IP. Эти сигнальные механизмы базируются, например, на завершении времени жизни (TTL¹³) и/или использовании IP-адреса получателя из блока 127.0.0.0/8 или 0:0:0:0:0:FFFF:127.0.0.0/104 для IPv4 и IPv6, соответственно. Эти механизмы используются по умолчанию для идентификации пакетов MPLS OAM, инкапсулированных в заголовок IP. Однако использование этих механизмов не всегда возможно для некоторых приложений MPLS — например, для MPLS Transport Profile (MPLS-TP) [MPLS-TP], особенно при невозможности использования демультиплексирования по IP. Данный документ определяет механизм, рекомендуемый для идентификации и инкапсуляции MPLS OAM и других управляющих сообщений при недоступности механизмов на базе IP типа тех, которые применяются в [RFC4379] и [BFD-MPLS]. Этот механизм может служить и дополнением к механизмам, основанным на IP.

Отметим, что функции и пакеты управления, описываемые в этом документе, следует понимать в широком смысле, как множество механизмов управления и поддержки, включающее сообщения OAM, APS¹⁴, SCC¹⁵ и MCC¹⁶.

Отметим также, что GAL и ACH в общем случае применимы к MPLS и PW. Данный документ задает общие механизмы и использует MPLS-TP в качестве примера. Применение GAL и ACH к другим конкретным приложениям MPLS выходит за рамки документа.

1.1. Цели

Этот документ определяет механизм, обеспечивающий решение задач технической поддержки для новых приложений MPLS. Предложен базовый механизм организации канала управления, который может использоваться для MPLS LSP и Section, сохраняя совместимость по управлению со связанными каналами PW. Механизм также нормализует использование ACH для PW в транспортном контексте и определяет механизм исключения на основе меток, позволяющий сигнализировать устройствам LER/LSR присутствие ACH под стеком меток.

1.2. Сфера применения

Документ определяет инкапсуляцию заголовков для сообщений связанных каналов управления Section, LSP и PW.

Документ не определяет сигнализацию или согласование возможностей связанного канала между устройствами LER/LSR или PE, а также не определяет работу функций OAM.

Документ не отменяет имеющиеся для MPLS и PW механизмы OAM.

1.3. Уровни требований и терминология

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

ACH¹⁷ — заголовок связанного канала.

G-ACh¹⁸ — базовый связанный канал.

GAL — метка базового связанного канала.

Пакет G-ACh — любой пакет, содержащий относящееся к протоколу сообщение, который передается через связанный канал управления PW, LSP или MPLS Section. Примерами могут служить такие протоколы, как OAM, сигнальные коммуникации, управление.

Термины Section и Concatenated Segment (соединенный сегмент) определены в [TP-REQ] как приведено ниже (отметим, что Section и Section Layer Network являются синонимами).

Section Layer Network

Уровень секции представляет собой уровень сервера (MPLS-TP или иная технология), обеспечивающий перенос информации клиента уровня секции между смежными узлами на уровне транспортного пути или транспортного сервиса. Отметим, что G.805 [G805] определяет уровень секции, как один из двух уровней в сети уровня среды передачи. Другим уровнем является уровень физической среды.

Concatenated Segment — сцепленный сегмент

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

2. Заголовок базового связанного канала

VCCV [RFC5085] определяет три типа каналов управления (CC¹⁹), которые могут использоваться для обмена сообщениями OAM через PW. CC Type 1 использует ACH и называется In-band VCCV (VCCV по основному каналу), CC Type 2 использует метки MPLS Router Alert Label для индикации пакетов VCCV и называется Out-of-Band VCCV (VCCV по отдельному каналу), CC Type 3 использует TTL для того, чтобы форсировать обработку пакетов целевым уровнем управления и называется MPLS PW Label with TTL == 1 (метка MPLS PW с TTL = 1).

2.1. Определение

Использование ACH, ранее ограниченное PW, сейчас обобщено для случаев LSP и Section. Отметим, что для PW управляющее слово PWE3 [RFC4385] должно присутствовать в инкапсуляции пользовательских пакетов, когда ACH применяется для реализации связанного канала управления.

ACH использует CC Type 1 как показано на рисунке.

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|   Reserved    |         Channel Type          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Заголовок связанного канала

На рисунке 1 первый полубайт имеет значение 0001b для индикации канала управления, связанного с PW, LSP или Section. Поле Version имеет значение 0 в соответствии с RFC 4385 [RFC4385]. Биты 8 — 15 заголовка ACH являются резервными и должны устанавливаться в 0 при передачи и игнорироваться на приемной стороне. Биты 16 — 31 используются для представления возможных значений Channel Type (16-битовое поле с сетевым порядком байтов).

Отметим, что VCCV [RFC5085] включает также механизмы согласования для Control Channel и типа Connectivity Verification (т. е., функций OAM) между PE. Предполагается, что аналогичные механизмы будут применяться и для LSP. Такие приложения потребуют разработки дополнительных спецификаций, выходящих за рамки этого документа.

G-ACh недопустимо применять для транспортировки пользовательского трафика.

2.2. Выделение типа канала

Поле Channel Type указывает тип сообщений, которые передаются по связанному каналу управления — например, IPv4 или IPv6, если для передачи сообщений по связанному каналу используется демультиплексирование IP, или OAM и другие функции управления, если демультиплексирование IP не используется. Для связанного канала управления где IP не используется для мультиплексирования, поле Channel Type указывает конкретный протокол, поддерживаемый в связанном канале управления.

Значения Channel Type, используемые в настоящее время для VCCV, заданы в других документах (например, RFC 4446 [RFC4446] и RFC 4385 [RFC4385]). Дополнительные значения Channel Type и связанная с ними функциональность управления может определяться в других документах. Каждый документ, описывающий протокольное решение на основе ACH, должен указывать также применимое для протокола значение поля Channel Type.

Отметим, что эти значения выделяются из реестра PW Associated Channel Type [RFC4446] и данный документ меняет существующие правила с учетом экспериментального уровня. Дополнительная информация приведена в разделе 10.

3. ACH TLV

В некоторых случаях применения обобщенных связанных каналов требуется включение одного или множества ACH TLV для обеспечения дополнительной контекстной информации пакету G-ACh. Одним из применений таких ACH TLV может быть идентификация отправителя и/или предусмотренного получателя для сообщения в связанном канале. Однако использование такой конструкции не ограничивается предоставлением адресной информации и приложениями транспортного уровня.

Если сообщению G-ACh могут предшествовать ACH TLV, они должны быть явно указаны в определении ACH Channel Type. Если определение ACH Channel Type не говорит о возможности присутствия одного или множества ACH TLV перед G-ACh, заголовок ACH TLV Header должен следовать за ACH. Если в конкретном пакете связанного канала не требуется ACH TLV, но Channel Type определяет возможность использования ACH TLV, заголовок ACH TLV Header должен присутствовать с нулевым значением поля размера, показывающим отсутствие ACH TLV.

Если спецификация ACH Channel Type не указывает явно возможность использования ACH TLV, использовать заголовок ACH TLV Header недопустимо.

3.1. Структура данных ACH TLV

В этом параграфе определена и описана структура данных ACH при наличии ACH TLV Header.

На рисунке 2 показана структура данных пакета G-ACh.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ACH                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         ACH TLV Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                     0 или более ACH TLV                       ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                        G-ACh Message                          ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Данные пакета G-ACh

3.2. Заголовок ACH TLV

Заголовок ACH TLV Header определяет размер следующего за ним множества ACH TLV.

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Length               |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Заголовок ACH TLV

Поле Length указывает число октетов в полном наборе TLV, следующем за ACH TLV Header (включая суб-TLV). Нулевой размер показывает, что после заголовка нет ACH TLV. Отметим, что заполнения для набора ACH TLV не требуется.

Поле Reserved предназначено для использования в будущем и должно устанавливаться в 0 при отправке и игнорироваться при получении.

3.3. Объект ACH TLV

После заголовка ACH TLV Header могут следовать ACH TLV, структура которых определена и описана ниже.

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           TLV Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                             Value                             ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат ACH TLV

ACH TLV состоит из 16-битового поля Type, за которым следует 16-битовое поле Length, указывающее число октетов в поле Value. Формат и семантика информации в поле Value определяются значением TLV Type, как указано в реестре TLV Type (дополнительная информация приведена в разделе 10). Отметим, что поле Value в ACH TLV может содержать суб-TLV. Для отдельных TLV и суб-TLV заполнение с целью выравнивания не требуется.

4. Обобщенный механизм исключения

Обобщение механизма связанного канала на случаи LSP и Section требует также метода идентификации наличия в пакете с ACH не относящихся к сервису данных. В этом документе указано использование для таких целей специальной метки, названной G-ACh Label (GAL). Для этой метки используется одно из резервных значений, определенных в RFC 3032 [RFC3032]. Агентство IANA выделило для метки GAL значение 13.

Метка GAL обеспечивает сигнал на базе механизма исключений для:

отличия специфических пакетов (например, G-ACh) от прочих (например, пользовательских);
индикации наличия ACH непосредственно под стеком меток.

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

4.1. Связи между существующими механизмами MPLS OAM Alert

RFC 4379 [RFC4379] и BFD-MPLS [BFD-MPLS] определяют сигнальные механизмы, которые позволяют MPLS LSR идентифицировать и обрабатывать пакеты MPLS OAM при их инкапсуляции в IP. Эти механизмы основаны, например, на завершении времени жизни (TTL²⁰) и,или использовании IP-адреса получателя из блоков 127.0.0.0/8 или 0:0:0:0:0:FFFF:127.0.0.0/104 для IPv4 и IPv6, соответственно.

Эти механизмы используются по умолчанию для идентификации пакетов MPLS OAM при их инкапсуляции в IP, хотя могут применяться и механизмы, определенные в данном документе.

4.2. Применимость и использование GAL

В MPLS-TP метка GAL должна использоваться с пакетами в G-ACh на LSP, сцепленных сегментах (Concatenated Segment) LSP и с Section, но недопустимо использование этой метки с PW. Метка всегда должна находиться на дне стека меток (т. е., бит S должен быть установлен). Однако для других сред MPLS этот документ не вносит ограничений на расположение метки GAL в стеке и ее применение с PW. Когда метка GAL размещается на дне стека (бит S = 1), за ней всегда должен следовать заголовок ACH.

Метку GAL недопустимо включать в стек меток при транспортировке обычных пользовательских пакетов. При использовании меток GAL недопустимо присутствие в стеке более одной метки.

Принимающему устройству LSR, LER или PE недопустимо пересылать пакеты G-ACh другим узлам на основе метки GAL.

4.2.1. Обработка меток GAL

Поле класса трафика (TC²¹) элемента LSE²², содержащее GAL, следует определению и правилам обработки, заданным в [RFC5462].

Поле времени жизни (TTL) для LSE, включающее метку GAL, следует определению и правилам обработки, заданным в [RFC3443].

4.2.1.1. Пути и сегменты MPLS

На рисунке 5 показаны два устройства LER (A и D) и два LSR (B и C) для данного LSP, организованного от A к D и коммутируемого в B и C.

+---+             +---+             +---+             +---+
| A |-------------| B |-------------| C |-------------| D |
+---+             +---+             +---+             +---+

Рисунок 5. Техническая поддержка через LSP

В этом примере G-ACh существует на LSP между устройствами LER, обозначенными A и D, через коммутаторы LSR, обозначенные B и C. Новые пакеты G-ACh могут инициировать только устройства A и D. Устройства A, B, C и D могут обрабатывать пакеты G-ACh и отвечать на них.

На рисунке 6 показан формат пакета MPLS-TP G-ACh, используемого для LSP.

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               LSP Label               |  TC |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL                  |  TC |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ACH                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  ACH TLV Header (при наличии)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                     0 или более ACH TLV                       ~
~                           (при наличии)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                         G-ACh Message                         ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Формат пакета G-ACh для LSP

Отметим, что возможно туннелирование LSP через другой LSP (например, при наличии туннеля MPLS между B и C) и по этой причине в стеке могут присутствовать другие LSE.

Для передачи сообщения G-ACh по связанному с LSP каналу управления LER (A) генерирует сообщение G-ACh, перед которым может быть добавлен (prepend) заголовок ACH TLV Header и подходящие ACH TLV. Затем добавляется ACH, в который «вталкивается» GAL LSE. В заключении в результирующий пакет «вталкивается» метка LSP Label LSE.

Для поля TTL в GAL LSE должно устанавливаться значение не менее 1. Точное значение TTL зависит от приложения. Определение и правила обработки приведены в параграфе 4.2.1.
Бит S в GAL должен устанавливаться в соответствии с положением метки в стеке (см. параграф 4.2).
Установка поля TC в GAL зависит от приложения. Определение и правила обработки приведены в параграфе 4.2.1.

Устройствам LSR недопустимо изменять сообщения G-ACh, ACH или GAL в направлении целевого получателя.

Примечание. Это обусловлено тем, что после отправки пакета G-ACh в LSP ни один узел не видит его, пока не завершится TTL для метки LSP или метка GAL не будет раскрыта при выталкивании метки LSP из стека. Если это происходит у целевого получателя, например, указанного адресом в ACH TLV, может быть выполнена обработка, указанная ниже. Если же это происходит в другом месте, но узел согласен обрабатывать пакеты на данном канале ACH, обработка пакета выходит за рамки этого документа.

При получении помеченного пакета целевому адресату после проверки полей LSP Label и GAL LSE следует передать весь пакет подходящему средству обработки.

4.2.1.2. MPLS Section

На рисунке 7 показан пример MPLS Section.

+---+             +---+
| A |-------------| Z |
+---+             +---+

Рисунок 7. Техническая поддержка MPLS Section

По отношению к MPLS Section канал G-ACh существует между A и Z. Только A и Z могут помещать, извлекать и обрабатывать пакеты в этом G-ACh.

На рисунке 8 показан формат пакета G-ACh при использовании MPLS Section. Метка GAL может указывать механизм исключения для управляющего канала без привязки к конкретному LSP, обеспечивая возможность связанных с поддержкой коммуникаций через конкретный канал, соединяющий два LSR. В этом случае GAL является единственной меткой в стеке.

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL                  |  TC |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ACH                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  ACH TLV Header (при наличии)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                     0 или более ACH TLV                       ~
~                         (при наличии)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                         G-ACh message                         ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 8. Формат пакета G-ACh для MPLS Section.

Для отправки сообщения G-ACh в управляющий канал, связанный с Section, головной (head-end) LSR (A) в этой секции (Section) создает сообщение G-ACh, перед которым от может поместить ACH TLV Header и подходящие ACH TLV. После этого LSR добавляет ACH с в заключение выталкивает (push) GAL LSE.

Поле TTL в GAL должно иметь значение не меньше 1. Точное значение TTL зависит от приложения. Определение и правила обработки приведены в параграфе 4.2.1.
Бит S в GAL должен устанавливаться в соответствии с положением в стеке меток (см. параграф 4.2).
Значение поля TC в GAL зависит от приложения. Определение и правила обработки даны в параграфе 4.2.1.

Промежуточным узлам MPLS Section недопустимо изменять сообщение G-ACh, ACH и GAL в направлении оконечного (tail-end) LSR (Z). При получении пакета G-ACh оконечному LSR (Z) после проверки полей GAL LSE следует передать пакет целиком подходящему модулю обработки.

4.3. Связь с RFC 3429

В RFC 3429 [RFC3429] описано выделение одного из резервных значений меток, определенных в RFC 3032 [RFC3032], в качестве метки OAM Alert, которая применяется на пользовательском уровне (user-plane) функций MPLS OAM для идентификации пакетов MPLS OAM. Для этого использовано значение 14.

Следовательно, данный документ и RFC 3429 [RFC3429] описывают выделение резервных значений меток с близкими целями. Обоснование выделения новой метки из резерва приведено ниже.

В отличие от механизмов, описанных и упоминаемых в RFC 3429 [RFC3429], сообщения G-ACh не будут размещаться сразу после GAL и будут находиться за заголовком связанного канала ACH, который, сам по себе, размещается после дна стека меток.
Множество функций управления, которые могут работать в контексте G-ACh, шире набора функций OAM, упоминаемых в RFC 3429 [RFC3429].
Было отмечено, что имеющиеся реализации и развернутые системы используют OAM Alert Label в соответствии с RFC 3429 [RFC3429]. Следовательно, нет возможности изменить выделение, предназначение или применение OAM Alert Label. Тем не менее, рекомендуется впредь не разрабатывать и не специфицировать расширений OAM на основе OAM Alert Label (Label 14).

5. Совместимость

Процедуры обработки пакетов, принятых с непригодной входящей меткой, заданы в RFC 3031 [RFC3031].

Устройства LER, LSR или PE должны отбрасывать принятые пакеты связанного канала, в которых были вытолкнуты все метки MPLS или PW при выполнении любого из приведенных ниже условий.

Неспособность обработать пакеты с типом (Channel Type), указанным заголовком ACH принятого пакета.
Пакет не помечен средствами, не входящими в данную спецификацию, для отправки устройству LSR, LER или PE, которое будет обрабатывать пакеты связанного канала для Channel Type, указанного заголовком ACH в принятом пакете.
Пакет получен с типом Experimental Channel Type, который в настоящее время запрещен.
Если ACH указывает присутствие GAL и первый полубайт ACH в принятом пакете отличается от 0001b.
Версия заголовка ACH не распознана.

В дополнение устройства LER, LSR или PE могут увеличивать значение счетчика ошибок, а также могут генерировать уведомление на уровне системы и/или протокола SNMP²³.

6. Вопросы насыщения

Вопросы насыщения, рассмотренные в RFC 5085 [RFC5085], применимы и здесь.

7. Основные авторы

Редакторы благодарны George Swallow, David Ward и Rahul Aggarwal за значительный вклад в разработку этого документа.

George Swallow

Cisco Systems

Email: swallow@cisco.com

David Ward

Cisco Systems

Email: dward@cisco.com

Rahul Aggarwal

Juniper Networks

Email: rahul@juniper.net

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

Редакторы выражают признательность Sami Boutros, Italo Busi, Marc Lasserre, Lieven Levrau и Siva Sivabalan за вклад в работу.

Авторы также благодарят Malcolm Betts (ITU-T Study Group 15) и всех членов объединенных команд MPLS Interoperability Design Team в IETF и MPLS-TP Ad Hoc Team в ITU-T, вовлеченных в определение и спецификацию транспортного профиля MPLS.

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

Проблемы безопасности для связанного канала управления рассмотрены RFC 4385 [RFC4385]. Дополнительное рассмотрение вопросов безопасности должно включать в соответствующие спецификации типов связанных каналов.

В RFC 5085 [RFC5085] рассмотрены вопросы безопасности, связанные с уровнем данных (data plane). Это рассмотрение применимо и к G-ACh, независимо от использования GAL или только ACH.

10. Взаимодействие с IANA

Агентство IANA выделило метку 13 для GAL из блока резервных меток в реестре Multiprotocol Label Switching Architecture (MPLS) Label Values.

Значения Channel Type для Associated Channel Header выделены из реестра IANA PW Associated Channel Type [RFC4446]. Выделение значений из реестра PW Associated Channel Type в настоящее время осуществляется с согласия IETF (процедура IETF Review в [RFC5226]). Такой способ выделения был выбран на основе согласованного мнения членов рабочей группы PWE3 о том, что механизмы связанных каналов для псевдопроводов должны рецензироваться IETF с выделением кодов лишь для тех механизмов, которые согласуются с архитектурой и требованиями PWE3.

Однако возникло требование (см. [OAM-REQ]) обеспечить возможность экспериментальной оптимизации или расширений OAM и других протоколов управления, работающих на связанных каналах, без привлечения процесса стандартизации IETF. Это позволит предотвратить использование для таких экспериментов кодов, выделенных в процессе стандартизации IETF, и защитить установленное оборудование от возможной непреднамеренной перегрузки кодами. Для поддержки этой потребности агентство IANA изменило схему распределения кодов для PW Associated Channel Type, как показано ниже:

0 — 32751 : IETF Review

32760 — 32767 : Experimental

Коды из выделенного для экспериментов диапазона должны использоваться в соответствии с рекомендациями RFC 3692 [RFC3692]. Функции, использующие экспериментальные коды G-ACh, по умолчанию должны быть отключены. Значение Channel Type, применяемое для такой экспериментальной функции OAM, должно быть настраиваемым, а также должны быть приняты меры по обеспечению использования во взаимодействующих функциях OAM разных значений Channel Type.

Значение	Описание	Следующий TLV	Документ
0x21	ACH передается в пакете IPv4	нет	[RFC4385]
	ACH передается в пакете IPv6	нет	[RFC4385]

Рисунок 9. Реестр типов каналов PW.

Реестр PW Associated Channel Type был обновлен путем включения колонки, указывающей наличие следующего за ACH заголовка ACH TLV header (да/нет). В настоящее время выделены два кода ACH Channel Type и для обоих заголовки ACH TLV не используются. Таким образом, для нового формата реестра PW Channel Type агентство IANA создало новый реестр Associated Channel Header TLV Registry. Значения в из этого реестра выделяются на основании рецензии IETF. В реестре должна указываться приведенная ниже информация. Изначально реестр пуст.

Имя	Тип	Размер в октетах	Описание	Документ

Рисунок 10. Реестр ACH TLV.

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

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

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

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

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

[RFC3443] Agarwal, P. and B. Akyol, «Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks», RFC 3443, January 2003.

[RFC3692] Narten, T., «Assigning Experimental and Testing Numbers Considered Useful», BCP 82, RFC 3692, January 2004.

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, «Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN», RFC 4385, February 2006.

[RFC4446] Martini, L., «IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)», BCP 116, RFC 4446, April 2006.

[RFC5085] Nadeau, T. and C. Pignataro, «Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires», RFC 5085, December 2007.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5462] Andersson, L. and R. Asati, «Multiprotocol Label Switching (MPLS) Label Stack Entry: «EXP» Field Renamed to «Traffic Class» Field», RFC 5462, February 2009.

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

[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, «BFD For MPLS LSPs», Work in Progress²⁴, June 2008.

[BFD-VCCV] Nadeau, T. and C. Pignataro, «Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)», Work in Progress²⁵, May 2009.

[G805] International Telecommunication Union, «Generic Functional Architecture of Transport Networks», ITU-T G.805, March 2000.

[MPLS-TP] Bocci, M., Bryant, S., and L. Levrau, «A Framework for MPLS in Transport Networks», Work in Progress²⁶, November 2008.

[OAM-REQ] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., «Requirements for OAM in MPLS Transport Networks», Work in Progress²⁷, March 2009.

[RFC3429] Ohta, H., «Assignment of the ‘OAM Alert Label’ for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions», RFC 3429, November 2002.

[RFC4379] Kompella, K. and G. Swallow, «Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures», RFC 4379, February 2006.

[TP-REQ] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, «MPLS-TP Requirements», Work in Progress²⁸, May 2009.

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

Matthew Bocci (редактор)

Alcatel-Lucent

Voyager Place, Shoppenhangers Road

Maidenhead, Berks SL6 2PJ

EMail: matthew.bocci@alcatel-lucent.com

Martin Vigoureux (редактор)

Alcatel-Lucent

Route de Villejust

Nozay, 91620

France

EMail: martin.vigoureux@alcatel-lucent.com

Stewart Bryant (редактор)

Cisco Systems

EMail: stbryant@cisco.com

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

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

nmalykh@protokols.ru

1Pseudowire Associated Channel Header.

2Label Switched Path — путь с коммутацией по меткам.

3Generic Associated Channel Label — метка обобщенного связанного канала.

4Operations, Administration, and Maintenance — эксплуатация, администрирование и техническая поддержка.

5Label Edge Router/Label Switching Router — краевой маршрутизатор по меткам/маршрутизатор с коммутацией по меткам.

6Terminating Provider Edge router/Switching Provider Edge router — краевой завершающий маршрутизатор провайдера/краевой коммутирующий маршрутизатор провайдера.

7Virtual Circuit Connectivity Verification — проверка связности виртуальных устройств (каналов).

8Bidirectional Forwarding Detection for MPLS LSPs — двухстороннее детектирование пересылки для MPLS LSP.

9Packet Switched Network — сеть с коммутацией пакетов.

10Associated Channel Header — заголовок связанного канала.

11Generic Associated Channel — базовый связанный канал.

12G-ACh Label — метка базового связанного канала.

13Time To Live — время жизни.

14Automatic Protection Switching — автоматическая защитная коммутация.

15Signaling Communication Channel — коммуникационный канал для сигнализации.

16Management Communication Channel — коммуникационный канал для поддержки.

17Associated Channel Header.

18Generic Associated Channel.

19Control Channel.

20Time To Live.

21Traffic Class (раньше называлось EXP).

22Label Stack Entry — элемент стека меток.

23Simple Network Management Protocol — простой протокол сетевого управления.

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

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

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

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

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

Рубрика: RFC | Комментарии отключены

RFC 5531 RPC: Remote Procedure Call Protocol Specification Version 2

Опубликовано 24.05.2009 автором Nikolai Malykh

Network Working Group                                         R. Thurlow
Request for Comments: 5531                              Sun Microsystems
Obsoletes: 1831                                                 May 2009
Category: Standards Track

RPC: Remote Procedure Call Protocol Specification Version 2

Спецификация протокола RPC версии 2

PDF

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

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

Аннотация

Этот документ определяет версию 2 протокола удалённого вызова процедур (Remote Procedure Call или RPC) от Open Network Computing (ONC) в том виде, в котором он развёрнут и принят. Документ отменяет RFC 1831.

1. Введение

Документ задаёт версию 2 протокола удалённого вызова процедур ONC RPC. Задан протокол сообщений на языке внешнего представления данных (eXternal Data Representation или XDR) [RFC4506] и предполагается, что читатели знакомы с этим языком. Документ не пытается обосновать системы удалённого вызова процедур или описать их применение. Для понимания концепций удалённых вызовов процедур рекомендуется статья Birrell и Nelson [XRPC].

1.1. Уровни требований

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

2. Отличия от RFC 1831

Этот документ отменяет [RFC1831] как полномочное описание RPC, не меняя протокол в линии. Основные отличия от RFC 1831 указаны ниже.

Добавлено приложение, описывающее способы запроса разработчиками новых номеров программ RPC, номеров вариантов аутентификации и статуса аутентификации в IANA, а не в Sun Microsystems.
Добавлен раздел 13. Взаимодействие с IANA, описывающий прошлую политику выделения номеров и правила IANA для назначения номеров в будущем.
Уточнена спецификация языка RPC в соответствии с текущим применением.
Улучшен раздел 14. Вопросы безопасности с учётом опыта работы с вариантами строгой защиты.
Задана спецификация новых ошибок аутентификации, часто возникающих в современных реализациях RPC.
Обновлены заявления IETF о правах интеллектуальной собственности.

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

В этом документе обсуждаются клиенты, вызовы, серверы, отклики, службы, программы, процедуры и версии. У каждого удалённого вызова процедуры есть 2 стороны — активный клиент, который вызывает серверную сторону, и сервер, который возвращает ответ. Сетевая служба — это набор из одной или нескольких удалённых программ. Удалённая программа реализует 1 или несколько удалённых процедур, а процедуры, их параметры и результаты документируются в спецификациях протоколов конкретных программ. Сервер может поддерживать не одну версию удалённой программы для совместимости с меняющимися протоколами. Например, сетевая файловая служба может состоять из двух программ — одна может работать с приложениями высокого уровня, такими как управление доступом к файлам и блокировка, а другая — работать с низкоуровневыми операциями ввода-вывода и иметь такие процедуры, как чтение и запись. Клиент сетевой службы будет вызывать процедуры, связанные с этими двумя программами от имени пользователя (клиента).

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

4. Модель RPC

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

Модель удалённого вызова похожа. Один поток (thread) управления логически проходит через два процесса — процесс вызывающего и процесс сервера. Вызывающий сначала передаёт сообщение с вызовом серверному процессу и ждёт (блокирует) ответное сообщение. Сообщение вызова включает параметры процедуры, а отклик — её результаты. После получения отклика результаты процедуры извлекаются и вызывающий возобновляет исполнение. На серверной стороне процесс бездействует в ожидании вызывающего сообщения. Получив сообщение, серверный процесс извлекает параметры процедуры, вычисляет результат, передаёт сообщение с откликом и ждёт следующего сообщения с вызовом.

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

Имеется несколько важных различий между локальными и удалёнными вызовами процедур.

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

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

5. Транспорт и семантика

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

Важно отметить, что RPC не пытается обеспечить надёжность и приложению может потребоваться знать тип транспортного протокола, используемого RPC. Если приложению известно, что протокол работает на основе надёжного транспорта, такого как TCP, большая часть работы уже сделана. Однако при работе на основе транспорта без гарантий, такого как UDP [RFC0768], приложение должно реализовать свои правила для тайм-аутов, повтора передачи и обнаружения дубликатов, поскольку протокол RPC не предоставляет таких услуг.

Независимость протокола RPC от транспорта ведёт к отсутствию привязки конкретной семантики требований к удаленным процедурам и их выполнению. Семантика может быть выведена из базового транспортного протокола (но её следует указывать явно). Рассмотрим, например, работу RPC на основе транспорта без гарантий, такого как UDP. Если приложение повторяет сообщения с запросом RPC после тайм-аута и не получает отклика, оно не будет знать, сколько раз была выполнена запрошенная процедура. При получении отклика приложение будет знать, что процедура выполнена по меньшей мере один раз.

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

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

Помимо протоколов, основанных на дейтаграммах и соединениях, имеются иные варианты транспорта. Например, протокол «запрос-отклик», такой как [VMTP], может быть естественным транспортным решением для RPC. В ONC RPC сейчас применяются транспортные протоколы TCP и UDP. В разделе 11. Стандарт маркировки записей описан механизм, реализованный в ONC RPC для ориентированного на соединения и потоки транспорта, такого как TCP. Механизмы, которые будут применяться для передачи сообщений ONC RPC будущим транспортом с другими структурными характеристиками, следует задавать в RFC категории Standards Track, как только дополнительный транспорт задан.

6. Независимость от привязки

Привязка конкретного клиента к конкретному сервису и параметрам транспорта не являются частью спецификации протокола RPC. Эта важная и необходимая функция оставлена программам вышележащего уровня. Разработчики могут представлять протокол RPC как сетевую инструкцию перехода в подпрограмму (jump-subroutine instruction или JSR), загрузчик делает JSR используемой и сам применяет JSR для решения задачи. Точно так же программа привязки делает RPC используемой и может применять RPC для решения задачи.

7. Проверка подлинности

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

8. Требования к протоколу RPC

Протокол RPC должен обеспечивать:

однозначное указание вызываемой процедуры;
средства сопоставления откликов с запросами;
кредства аутентификации клиентов и серверов.

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

Несоответствие протоколов RPC.
Несоответствие версии протокола удалённой программы.
Ошибки протокола (например, некорректное указание параметров процедуры).
Причины отказа при аутентификации.
Любые другие причины, по которым запрошенная процедура не была вызвана.

8.1. Программы и процедуры RPC

Сообщение RPC с вызовом процедуры содержит 3 целочисленных поля без знака — номер удалённой программы, номер версии удалённой программы и номер удалённой процедуры, — которые однозначно указывают вызываемую процедуру. Номера программ централизованно администрирует IANA. После получения разработчиком номера программы он может реализовать свою программу и первая реализация будет вероятно иметь версию номер 1, но использование номера 0 недопустимо. Поскольку большинство новых протоколов развиваются, поле версии (version) в сообщении с вызовом указывает, вресию, используемую вызывающей стороной. Номера версий позволяют поддерживать старый и новый протокол в одном серверном процессе.

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

Протокол сообщений RPC, как и протокол удалённой программы, может изменяться, поэтому сообщение с вызовом указывает также номер версии RPC, который для описанной здесь версии протокола имеет значение 2.

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

Удалённая реализация RPC не поддерживает протокол версии 2 и возвращает старший и младший номера поддерживаемых версий.
Удалённая программа недоступна на удалённой системе.
Удалённая программа не поддерживает запрошенный номер версии и возвращает старший и младший номера поддерживаемых версий.
Процедуры с запрошенным номером не существует (обычно это связано с ошибкой протокола или программы на стороне клиента).
Параметры удалённой процедуры представляются серверу некорректными (мусор) — обычно это связано с рассогласованием клиента и сервера.

8.2. Аутентификация, целостность и приватность

Положения для аутентификации клиента серверу (и наоборот) являются частью протокола RPC. Сообщение с вызовом включает два поля аутентификации — свидетельство (credential) и верификатор (verifier), а отклик содержит лишь поле верификатор (verifier) для отклика. Спецификация протокола RPC определяет все три поля как неинтерпретируемые (opaque), как представлено ниже на языке XDR [RFC4506]).

         enum auth_flavor {
            AUTH_NONE       = 0,
            AUTH_SYS        = 1,
            AUTH_SHORT      = 2,
            AUTH_DH         = 3,
            RPCSEC_GSS      = 6
            /* могут дополняться другими */
         };

         struct opaque_auth {
            auth_flavor flavor;
            opaque body<400>;
         };

Иными словами, любая структура opaque_auth является перечисляемым значением auth_flavor, а за ним следует до 400 байтов, которые не интерпретируются (opaque) реализацией протокола RPC. Интерпретация и семантика данных в полях аутентификации задаётся отдельной, независимой спецификацией протокола проверки подлинности.

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

8.3. Назначение номеров программ

Номера программ разделены на группы, показанные ниже.

0x00000000                резерв
0x00000001 - 0x1fffffff   для распределения IANA
0x20000000 - 0x3fffffff   выделяет локальный администратор
                          (некоторые блоки выделены здесь)
0x40000000 - 0x5fffffff   временные (динамические)
0x60000000 - 0x7effffff   резерв
0x7f000000 - 0x7fffffff   не распределены
0x80000000 - 0xffffffff   резерв

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

8.4. Другие применения протокола RPC

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

8.4.1. Пакетная обработка

Пакетная обработка может быть полезна в случаях, когда клиенту нужно передать серверу произвольно большую последовательность сообщений с вызовами. Обычно для этого применяются потоковые транспортные протоколы с надёжной доставкой (такие как TCP). При пакетной обработке клиент не ождает отклика от сервера, а сервер не возвращает отклик на пакетный вызов. Цепочка пакетных вызовов обычно завершается легитимной операцией вызова удалённой процедуры для очистки конвейера (pipeline) и получения позитивного подтверждения.

8.4.2. Широковещательные вызовы RPC

В широковещательных протоколах клиент передаёт в сеть широковещательный вызов и ждёт множества откликов. Для этого требуется использовать основанный на пакетах транспортный протокол (такой как UDP). Серверы, поддерживающие широковещательные протоколы, обычно отвечают лишь при успешном выполнении вызова и молчат в случае ошибки, но это может зависеть от приложения. Принципы широковещательных RPC применимы и к групповой передаче (multicast) — запросы RPC будут отправляться на групповой адрес.

9. Протокол сообщений RPC

В этом разделе определён протокол сообщений RPC на языке описания данных XDR [RFC4506].

         enum msg_type {
            CALL  = 0,
            REPLY = 1
         };

Отклик на сообщение с вызовом может принимать две формы — восприятие или отказ.

         enum reply_stat {
            MSG_ACCEPTED = 0,
            MSG_DENIED   = 1
         };

Если вызов воспринят, возвращается результат попытки вызова удалённой процедуры.

enum accept_stat {
   SUCCESS       = 0, /* Вызов RPC завершился успешно */
   PROG_UNAVAIL  = 1, /* У удалённой стороны нет экспортируемой 
                         программы */
   PROG_MISMATCH = 2, /* У удалённой стороны нет поддерживаемой 
                         версии */
   PROC_UNAVAIL  = 3, /* Программа не поддерживает процедуру */
   GARBAGE_ARGS  = 4, /* Процедура не может декодировать параметры */
   SYSTEM_ERR    = 5  /* Например, ошибка выделения памяти */
};

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

         enum reject_stat {
            RPC_MISMATCH = 0, /* Номер версии RPC не равен 2 */
            AUTH_ERROR = 1    /* Удалённая сторона не смогла 
                                 аутентифицировать вызавающего */
         };

Ниже указаны причины отказа при аутентификации.

      enum auth_stat {
         AUTH_OK           = 0,  /* Успех */
         /*
          * Отказы на удалённой стороне
          */
         AUTH_BADCRED      = 1,  /* Непригодное свидетельство */
         AUTH_REJECTEDCRED = 2,  /* Клиент должен начать новую сессию */
         AUTH_BADVERF      = 3,  /* Непригодный верификатор */
         AUTH_REJECTEDVERF = 4,  /* Срок действия верификатора 
                                    или использован повтор (replay) */
         AUTH_TOOWEAK      = 5,  /* Отвергнуто по соображениям 
                                    безопасности */
         /*
          * Локальный отказ
          */
         AUTH_INVALIDRESP  = 6,  /* Поддельный верификатор в отклике */
         AUTH_FAILED       = 7,  /* Неизвестная причина */
         /*
          * Ошибки AUTH_KERB - отменены, см. [RFC2695]
          */
         AUTH_KERB_GENERIC = 8,  /* Общая ошибка kerberos */
         AUTH_TIMEEXPIRE = 9,    /* Просроченное свидетельство */
         AUTH_TKT_FILE = 10,     /* Проблема с файлом квитанции */
         AUTH_DECODE = 11,       /* Не удалось декодировать 
                                    authenticator */
         AUTH_NET_ADDR = 12,     /* Неверный адрес сети в квитанции */
         /*
          * Ошибки RPCSEC_GSS, связанные с GSS
          */
         RPCSEC_GSS_CREDPROBLEM = 13, /* Нет свидетельства для 
                                         пользователя */
         RPCSEC_GSS_CTXPROBLEM = 14   /* Проблема с контекстом */
      };

По мере добавления механизмов аутентификации список кодов может расширяться. Агентство IANA будет выдавать новые номера auth_stat в порядке их запроса (First Come First Served), как указано в разделе 13. Взаимодействие с IANA и приложении B.

Все сообщения RPC начинаются с идентификатора транзакции xid, за которым следует двухэлементное объединение (union). Дискриминантом union является тип сообщения (msg_type), который может принимать два значения. Поле xid в сообщении с откликом (REPLY) всегда соответствует одноименному полю в исходном сообщении с вызовом (CALL). Важно подчеркнуть, что поле xid служит лишь для сопоставления откликов с запросами у клиента и обнаружения сервером повторов передачи, серверна сторона не может считать это поле порядковым номером.

         struct rpc_msg {
            unsigned int xid;
            union switch (msg_type mtype) {
            case CALL:
               call_body cbody;
            case REPLY:
               reply_body rbody;
            } body;
         };

В теле вызова RPC версии 2 поле rpcvers должно иметь значение 2. Поля prog, vers и proc задают удалённую программу, номер её версии и вызываемую в этой программе процедуру. За этими полями следуют два параметра аутентификации — cred (свидетельство для проверки подлинности) и verf (верификатор для аутентификации). После этих параметров указываются параметры, передаваемые удалённой процедуре в соответствии с конкретным протоколом.

Роль vers состоит в проверке свидетельства аутентификации (cred). Отмтим, что два эти элемента разделены исторически, но всегда применяются вместе как один логический объект.

        struct call_body {
           unsigned int rpcvers;       /* Должно быть 2 */
           unsigned int prog;
           unsigned int vers;
           unsigned int proc;
           opaque_auth cred;
           opaque_auth verf;
           /* Здесь начинаются параметры процедуры */
        };

Тело отклика на вызов RPC показано ниже.

         union reply_body switch (reply_stat stat) {
         case MSG_ACCEPTED:
            accepted_reply areply;
         case MSG_DENIED:
            rejected_reply rreply;
         } reply;

Отклик на воспринятый сервером вызов RPC может указывать ошибку, несмотря на принятие запроса. Первое поле служит для проверки аутентификации и генерируется сервером для подтверждения себя клиенту. Далее следует объединение (union) с перечисляемым дискриминатором accept_stat, ветвь SUCCESS в объединении зависит от протокола, а ветви PROG_UNAVAIL, PROC_UNAVAIL, GARBAGE_ARGS и SYSTEM_ERR имеют тип void. Ветвь PROG_MISMATCH задаёт младшую и старшую версию удалённой программы, поддерживаемой сервером.

         struct accepted_reply {
            opaque_auth verf;
            union switch (accept_stat stat) {
            case SUCCESS:
               opaque results[0];
               /*
                * Здесь начинаются зависящие от процедуры результаты
                */
             case PROG_MISMATCH:
                struct {
                   unsigned int low;
                   unsigned int high;
                } mismatch_info;
             default:
                /*
                 * Void. Варианты включают PROG_UNAVAIL, PROC_UNAVAIL,
                 * GARBAGE_ARGS, SYSTEM_ERR.
                 */
                void;
             } reply_data;
         };

Вызов RPC может быть отвергнут сервером по двум причинам — отсутствие совместимой версии протокола RPC (RPC_MISMATCH) или отказ при аутентификации (AUTH_ERROR). При несоответствии версий сервер возвращает младший и старший номер поддерживаемой версии RPC. При отказе проверки подлинности указывается статус отказа.

         union rejected_reply switch (reject_stat stat) {
         case RPC_MISMATCH:
            struct {
               unsigned int low;
               unsigned int high;
            } mismatch_info;
         case AUTH_ERROR:
            auth_stat stat;
         };

10. Протоколы аутентификации

Выше было отмечено, что параметры аутентификации не интерпретируются, но открыты для остальной части протокола RPC. В этом разделе рассматриваются два стандартных варианта аутентификации. Разработчики могут предлагать свои варианты с такими же правилами назначения им номеров, какие применяются для номеров программ. Вариант со свидетельством или верификаторами относится к значению поля flavor в структуре opaque_auth. Номера вариантов, подобно номерам программ RPC, администрируются централизованно и разработчики могут назначать новым вариантам номера в соответствии с методами, указанными в Приложении B. Свидетельства и верификаторы представляются как неинтерпретируемые данные переменного размера (поле body в структуре opaque_auth).

В этом документе описаны два варианта проверки подлинности. Пустая (Null) аутентификация, описанная в следующем параграфе, является обязательной и должна быть доступна во всех реализациях. Системная аутентификация (AUTH_SYS) описана в Приложении A. Разработчики могут включать AUTH_SYS в свои реализации для поддержки имеющихся приложений. Более защищённые варианты аутентификации указаны в разделе 14. Вопросы безопасности.

10.1. Пустая (Null) аутентификация

Зачастую нужны вызовы, когда клиенту не важно своё отождествление, а серверу все равно, кто является клиентом. В таких случаях в сообщениях RPC в качестве свидетельства, верификатора, а также верификатора в отклике применяется значение AUTH_NONE. Связанные данные для AUTH_NONE не заданы и рекомендуется, чтобы размер неинтерпретируемых данных был нулевым (нет данных).

11. Стандарт маркировки записей

Когда сообщения RPC передаются через транспорт в форме потока байтов (как в TCP), требуется отделять одно сообщение от другого для обнаружения и исправления возможных ошибок протокола. Это называется маркировкой записей (record marking или RM). Одно сообщение RPC помещается в одну запись RM.

Запись состоит из одного или нескольких фрагментов. Фрагмент имеет 4-байтовый заголовок, за которым может следовать до 2³¹ — 1 байтов данных. Байты кодируют целые числа без знака, как и в случае с целыми числами XDR, от старшего байта к младшему. Заголовок представляет два значения — логическое, указывающее, является ли фрагмент последним (установленный в 1 бит указывает последний фрагмент), и 31-битовое целое число без знака, указывающее размер данных во фрагменте. Логическое значение занимает старший бит заголовка, а размер — 31 младший бит (отметим, что эта спецификация записи не использует стандартный формат XDR).

12. Язык RPC

Как и для описания типов данных XDR на формальном языке, нужно формально описать и процедуры, которые работают с этими типами данных XDR. Язык RPC является расширением языка XDR путём добавления деклараций program, procedure, version. Ключевые слова program и version зарезервированы в языке RPC и реализации компиляторов XDR могут резервировать эти слова даже при их включении в «чистые» описания XDR (без RPC). Ниже приведён пример описания сущности языка.

12.1. Пример службы, описанной на языке RPC

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

      program PING_PROG {
            /*
             * Последняя и наибольшая версия
             */
            version PING_VERS_PINGBACK {
               void
               PINGPROC_NULL(void) = 0;
               /*
                * Ping для клиента возвращает время кругового обхода
                * (в мксек). Значение -1 указывает тайм-аут.
                */
               int
               PINGPROC_PINGBACK(void) = 1;
            } = 2;

            /*
             * Исходная версия
             */
            version PING_VERS_ORIG {
               void
               PINGPROC_NULL(void) = 0;
            } = 1;
         } = 1;

         const PING_VERS = 2;      /* Последняя версия */

Первая описанная версия — PING_VERS_PINGBACK имеет 2 процедуры: PINGPROC_NULL и PINGPROC_PINGBACK. PINGPROC_NULL не имеет аргументов и не возвращает результата, но полезна для расчёта времени кругового обхода между клиентом и сервером. По соглашению, процедуре 0 в любом протоколе RPC следует иметь такую же семантику и никогда не требовать аутентификации. Вторая процедура применяется для клиента, чтобы заставить сервер выполнить операцию ping в сторону клиента и вернуть интервал времени, затраченного на операцию (в микросекундах). PING_VERS_ORIG является исходной версией протокола и не включает процедуру PINGPROC_PINGBACK. Это полезно для совместимости со старыми клиентскими программами и по мере развития самой программы может быть полностью исключено из протокола.

12.2. Спецификация языка RPC

Язык RPC идентичен языку XDR, заданному в RFC 4506, за исключением добавления program-def, описанного ниже.

      program-def:
         "program" identifier "{"
            version-def
            version-def *
         "}" "=" constant ";"

      version-def:
         "version" identifier "{"
             procedure-def
             procedure-def *
         "}" "=" constant ";"

      procedure-def:
         proc-return identifier "(" proc-firstarg
           ("," type-specifier )* ")" "=" constant ";"

      proc-return: "void" | type-specifier

      proc-firstarg: "void" | type-specifier

12.3. Замечания по синтаксису

Ключевые слова program и version не могут использоваться в качестве идентификаторов.
Имя версии, а также номер версии не может включаться более 1 раза в области определения программы.
Имя процедуры, а также номер процедуры не может включаться более 1 раза в области опеределения версии.
Идентификаторы программ относятся к одному пространству имён с идентификаторами констант и типов.
Номера программ, версий и процедур могут быть только беззнаковыми целыми числами.
Имеющиеся компиляторы языка RPC обычно не поддерживают более одного спецификатора типа в списках аргументов процедур, обычно аргументы помещаются внутрь структуры.

13. Взаимодействие с IANA

Назначение номеров программ RPC, вариантов аутентификации и статуса аутентификации в прошлом выполнялось компанией Sun Microsystems, Inc (Sun). Это неприемлемо для протокола IETF Standards Track, поскольку такая работа отдана агентству по назначению номеров Internet (Internet Assigned Numbers Authority или IANA). Этот документ предлагает передать полномочия по выделению номеров программ RPC, вариантов аутентификации и статуса аутентификации от Sun Microsystems, Inc. в IANA и описать, как IANA будет поддерживать и выделять эти номера. Пользователи протоколов RPC выиграют от наличия независимого органа, отвечающего за назначение номеров.

13.1. Запрос номеров в IANA

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

краткое описание цели использования;
выделенные номера программ;
короткие идентификаторы (строки).

13.2. Защита прошлых назначений

Компания Sun выделила значения из пространств номеров программ RPC и вариантов аутентификации RPC с момента исходного развёртывания RPC. Назначения от Sun Microsystems остаются действительными и будут сохранены. Компания Sun сообщила в IANA все выделенные в обоих пространствах номера и процедура передачи на этом завершилась. Выделенные в настоящее время значения приведены в Приложении C. Текущие номера статусов аутентификации указаны в разделе 9 этого документа (определение enum auth_stat).

13.3. Назначение номеров RPC

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

13.3.1. Номера, выделяемые IANA

Первый блок администрирует IANA с защитой ранее выделенных компанией Sun значений. Эти значения относятся к десятичному диапазону 100000-399999 (0x000186a0 — 0x00061a7f), поэтому IANA начнёт назначение с десятичного номера 400000. Отдельные номера следует распределять в порядке запросов (First Come First Served), а блоки следует выделять по правилам, зависящим от размера блока.

13.3.2. Номера, выделяемые локальным администратором

Блок, распределяемый локальными администраторами, доступен для использования в любом административном домене, аналогично диапазонам приватных адресов IP. Ожидаемое использование будет заключаться в создании локальным доменом «агентства» (authority) по назначению номеров из этого диапазона. Этому органу следует задать правила и процедуры назначения номеров RPC из данного диапазона. Домену следует быть достаточно изолированным, чтобы вероятность взаимодействия с приложениями RPC из других доменов была минимальна, поскольку иначе могут возникать конфликты номеров RPC и связанные с ними отказы приложений. В отсутствие локального администратора этот блок можно использовать в стиле Private Use, как указано в [RFC5226].

13.3.3. Временные номера

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

Временный блок не администрируется. Службы RPC используют этот диапазон, выбирая номер и пытаясь зарегистрировать его в привязке RPC локальной системы (см. процедуры RPCBPROC_SET и PMAPPROC_SET в [RFC1833]). При успешной регистрации (другие службы RPC не используют этот номер) RPC Bindery назначает его запросившему приложению RPC. Регистрация действует до завершения RPC, которое обычно происходит при перезагрузке системы, закрывающей все приложения, включая службу RPC, использовавшую временный номер. При отказе регистрации (номер занят другим приложением RPC) запрашивающий должен выбрать другой номер и повторить запрос. Для предотвращения конфликтов рекомендуется выбирать случайный номер из этого диапазона.

13.3.4. Резервный блок

Резервный блок (Reserved) сохранён на будущее. Приложениям RPC недопустимо использовать номера из этого блока, пока это не будет разрешено IESG.

13.3.5. Субблоки номеров RPC

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

В таких случаях с разными номерами может использоваться один или разные протоколы RPC. Номера могут назначаться приложением динамически или устанавливаться административным решением для сайта. По возможности, службам RPC с динамическим назначением номеров RPC следует использовать номера из блока временных номеров (параграф 13.3.3), а если это невозможно, можно запросить субблок номеров RPC.

Назначение субблоков номеров RPC зависит от размера запрашиваемого субблока и выполняется по процедуре Specification Required или IESG Approval из параграфа 4.1 в [RFC5226].

Размер субблока	Метод выделения	Ответственный
до 100 номеров	First Come First Served	IANA
до 1000 номеров	Specification Required	IANA
более 1000 номеров	IESG Approval	IESG

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

Субблоки размером до 100 номеров IANA может выделять в порядке поступления запросов (First Come First Served). Описание службы (RPC Service Description), включённое в диапазон должно указывать, как будет управляться субблок и, как минимум, должно быть указано, будет он применяться с одним или несколькими протоколами RPC, а также динамическое или статическое (административное) назначение адресов.

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

Субблоки размером более 1000 должны документироваться, как указано выше, а назначение должно происходить после одобрения IESG. Предполагается, что такие случаи будут редкими.

Для предотвращения множественных запросов больших блоков номеров предлагаются приведённые ниже правила.

Запросы с числом номеров до 100 (включительно) обрабатываются по процедуре First Come First Served. Пороговое значение 100 применяется к общему числу номеров RPC, выделяемых физическому или юридическому лицу. Например, если сначала запрошено 70 номеров, а затем то же лицо запрашивает ещё 40, запрос на 40 номеров будет обрабатываться по процедуре Specification Required. Пока общее число номеров не превышает 1000, IANA может может не использовать процедуру Specification Required для дополнительных запросом с числом номеров меньше 100. Если физическое или юридическое лицо имеет менее 1000, а затем запрашивает дополнительный блок номеров так, что общее число превышает 1000, для дополнительного запроса требуется процедура IESG Approval.

13.4. Назначение номеров для вариантов аутентификации RPC

Второе пространство номеров предназначено для идентификаторов механизма аутентификации (flavor). Этот номер служит для выбора механизма проверки подлинности, который может применяться для сообщения RPC. Идентификатор используется в поле flavor структуры opaque_auth.

13.4.1. Правила назначения

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

короткие идентификаторы (строки);
выделенные номера аутентификации;

краткое описание цели использования.

13.4.2. Варианты и псевдо-варианты аутентификации

Тенденции защиты RPC отошли от создания новых вариантов аутентификации, применяемых в AUTH_DH [DH], и сосредоточились на использовании имеющегося варианта RPCSEC_GSS [RFC2203] и создании новых механизмов GSS-API¹ для него. Хотя RPCSEC_GSS является выбранным вариантом аутентификации, применение нового механизма RPCSEC_GSS с сетевой файловой системой (Network File System или NFS) [RFC1094] [RFC1813], [RFC3530] требует регистрации псевдо-вариантов (pseudo-flavor), используемых для однозначного согласования механизмов защиты, как указано в [RFC2623]. Имеющиеся псевдо-варианты представлены в диапазоне 390000-390255, а новые будут выделяться IANA из этого же блока по процедуре First Come First Served.

Для запросов, не связанных с псевдо-вариантами, IANA будет выделять номера вариантов аутентификации RPC, начиная с 400000 по процедуре First Come First Served, чтобы избежать конфликтов с уже выделенными номерами.

Для вариантов аутентификации или механизмов RPCSEC_GSS, применяемых в Internet, настоятельно рекомендуется публиковать RFC категории Informational или Standards Track с описанием поведения и параметров механизма аутентификации.

13.5. Выделение номеров для статуса аутентификации

Ещё одно пространство номеров предназначено для значений статуса аутентификации auth_stat, описывающих природу проблем, возникших при проверке подлинности, или подтверждения аутентификации. Полный исходный список значений приведён в разделе 9 (auth_stat). Предполагается, что новые значения будут добавляться редко, но время от времени новые варианты аутентификации могут приводить к расширению списка значений. Номера следует выделять по процедуре First Come First Served, чтобы избежать конфликтов с уже выделенными значениеми.

13.5.1. Правила назначения

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

короткие идентификаторы (строки);
выделенные номера auth_stat;

краткое описание цели использования.

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

Системная аутентификация (AUTH_SYS), описанная в Приложении A, считается небезопасной из-за отсутствия верификатора, позволяющего проверить свидетельство (credential). AUTH_SYS не следует применять для служб, позволяющих клиенту изменять данные. Метод AUTH_SYS недопустимо указывать как рекомендуемый или требуемый для любой службы RPC со статусом Standards Track.

Метод AUTH_DH, как отмечено в параграфах 8.2 и 13.4.2, считается устаревшим и небезопасным (см. [RFC2695]). AUTH_DH не следует применять для служб, позволяющих клиенту изменять данные. Метод AUTH_DH недопустимо указывать как рекомендуемый или требуемый для любой службы RPC со статусом Standards Track.

В [RFC2203] определён новый вариант защиты — RPCSEC_GSS, позволяющий использовать механизмы GSS-API [RFC2743] для защиты RPC. Всем нетривиальным программам RPC, разрабатываемым впредь, следует соответствующим образом реализовать защиту на основе RPCSEC_GSS. В [RFC2623] описано, как это сделано в широко распространённой программе RPC.

Службы RPC со статусом Standards Track должны требовать поддержку RPCSEC_GSS, а также должны требовать поддержку псевдо-варианта аутентификации с подходящим уровнем безопасности в зависимости от потребности в проверке подлинности, защите целостности (т. е. неотказуемости) и приватности данных.

Приложение A. Системная аутентификация

Клиент может пожелать идентифицировать себя, как это делается в системе UNIX(tm). Этот вариант свидетельства клиента называется AUTH_SYS. Неинтерпретируемые (opaque) данные свидетельства представляют собой структуру

         struct authsys_parms {
            unsigned int stamp;
            string machinename<255>;
            unsigned int uid;
            unsigned int gid;
            unsigned int gids<16>;
         };

Поле stamp содержит произвольный идентификатор, который может генерировать вызывающая машина, machinename указывает имя этой машины (например, krypton). Поле uid содержит идентификатор вызывающего пользователя, gid — идентификатор действующей группы, а gids содержит массив идентификаторов групп, в которые входит вызывающий пользователь. Верификатору, сопровождающему свидетельство (credential), следует иметь значение AUTH_NONE (см. выше). Отметим, что свидетельство будет уникальным лишь в рамках отдельного домена имён машин, uid и gid.

Значением верификатора в отклике сервера может быть AUTH_NONE или AUTH_SHORT. В случае AUTH_SHORT байты строки верификатора содержат неинтерпретируемую (opaque) структуру, которая может быть передана серверу вместо исходного свидетельства варианта AUTH_SYS. Сервер может хранить кэш, сопоставляющий сокращённые opaque-структуры (передаются обратно в стиле верификатора отклика AUTH_SHORT) с исходными свидетельствами вызывающего. Вызывающий может сэкономить пропускную способность и ресурсы серверного процессора, используя сокращённое свидетельство. Сервер может в любой момент сбросить сокращённую opaque-структуру. В этом случае сообщение с вызовом удалённой процедуры будет отвергнуто с ошибкой аутентификации (причина AUTH_REJECTEDCRED). Тогда клиент может попытаться применить исходное свидетельство AUTH_SYS.

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

Приложение B. Запрос связанных с RPC номеров в IANA

Номера программ RPC, вариантов и статуса аутентификации, которые должны быть уникальными во всех сетях, выделяются Internet Assigned Number Authority (IANA). Для запроса одного или блока номеров нужно отправить в IANA по адресу <iana@iana.org> запрос, содержащий указанные ниже сведения.

Тип запрашиваемых номеров (для программ, вариантов аутентификации или кодов аутентификации).
Число запрашиваемых номеров.
Имя физического лица или название компании, которая будет использовать номера.
Строка идентификатора, связывающая номера со службой.
Адрес электронной почты для контактов со службой, использующей номера.
Краткое описание цели использования номеров.
При запросе номеров для вариантов аутентификации и псевдо-вариантов для использования с RPCSEC_GSS и NFS, отображения, аналогичные приведённым в параграфе 4.2 [RFC2623].

Запросить конкретные номера нельзя, они распределяются по порядку (First Come First Served).

Для всех вариантов и статусов аутентификации RPC, применяемых в Internet, настоятельно рекомендуется публикация RFC категории Informational или Standards Track с описанием поведения и параметров механизма аутентификации.

Приложение C. Выделенные номера

   #
   # Выделенные Sun номера RPC
   #
   # Описание и владелец            Номер RPC   Краткое имя
   # -----------------------------------------------------------------
   portmapper                         100000    pmapprog portmap rpcbind
   remote stats                       100001    rstatprog
   remote users                       100002    rusersprog
   nfs                                100003    nfs
   yellow pages (NIS)                 100004    ypprog ypserv
   mount demon                        100005    mountprog
   remote dbx                         100006    dbxprog
   yp binder (NIS)                    100007    ypbindprog ypbind
   shutdown msg                       100008    wall
   yppasswd server                    100009    yppasswdprog yppasswdd
   ether stats                        100010    etherstatprog
   disk quotas                        100011    rquota
   spray packets                      100012    spray
   3270 mapper                        100013    ibm3270prog
   RJE mapper                         100014    ibmrjeprog
   selection service                  100015    selnsvcprog
   remote database access             100016    rdatabaseprog
   remote execution                   100017    rexec
   Alice Office Automation            100018    aliceprog
   scheduling service                 100019    schedprog
   local lock manager                 100020    lockprog llockmgr
   network lock manager               100021    netlockprog nlockmgr
   x.25 inr protocol                  100022    x25prog
   status monitor 1                   100023    statmon1
   status monitor 2                   100024    statmon2
   selection library                  100025    selnlibprog
   boot parameters service            100026    bootparam
   mazewars game                      100027    mazeprog
   yp update (NIS)                    100028    ypupdateprog ypupdate
   key server                         100029    keyserveprog
   secure login                       100030    securecmdprog
   nfs net forwarder init             100031    netfwdiprog
   nfs net forwarder trans            100032    netfwdtprog
   sunlink MAP                        100033    sunlinkmap
   network monitor                    100034    netmonprog
   lightweight database               100035    dbaseprog
   password authorization             100036    pwdauthprog
   translucent file svc               100037    tfsprog
   nse server                         100038    nseprog
   nse activate daemon                100039    nse_activate_prog
   sunview help                       100040    sunview_help_prog
   pnp install                        100041    pnp_prog
   ip addr allocator                  100042    ipaddr_alloc_prog
   show filehandle                    100043    filehandle
   MVS NFS mount                      100044    mvsnfsprog
   remote user file operations        100045    rem_fileop_user_prog
   batched ypupdate                   100046    batch_ypupdateprog
   network execution mgr              100047    nem_prog
   raytrace/mandelbrot remote daemon  100048    raytrace_rd_prog
   raytrace/mandelbrot local daemon   100049    raytrace_ld_prog
   remote group file operations       100050    rem_fileop_group_prog
   remote system file operations      100051    rem_fileop_system_prog
   remote system role operations      100052    rem_system_role_prog
   gpd lego fb simulator              100053    [неизвестно]
   gpd simulator interface            100054    [неизвестно]
   ioadmd                             100055    ioadmd
   filemerge                          100056    filemerge_prog
   Name Binding Program               100057    namebind_prog
   sunlink NJE                        100058    njeprog
   MVSNFS get attribute service       100059    mvsattrprog
   SunAccess/SunLink resource manager 100060    rmgrprog
   UID allocation service             100061    uidallocprog
   license broker                     100062    lbserverprog
   NETlicense client binder           100063    lbbinderprog
   GID allocation service             100064    gidallocprog
   SunIsam                            100065    sunisamprog
   Remote Debug Server                100066    rdbsrvprog
   Network Directory Daemon           100067    [неизвестно]
   Network Calendar Program           100068    cmsd cm
   ypxfrd                             100069    ypxfrd
   rpc.timed                          100070    timedprog
   bugtraqd                           100071    bugtraqd
                                      100072    [неизвестно]
   Connectathon Billboard - NFS       100073    [неизвестно]
   Connectathon Billboard - X         100074    [неизвестно]
   Sun tool for scheduling rooms      100075    schedroom
   Authentication Negotiation         100076    authnegotiate_prog
   Database manipulation              100077    attribute_prog
   Kerberos authentication daemon     100078    kerbprog
   Internal testing product (no name) 100079    [неизвестно]
   Sun Consulting Special             100080    autodump_prog
   Event protocol                     100081    event_svc
   bugtraq_qd                         100082    bugtraq_qd
   ToolTalk and Link Service Project  100083    database service
   Consulting Services                100084    [неизвестно]
   Consulting Services                100085    [неизвестно]
   Consulting Services                100086    [неизвестно]
   Jupiter Administration             100087    adm_agent admind
   Dual Disk support                  100090    libdsd/dsd
   DocViewer 1.1                      100091    [неизвестно]
   ToolTalk                           100092    remote_activation_svc
   Consulting Services                100093    host_checking
   SNA peer-to-peer                   100094    [неизвестно]
   Roger Riggs                        100095    searchit
   Robert Allen                       100096    mesgtool
   SNA                                100097    [неизвестно]
   SISU                               100098    networked version of CS5
   NFS Automount File System          100099    autofs
                                      100100    msgboard
   event dispatching agent [eventd]   100101    netmgt_eventd_prog
   statistics/event logger [netlogd]  100102    netmgt_netlogd_prog
   topology display manager [topology]100103    netmgt_topology_prog
   syncstat agent [syncstatd]         100104    netmgt_syncstatd_prog
   ip packet stats agent [ippktd]     100105    netmgt_ippktd_prog
   netmgt config agent [configd]      100106    netmgt_configd_prog
   restat agent [restatd]             100107    netmgt_restatd_prog
   lpq agent [lprstatd]               100108    netmgt_lprstatd_prog
   netmgt activity agent [mgtlogd]    100109    netmgt_mgtlogd_prog
   proxy DECnet NCP agent [proxydni]  100110    netmgt_proxydni_prog
   topology mapper agent [mapperd]    100111    netmgt_mapperd_prog
   netstat agent [netstatd]           100112    netmgt_netstatd_prog
   sample netmgt agent [sampled]      100113    netmgt_sampled_prog
   X.25 statistics agent [vcstatd]    100114    netmgt_vcstatd_prog
   Frame Relay                        100128    [неизвестно]
   PPP agent                          100129    [неизвестно]
   localhad                           100130    rpc.localhad
   layers2                            100131    na.layers2
   token ring agent                   100132    na.tr
   related to lockd and statd         100133    nsm_addr
   Kerberos project                   100134    kwarn
   ertherif2                          100135    na.etherif2
   hostmem2                           100136    na.hostmem2
   iostat2                            100137    na.iostat2
   snmpv2                             100138    na.snmpv2
   Cooperative Console                100139    cc_sender
   na.cpustat                         100140    na.cpustat
   Sun Cluster SC3.0                  100141    rgmd_receptionist
                                      100142    fed
   Network Storage                    100143    rdc
   Sun Cluster products               100144    nafo
   SunCluster 3.0                     100145    scadmd
   ASN.1                              100146    amiserv
                                      100147    amiaux # BER и DER,
                                              кодирование и декодирование
   Delegate Management Server         100148    dm
                                      100149    rkstat
                                      100150    ocfserv
                                      100151    sccheckd
                                      100152    autoclientd
                                      100153    sunvts
                                      100154    ssmond
                                      100155    smserverd
                                      100156    test1
                                      100157    test2
                                      100158    test3
                                      100159    test4
                                      100160    test5
                                      100161    test6
                                      100162    test7
                                      100163    test8
                                      100164    test9
                                      100165    test10
                                      100166    nfsmapid
                                      100167    SUN_WBEM_C_CIMON_HANDLE
                                      100168    sacmmd
                                      100169    fmd_adm
                                      100170    fmd_api
                                      100171    [неизвестно]
                                      100172    idmapd
   не выделены                        100173 - 100174
   snmptrap                           100175    na.snmptrap
   не выделены                        100176-100199

   не выделены                        100200
   MVS/NFS Memory usage stats server  100201    [неизвестно]
   Netapp                             100202-100207
   не выделены                        100208-100210
   8.0 SunLink SNA RJE                100211    [неизвестно]
   8.0 SunLink SNA RJE                100212    [неизвестно]
                                      100213    ShowMe
                                      100214    [неизвестно]
                                      100215    [неизвестно]
   AUTH_RSA Key service               100216    keyrsa
   SunSelect PC license service       100217    [неизвестно]
   WWCS (Corporate)                   100218    sunsolve
                                      100219    cstatd
   X/Open Federated Naming            100220    xfn_server_prog
   Kodak Color Management System      100221    kcs_network_io kcs
   HA-DBMS                            100222    ha_dbms_serv
                                      100223-100225    [неизвестно]
                                      100226    hafaultd
   NFS ACL Service                    100227    nfs_acl
   distributed lock manager           100228    dlmd
                                      100229    metad
                                      100230    metamhd
                                      100231    nfsauth
                                      100232    sadmind
                                      100233    ufsd
                                      100234    grpservd
                                      100235    cachefsd
                                      100236    msmprog Media_Server
                                      100237    ihnamed
                                      100238    ihnetd
                                      100239    ihsecured
                                      100240    ihclassmgrd
                                      100241    ihrepositoryd
                                      100242    metamedd rpc.metamedd
                                      100243    contentmanager cm
                                      100244    symon
                                      100245    pld genesil
                                      100246    ctid
                                            cluster_transport_interface
                                      100247    ccd
                                            cluster_configuration_db
                                      100248    pmfd
                                      100249    dmi2_client
                                      100250    mfs_admin
                                      100251    ndshared_unlink
                                      100252    ndshared_touch
                                      100253    ndshared_slink
                                      100254    cbs control_board_server
                                      100255    skiserv
                                      100256    nfsxa nfsxattr
                                      100257    ndshared_disable
                                      100258    ndshared_enable
                                      100259    sms_account_admin
                                      100260    sms_modem_admin
                                      100261    sms_r_login
                                      100262    sms_r_subaccount_mgt
                                      100263    sms_service_admin
                                      100264    session_admin
                                      100265    canci_ancs_program
                                      100266    canci_sms_program
                                      100267    msmp
                                      100268    halck
                                      100269    halogmsg
                                      100270    nfs_id_map
                                      100271    ncall
                                      100272    hmip
                                      100273    repl_mig
                                      100274    repl_mig_cb

   NIS+                               100300    nisplus
   NIS+                               100301    nis_cachemgr
   NIS+ call back protocol            100302    [неизвестно]
   NIS+ Password Update Daemon        100303    nispasswdd
   FNS context update in NIS          100304    fnsypd
                                      100305    [неизвестно]
                                      100306    [неизвестно]
                                      100307    [неизвестно]
                                      100308    [неизвестно]
                                      100309    [неизвестно]
   не выделены                        100310 - 100398
   nfscksum                           100399    nfscksum
   network utilization agent          100400    netmgt_netu_prog
   network rpc ping agent             100401    netmgt_rping_prog
                                      100402    na.shell
   picsprint                          100403    na.picslp
                                      100404    traps
                                      100405 - 100409 [неизвестно]
                                      100410    jdsagent
                                      100411    na.haconfig
                                      100412    na.halhost
                                      100413    na.hadtsrvc
                                      100414    na.hamdstat
                                      100415    na.neoadmin
                                      100416    ex1048prog
   rdmaconfig                         100417    rpc.rdmaconfig
   IETF NFSv4 Working Group - FedFS   100418 - 100421
                                      100422    mdcommd
                                      100423    kiprop krb5_iprop
                                      100424    stsf
   не выделены                        100425 - 100499
   Sun Microsystems                   100500 - 100531 [неизвестно]
                                      100532    ucmmstate
                                      100533    scrcmd
   не выделены                        100534 - 100999
   nse link daemon                    101002    nselinktool
   nse link application               101003    nselinkapp
   unassigned                         101004 - 101900
                                      101901    [неизвестно]
   не выделены                        101902 - 101999
   AssetLite                          102000    [неизвестно]
   PagerTool                          102001    [неизвестно]
   Discover                           102002    [неизвестно]
   не выделены                        102003 - 105000
   ShowMe                             105001    sharedapp
   Registry                           105002    REGISTRY_PROG
   Print-server                       105003    print-server
   Proto-server                       105004    proto-server
   Notification-server                105005    notification-server
   Transfer-agent-server              105006    transfer-agent-server
   не выделены                        105007 - 110000
                                      110001    tsolrpcb
                                      110002    tsolpeerinfo
                                      110003    tsolboot
                                      120001    cmip na.cmip
                                      120002    na.osidiscover
                                      120003    cmiptrap
   не выделены                        120004 - 120099
                                      120100    eserver
                                      120101    repserver
                                      120102    swserver
                                      120103    dmd
                                      120104    ca
   не выделены                        120105 - 120125
                                      120126    nf_fddi
                                      120127    nf_fddismt7_2
   не выделены                        120128 - 150000
   pc passwd authorization            150001    pcnfsdprog
   TOPS name mapping                  150002    [неизвестно]
   TOPS external attribute storage    150003    [неизвестно]
   TOPS hierarchical file system      150004    [неизвестно]
   TOPS NFS transparency extensions   150005    [неизвестно]
   PC NFS License                     150006    pcnfslicense
   RDA                                150007    rdaprog
   WabiServer                         150008    wsprog
   WabiServer                         150009    wsrlprog
   не выделены                        150010 - 160000
                                      160001    nihon-cm
                                      160002    nihon-ce
   не выделены                        160003 - 170099
                                      170100    domf_daemon0
                                      170101    domf_daemon1
                                      170102    domf_daemon2
                                      170103    domf_daemon3
                                      170104    domf_daemon4
                                      170105    domf_daemon5
   не выделены                        170106 - 179999
                                      180000    cecprog
                                      180001    cecsysprog
                                      180002    cec2cecprog
                                      180003    cesprog
                                      180004    ces2cesprog
                                      180005    cet2cetprog
                                      180006    cet2cetdoneprog
                                      180007    cetcomprog
                                      180008    cetsysprog
                                      180009    cghapresenceprog
                                      180010    cgdmsyncprog
                                      180011    cgdmcnscliprog
                                      180012    cgdmcrcscliprog
                                      180013    cgdmcrcssvcproG
                                      180014    chmprog
                                      180015    chmsysprog
                                      180016    crcsapiprog
                                      180017    ckptmprog
                                      180018    crimcomponentprog
                                      180019    crimqueryprog
                                      180020    crimsecondaryprog
                                      180021    crimservicesprog
                                      180022    crimsyscomponentprog
                                      180023    crimsysservicesprog
                                      180024    csmagtapiprog
                                      180025    csmagtcallbackprog
                                      180026    csmreplicaprog
                                      180027    csmsrvprog
                                      180028    cssccltprog
                                      180029    csscsvrprog
                                      180030    csscopresultprog
   не выделены                        180031 - 199999
                                      200000    pyramid_nfs
                                      200001    pyramid_reserved
                                      200002    cadds_image
                                      200003    stellar_name_prog
                                      200004    [неизвестно]
                                      200005    [неизвестно]
                                      200006    pacl
                                      200007    lookupids
                                      200008    ax_statd_prog
                                      200009    ax_statd2_prog
                                      200010    edm
                                      200011    dtedirwd
                                      200012    [неизвестно]
                                      200013    [неизвестно]
                                      200014    [неизвестно]
                                      200015    [неизвестно]
                                      200016    easerpcd
                                      200017    rlxnfs
                                      200018    sascuiddprog
                                      200019    knfsd
                                      200020    ftnfsd ftnfsd_program
                                      200021    ftsyncd ftsyncd_program
                                      200022    ftstatd ftstatd_program
                                      200023    exportmap
                                      200024    nfs_metadata
   не выделены                        200025 - 200200
                                      200201    ecoad
                                      200202    eamon
                                      200203    ecolic
                                      200204    cs_printstatus_svr
                                      200205    ecodisc
   не выделены                        200206 - 300000
                                      300001    adt_rflockprog
                                      300002    columbine1
                                      300003    system33_prog
                                      300004    frame_prog1
                                      300005    uimxprog
                                      300006    rvd
                                      300007    entombing daemon
                                      300008    account mgmt system
                                      300009    frame_prog2
                                      300010    beeper access
                                      300011    dptuprog
                                      300012    mx-bcp
                                      300013    instrument-file-access
                                      300014    file-system-statistics
                                      300015    unify-database-server
                                      300016    tmd_msg
                                      300017    [неизвестно]
                                      300018    [неизвестно]
                                      300019    automounter access
                                      300020    lock server
                                      300021    [неизвестно]
                                      300022    office-automation-1
                                      300023    office-automation-2
                                      300024    office-automation-3
                                      300025    office-automation-4
                                      300026    office-automation-5
                                      300027    office-automation-6
                                      300028    office-automation-7
                                      300029    local-data-manager
                                      300030    chide
                                      300031    csi_program
                                      300032    [неизвестно]
                                      300033    online-help
                                      300034    case-tool
                                      300035    delta
                                      300036    rgi
                                      300037    instrument-config-server
                                      300038    [неизвестно]
                                      300039    [неизвестно]
                                      300040    dtia-rpc-server
                                      300041    cms
                                      300042    viewer
                                      300043    aqm
                                      300044    exclaim
                                      300045    masterplan
                                      300046    fig_tool
                                      300047    [неизвестно]
                                      300048    [неизвестно]
                                      300049    [неизвестно]
                                      300050    remote-lock-manager
                                      300051    [неизвестно]
                                      300052    gdebug
                                      300053    ldebug
                                      300054    rscanner
                                      300055    [неизвестно]
                                      300056    [неизвестно]
                                      300057    [неизвестно]
                                      300058    [неизвестно]
                                      300059    [неизвестно]
                                      300060    [неизвестно]
                                      300061    [неизвестно]
                                      300062    [неизвестно]
                                      300063    [неизвестно]
                                      300064    [неизвестно]
                                      300065    [неизвестно]
                                      300066    nSERVER
                                      300067    [неизвестно]
                                      300068    [неизвестно]
                                      300069    [неизвестно]
                                      300070    [неизвестно]
                                      300071    BioStation
                                      300072    [неизвестно]
                                      300073    NetProb
                                      300074    Logging
                                      300075    Logging
                                      300076    [неизвестно]
                                      300077    [неизвестно]
                                      300078    [неизвестно]
                                      300079    [неизвестно]
                                      300080    [неизвестно]
                                      300081    [неизвестно]
                                      300082    sw_twin
                                      300083    remote_get_login
                                      300084    odcprog
                                      300085    [неизвестно]
                                      300086    [неизвестно]
                                      300087    [неизвестно]
                                      300088    [неизвестно]
                                      300089    [неизвестно]
                                      300090    [неизвестно]
                                      300091    smartdoc
                                      300092    superping
                                      300093    distributed-chembench
                                      300094    uacman/alfil-uacman
                                      300095    ait_rcagent_prog
                                      300096    ait_rcagent_appl_prog
                                      300097    smart
                                      300098    ecoprog
                                      300099    leonardo
                                      300100    [неизвестно]
                                      300101    [неизвестно]
                                      300102    [неизвестно]
                                      300103    [неизвестно]
                                      300104    [неизвестно]
                                      300105    [неизвестно]
                                      300106    [неизвестно]
                                      300107    [неизвестно]
                                      300108    wingz
                                      300109    teidan
                                      300110    [неизвестно]
                                      300111    [неизвестно]
                                      300112    [неизвестно]
                                      300113    [неизвестно]
                                      300114    [неизвестно]
                                      300115    [неизвестно]
                                      300116    cadc_fhlockprog
                                      300117    highscan
                                      300118    [неизвестно]
                                      300119    [неизвестно]
                                      300120    [неизвестно]
                                      300121    opennavigator
                                      300122    aarpcxfer
                                      300123    [неизвестно]
                                      300124    [неизвестно]
                                      300125    [неизвестно]
                                      300126    groggs
                                      300127    licsrv
                                      300128    issdemon
                                      300129    [неизвестно]
                                      300130    maximize
                                      300131    cgm_server
                                      300132    [неизвестно]
                                      300133    agent_rpc
                                      300134    docmaker
                                      300135    docmaker
                                      300136    [неизвестно]
                                      300137    [неизвестно]
                                      300138    [неизвестно]
                                      300139    iesx
                                      300140    [неизвестно]
                                      300141    [неизвестно]
                                      300142    [неизвестно]
                                      300143    [неизвестно]
                                      300144    smart-mbs
                                      300145    [неизвестно]
                                      300146    [неизвестно]
                                      300147    docimage
                                      300148    [неизвестно]
                                      300149    dmc-interface
                                      300150    [неизвестно]
                                      300151    jss
                                      300152    [неизвестно]
                                      300153    arimage
                                      300154    xdb-workbench
                                      300155    frontdesk
                                      300156    dmc
                                      300157    expressight-6000
                                      300158    graph service program
                                      300159    [неизвестно]
                                      300160    [неизвестно]
                                      300161    [неизвестно]
                                      300162    [неизвестно]
                                      300163    [неизвестно]
                                      300164    [неизвестно]
                                      300165    [неизвестно]
                                      300166    [неизвестно]
                                      300167    [неизвестно]
                                      300168    [неизвестно]
                                      300169    [неизвестно]
                                      300170    [неизвестно]
                                      300171    [неизвестно]
                                      300172    [неизвестно]
                                      300173    [неизвестно]
                                      300174    [неизвестно]
                                      300175    [неизвестно]
                                      300176    rlpr
                                      300177    nx_hostdprog
                                      300178    netuser-x
                                      300179    rmntprog
                                      300180    [неизвестно]
                                      300181    mipe
                                      300182    [неизвестно]
                                      300183    collectorprog
                                      300184    uslookup_PROG
                                      300185    viewstation
                                      300186    iate
                                      300187    [неизвестно]
                                      300188    [неизвестно]
                                      300189    [неизвестно]
                                      300190    imsvtprog
                                      300191    [неизвестно]
                                      300192    [неизвестно]
                                      300193    [неизвестно]
                                      300194    pmdb
                                      300195    pmda
                                      300196    [неизвестно]
                                      300197    [неизвестно]
                                      300198    trend_idbd
                                      300199    rres
                                      300200    sd.masterd
                                      300201    sd.executiond
                                      300202    sd.listend
                                      300203    sd.reserve1
                                      300204    sd.reserve2
                                      300205    msbd
                                      300206    stagedprog
                                      300207    mountprog
                                      300208    watchdprog
                                      300209    pms
                                      300210    [неизвестно]
                                      300211    session_server_program
                                      300212    session_program
                                      300213    debug_serverprog
                                      300214    [неизвестно]
                                      300215    [неизвестно]
                                      300216    paceprog
                                      300217    [неизвестно]
                                      300218    mbus
                                      300219    aframes2ps
                                      300220    npartprog
                                      300221    cm1server
                                      300222    cm1bridge
                                      300223    sailfrogfaxprog
                                      300224    sailfrogphoneprog
                                      300225    sailfrogvmailprog
                                      300226    wserviceprog arcstorm
                                      300227    hld
                                      300228    alive
                                      300229    radsp
                                      300230    radavx
                                      300231    radview
                                      300232    rsys_prog
                                      300233    rsys_prog
                                      300234    fm_rpc_prog
                                      300235    aries
                                      300236    uapman
                                      300237    ddman
                                      300238    top
                                      300239    [неизвестно]
                                      300240    trendlink
                                      300241    licenseprog
                                      300242    statuslicenseprog
                                      300243    oema_rmpf_svc
                                      300244    oema_smpf_svc
                                      300245    oema_rmsg_svc
                                      300246    grapes-sd
                                      300247    ds_master
                                      300248    ds_transfer
                                      300249    ds_logger
                                      300250    ds_query
                                      300251    [неизвестно]
                                      300252    [неизвестно]
                                      300253    nsd_prog
                                      300254    browser
                                      300255    epoch
                                      300256    floorplanner
                                      300257    reach
                                      300258    tactic
                                      300259    cachescientific1
                                      300260    cachescientific2
                                      300261    desksrc_prog
                                      300262    photo3d1
                                      300263    photo3d2
                                      300264    [неизвестно]
                                      300265    soundmgr
                                      300266    s6k
                                      300267    aims_referenced_
                                                text_processor
                                      300268    xess
                                      300269    ds_queue
                                      300270    [неизвестно]
                                      300271    orionscanplus
                                      300272    openlink-xx
                                      300273    kbmsprog
                                      300274    [неизвестно]
                                      300275    futuresource
                                      300276    the_xprt
                                      300277    cmg_srvprog
                                      300278    [неизвестно]
                                      300279    [неизвестно]
                                      300280    front
                                      300281    [неизвестно]
                                      300282    [неизвестно]
                                      300283    [неизвестно]
                                      300284    conmanprog
                                      300285    jincv2
                                      300286    isls
                                      300287    systemstatprog
                                      300288    fxpsprog
                                      300289    callpath
                                      300290    axess
                                      300291    armor_rpcd
                                      300292    armor_dictionary_rpcd
                                      300293    armor_miscd
                                      300294    filetransfer_prog
                                      300295    bl_swda
                                      300296    bl_hwda
                                      300297    [неизвестно]
                                      300298    [неизвестно]
                                      300299    [неизвестно]
                                      300300    filemon
                                      300301    acunetprog
                                      300302    rbuild
                                      300303    assistprog
                                      300304    tog
                                      300305    [неизвестно]
                                      300306    sns7000
                                      300307    igprog
                                      300308    tgprog
                                      300309    plc
                                      300310    pxman pxlsprog
                                      300311    hde_server hdeserver
                                      300312    tsslicenseprog
                                      300313    rpc.explorerd
                                      300314    chrd
                                      300315    tbisam
                                      300316    tbis
                                      300317    adsprog
                                      300318    sponsorprog
                                      300319    querycmprog
                                      300320    [неизвестно]
                                      300321    [неизвестно]
                                      300322    mobil1
                                      300323    sld
                                                service_locator_daemon
                                      300324    linkprog
                                      300325    codexdaemonprog
                                      300326    drprog
                                      300327    ressys_commands
                                      300328    stamp
                                      300329    matlab
                                      300330    sched1d
                                      300331    upcprog
                                      300332    xferbkch
                                      300333    xfer
                                      300334    qbthd
                                      300335    qbabort
                                      300336    lsd
                                      300337    geomgrd
                                      300338    generic_fts
                                      300339    ft_ack
                                      300340    lymb
                                      300341    vantage
                                      300342    cltstd clooptstdprog
                                      300343    clui clui_prog
                                      300344    testerd tstdprog
                                      300345    extsim
                                      300346    cmd_dispatch maxm_ems
                                      300347    callpath_receive_program
                                      300348    x3270prog
                                      300349    sbc_lag
                                      300350    sbc_frsa
                                      300351    sbc_frs
                                      300352    atommgr
                                      300353    geostrat
                                      300354    dbvialu6.2
                                      300355    [неизвестно]
                                      300356    fxncprog
                                      300357    infopolic
                                      300358    [неизвестно]
                                      300359    aagns
                                      300360    aagms
                                      300361    [неизвестно]
                                      300362    clariion_mgr
                                      300363    setcimrpc
                                      300364    virtual_protocol_adapter
                                      300365    unibart
                                      300366    uniarch
                                      300367    unifile
                                      300368    unisrex
                                      300369    uniscmd
                                      300370    rsc
                                      300371    set
                                      300372    desaf-ws/key
                                      300373    reeldb
                                      300374    nl
                                      300375    rmd
                                      300376    agcd
                                      300377    rsynd
                                      300378    rcnlib
                                      300379    rcnlib_attach
                                      300380    evergreen_mgmt_agent
                                      300381    fx104prog
                                      300382    rui
                                                remote_user_interface
                                      300383    ovomd
                                      300384    [неизвестно]
                                      300385    [неизвестно]
                                      300386    system_server
                                      300387    pipecs cs_pipeprog
                                                ppktrpc
                                      300388    uv-net univision
                                      300389    auexe
                                      300390    audip
                                      300391    mqi
                                      300392    eva
                                      300393    eeei_reserved_1
                                      300394    eeei_reserved_2
                                      300395    eeei_reserved_3
                                      300396    eeei_reserved_4
                                      300397    eeei_reserved_5
                                      300398    eeei_reserved_6
                                      300399    eeei_reserved_7
                                      300400    eeei_reserved_8
                                      300401    cprlm
                                      300402    wg_idms_manager
                                      300403    timequota
                                      300404    spiff
                                      300405-300414        ov_oem_svc
                                      300415    ov_msg_ctlg_svc
                                      300416    ov_advt_reg_svc
                                      300417-300424  showkron
                                      300425    daatd
                                      300426    swiftnet
                                      300427    ovomdel
                                      300428    ovomreq
                                      300429    msg_dispatcher
                                      300430    pcshare server
                                      300431    rcvs
                                      300432    fdfserver
                                      300433    bssd
                                      300434    drdd
                                      300435    mif_gutsprog
                                      300436    mif_guiprog
                                      300437    twolfd
                                      300438    twscd
                                      300439    nwsbumv
                                      300440    dgux_mgr
                                      300441    pfxd
                                      300442    tds
                                      300443    ovomadmind
                                      300444    ovomgate
                                      300445    omadmind
                                      300446    nps
                                      300447    npd
                                      300448    tsa
                                      300449    cdaimc
   не выделены                        300450-300452
                                      300453    ckt_implementation
                                      300454    mda-tactical
   не выделены                        300455-300458
                                      300459    atrrun
                                      300460    RoadRunner
                                      300461    nas
                                      300462    undelete
                                      300463    ovacadd
                                      300464    tbdesmai
                                      300465    arguslm
                                      300466    dmd
                                      300467    drd
                                      300468    fm_help
                                      300469    ftransrpc_prog
                                      300470    finrisk
                                      300471    dg_pc_idisched
                                      300472    dg_pc_idiserv
                                      300473    apd
                                      300474    ap_sspd
                                      300475    callpatheventrecorder
                                      300476    flc
                                      300477    dg_osm
                                      300478    dspnamed
                                      300479    iqddsrv
                                      300480    iqjobsrv
                                      300481    tacosxx
                                      300482    wheeldbmg
                                      300483    cnxmgr_nm_prog
                                      300484    cnxmgr_cfg_prog
                                      300485    3dsmapper
                                      300486    ids
                                      300487    imagine_rpc_svc
                                      300488    lfn
                                      300489    salesnet
                                      300490    defaxo
                                      300491    dbqtsd
                                      300492    kms
                                      300493    rpc.iced
                                      300494    calc2s
                                      300495    ptouidprog
                                      300496    docsls
                                      300497    new
                                      300498    collagebdg
                                      300499    ars_server
                                      300500    ars_client
                                      300501    vr_catalog
                                      300502    vr_tdb
                                      300503    ama
                                      300504    evama
                                      300505    conama
                                      300506    service_process
                                      300507    reuse_proxy
                                      300508    mars_ctrl
                                      300509    mars_db
                                      300510    mars_com
                                      300511    mars_admch
                                      300512    tbpipcip
                                      300513    top_acs_svc
                                      300514    inout_svc
                                      300515    csoft_wp
                                      300516    mcfs
                                      300517    eventprog
                                      300518    dg_pc_idimsg
                                      300519    dg_pc_idiaux
                                      300520    atsr_gc
                                      300521    alarm alarm_prog
                                      300522    fts_prog
                                      300523    dcs_prog
                                      300524    ihb_prog
                                      300525    [неизвестно]
                                      300526    [неизвестно]
                                      300527    clu_info_prog
                                      300528    rmfm
                                      300529    c2sdocd
                                      300530    interahelp
                                      300531    callpathasyncmsghandler
                                      300532    optix_arc
                                      300533    optix_ts
                                      300534    optix_wf
                                      300535    maxopenc
                                      300536    cev cev_server
                                      300537    sitewideprog
                                      300538    drs
                                      300539    drsdm
                                      300540    dasgate
                                      300541    dcdbd
                                      300542    dcpsd
                                      300543    supportlink_prog
                                      300544    broker
                                      300545    listner
                                      300546    multiaccess
                                      300547    spai_interface
                                      300548    spai_adaption
                                      300549    chimera_ci
                                                chimera_clientinterface
                                      300550    chimera_pi
                                                chimera_processinvoker
                                      300551    teamware_fl
                                                teamware_foundationlevel
                                      300552    teamware_sl
                                                teamware_systemlevel
                                      300553    teamware_ui
                                                teamware_userinterface
                                      300554    lprm
                                      300555    mpsprog
                                                Mensuration_Proxy_Server
                                      300556    mo_symdis
                                      300557    retsideprog
                                      300558    slp
                                      300559    slm-api
                                      300560    im_rpc teamconference
                                      300561    license_prog license
                                      300562    stuple stuple_prog
                                      300563    upasswd_prog
                                      300564    gentranmentorsecurity
                                      300565    gentranmentorprovider
                                      300566    latituded
                                                latitude_license_server
                                      300567    gentranmentorreq1
                                      300568    gentranmentorreq2
                                      300569    gentranmentorreq3
                                      300570    rj_server
                                      300571    gws-rdb
                                      300572    gws-mpmd
                                      300573    gws-spmd
                                      300574    vwcalcd
                                      300575    vworad
                                      300576    vwsybd
                                      300577    vwave
                                      300578    online_assistant
                                      300579    internet_assistant
                                      300580    spawnd
                                      300581    procmgrg
                                      300582    cfgdbd
                                      300583    logutild
                                      300584    ibis
                                      300585    ibisaux
                                      300586    aapi
                                      300587    rstrt
                                      300588    hbeat
                                      300589    pcspu
                                      300590    empress
                                      300591    sched_server
                                                LiveScheduler
                                      300592    path_server
                                                LiveScheduler
                                      300593    c2sdmd
                                      300594    c2scf
                                      300595    btsas
                                      300596    sdtas
                                      300597    appie
                                      300598    dmi
                                      300599    pscd
                                            panther software corp daemon
                                      300600    sisd
                                      300601    cpwebserver
                                      300602    wwcommo
                                      300603    mx-mie
                                      300604    mx-mie-debug
                                      300605    idmn
                                      300606    ssrv
                                      300607    vpnserver
                                      300608    samserver
                                      300609    sams_server
                                      300610    chrysalis
                                      300611    ddm
                                      300612    ddm-is
                                      300613    mx-bcp-debug
                                      300614    upmrd
                                      300615    upmdsd
                                      300616    res
                                      300617    colortron
                                      300618    zrs
                                      300619    afpsrv
                                      300620    apxft
                                      300621    nrp
                                      300622    hpid
                                      300623    mailwatch
                                      300624    fos bc_fcrb_receiver
                                      300625    cs_sysadmin_svr
                                      300626    cs_controller_svr
                                      300627    nokia_nms_eai
                                      300628    dbg
                                      300629    remex
                                      300630    cs_bind
                                      300631    idm
                                      300632    prpasswd
                                      300633    iw-pw
                                      300634    starrb
                                      300635    Impress_Server
                                      300636    colorstar
                                      300637    gwugui
                                      300638    gwsgui
                                      300639    dai_command_proxy
                                      300640    dai_alarm_server
                                      300641    dai_fui_proxy
                                      300642    spai_command_proxy
                                      300643    spai_alarm_server
                                      300644    iris
                                      300645    hcxttp
                                      300646    updatedb rsched
                                      300647    urnd urn
                                      300648    iqwpsrv
                                      300649    dskutild
                                      300650    online
                                      300651    nlserv
                                      300652    acsm
                                      300653    dg_clar_sormsg
                                      300654    wwpollerrpc
                                      300655    wwmodelrpc
                                      300656    nsprofd
                                      300657    nsdistd
                                      300658    recollect
                                      300659    lssexecd lss_res
                                      300660    lssagend lss_rea
                                      300661    cdinfo
                                      300662    sninsr_addon
                                      300663    mm-sap
                                      300664    ks
                                      300665    psched
                                      300666    tekdvfs
                                      300667    storxll
                                      300668    nisse
                                      300669    lbadvise
                                      300670    atcinstaller
                                      300671    atntstarter
                                      300672    NetML
                                      300673    tdmesmge
                                      300674    tdmesmgd
                                      300675    tdmesmgt
                                      300676    olm
                                      300677    mediamanagement
                                      300678    rdbprog fieldowsrv
                                      300679    rpwdprog rpwd
                                      300680    sapi-trace
                                      300681    sapi-master-daemon
                                      300682    omdcuprog om-dcu
                                      300683    wwprocmon
                                      300684    tndidprog
                                      300685    rkey_setsecretprog
                                      300686    asdu_server_prog
                                      300687    pwrcntrl
                                      300688    siunixd
                                      300689    wmapi
                                      300690    cross_reference_ole
                                      300691    rtc
                                      300692    disp
                                      300693    sql_compilation_agent
                                      300694    tnsysprog
                                      300695    ius-sapimd
                                      300696    apteam-dx
                                      300697    rmsrpc
                                      300698    seismic_system
                                      300699    remote
                                      300700    tt1_ts_event nokia_nms
                                      300701    fxrs
                                      300702    onlicense
                                      300703    vxkey
                                      300704    dinis
                                      300705    sched2d schedule-2
                                      300706    sched3d schedule-3
                                      300707    sched4d schedule-4
                                      300708    sched5d schedule-5
                                      300709    sched6d schedule-6
                                      300710    sched7d schedule-7
                                      300711    sched8d schedule-8
                                      300712    sched9d schedule-9
                                      300713    adtsqry
                                      300714    adserv
                                      300715    adrepserv
                                      300716    [неизвестно]
                                      300717    caad
                                      300718    caaui
                                      300719    cescda
                                      300720    vcapiadmin
                                      300721    vcapi20
                                      300722    tcfs
                                      300723    csed
                                      300724    nothand
                                      300725    hacb
                                      300726    nfauth
                                      300727    imlm
                                      300728    bestcomm
                                      300729    lprpasswd
                                      300730    rprpasswd
                                      300731    proplistd
                                      300732    mikomomc
                                      300733    arepa-cas
                                      300734    [неизвестно]
                                      300735    [неизвестно]
                                      300736    ando_ts
                                      300737    intermezzo
                                      300738    ftel-sdh-request
                                      300739    ftel-sdh-response
                                      300740    [неизвестно]
                                      300741    [неизвестно]
                                      300742    [неизвестно]
                                      300743    [неизвестно]
                                      300744    [неизвестно]
                                      300745    vrc_abb
                                      300746    vrc_comau
                                      300747    vrc_fanuc
                                      300748    vrc_kuka
                                      300749    vrc_reis
                                      300750    hp_sv6d
                                      300751    correntmgr01
                                      300752    correntike
                                      300753    [неизвестно]
                                      300754    [неизвестно]
                                      300755    intransa_location
                                      300756    intransa_management
                                      300757    intransa_federation
                                      300758    portprot
                                      300759    ipmiprot
                                      300760    aceapi
                                      300761    f6000pss
                                      300762    vsmapi_program
                                      300763    ubertuple
                                      300764    ctconcrpcif
                                      300765    mfuadmin
                                      300766    aiols
                                      300767    dsmrootd
                                      300768    htdl
                                      300769    caba
                                      300770    vrc_cosimir
                                      300771    cmhelmd
                                      300772    polynsm
                                      300773    [неизвестно]
                                      300774    [неизвестно]
                                      300775    [неизвестно]
                                      300776    [неизвестно]
                                      300777    [неизвестно]
                                      300778    [неизвестно]
                                      300779    [неизвестно]
                                      300780    [неизвестно]
                                      300781    dsmrecalld
                                      300782    [неизвестно]
                                      300783    [неизвестно]
                                      300784    twrgcontrol
                                      300785    twrled
                                      300786    twrcfgdb
   BMC software                       300787-300886
   не выделены                        300887 - 300999
   Sun Microsystems                   301000-302000 [ 2000 номеров ]
   не выделены                        302001-349999
   American Airlines                  350000 - 350999
   Acucobol Inc.                      351000 - 351099
   The Bristol Group                  351100 - 351249
   Amteva Technologies                351250 - 351349
                                      351350    wfmMgmtApp
                                      351351    wfmMgmtDataSrv
                                      351352    wfmMgmtFut1
                                      351353    wfmMgmtFut1
                                      351354    wfmAPM
                                      351355    wfmIAMgr
                                      351356    wfmECMgr
                                      351357    wfmLookOut
                                      351358    wfmAgentFut1
                                      351359    wfmAgentFut2
   не выделены                        351360 - 351406
   Sterling Software ITD              351407    csed
                                      351360    sched10d
                                      351361    sched11d
                                      351362    sched12d
                                      351363    sched13d
                                      351364    sched14d
                                      351365    sched15d
                                      351366    sched16d
                                      351367    sched17d
                                      351368    sched18d
                                      351369    sched19d
                                      351370    sched20d
                                      351371    sched21d
                                      351372    sched22d
                                      351373    sched23d
                                      351374    sched24d
                                      351375    sched25d
                                      351376    sched26d
                                      351377    sched27d
                                      351378    sched28d
                                      351379    sched29d
                                      351380    sched30d
                                      351381    sched31d
                                      351382    sched32d
                                      351383    sched33d
                                      351384    sched34d
                                      351385    sched35d
                                      351386    sched36d
                                      351387    sched37d
                                      351388    sched38d
                                      351389    sched39d
                                      351390    consoleserver
                                      351391    scheduleserver
                                      351392    RDELIVER
                                      351393    REVENTPROG
                                      351394    RSENDEVENTPROG
                                      351395    snapp
                                      351396    snapad
                                      351397    sdsoodb
                                      351398    sdsmain
                                      351399    sdssrv
                                      351400    sdsclnt
                                      351401    sdsreg
                                      351402    fsbatch
                                      351403    fsmonitor
                                      351404    fsdisp
                                      351405    fssession
                                      351406    fslog
                                      351407    svdpappserv
                                      351408    gns
                                      351409    [unkonwn]
                                      351410    [unkonwn]
                                      351411    [unkonwn]
                                      351412    axi
                                      351413    rpcxfr
                                      351414    slm
                                      351415    smbpasswdd
                                      351416    tbdbserv
                                      351417    tbprojserv
                                      351418    genericserver
                                      351419    dynarc_ds
                                      351420    dnscmdr
                                      351421    ipcmdr
                                      351422    faild
                                      351423    failmon
                                      351424    faildebug
                                      351425    [неизвестно]
                                      351426    [неизвестно]
                                      351427    siemens_srs
                                      351428    bsproxy
                                      351429    ifsrpc
                                      351430    CesPvcSm
                                      351431    FrPvcSm
                                      351432    AtmPvcSm
                                      351433    radius
                                      351434    auditor
                                      351435    sft
                                      351436    voicemail
                                      351437    kis
                                      351438    SOFTSERV_NOTIFY
                                      351439    dynarpc
                                      351440    hc
                                      351441    iopas
                                      351442    iopcs
                                      351443    iopss
                                      351444    spcnfs
                                      351445    spcvss
                                      351446    matilda_sms
                                      351447    matilda_brs
                                      351448    matilda_dbs
                                      351449    matilda_sps
                                      351450    matilda_svs
                                      351451    matilda_sds
                                      351452    matilda_vvs
                                      351453    matilda_stats
                                      351454    xtrade
                                      351455    mapsvr
                                      351456    hp_graphicsd
                                      351457    berkeley_db
                                                berkeley_db_svc
                                      351458    io_server
                                      351459    rpc.niod
                                      351460    rpc.kill
                                      351461    hmdisproxy
                                      351462    smdisproxy
                                      351463    avatard
                                      351464    namu
                                      351465    BMCSess
                                      351466    FENS_Sport
                                      351467    EM_CONFIG
                                      351468    EM_CONFIG_RESP
                                      351469    lodge_proof
                                      351470    ARCserveIT-Queue
                                      351471    ARCserveIT-Device
                                      351472    ARCserveIT-Discover
                                      351473    ARCserveIT-Alert
                                      351474    ARCserveIT-Database
                                      351475    scand1
                                      351476    scand2
                                      351477    scand3
                                      351478    scand4
                                      351479    scand5
                                      351480    dscv
                                      351481    cb_svc
                                      351482    [неизвестно]
                                      351483    iprobe
                                      351484    omniconf
                                      351485    isan
   BG Partners                        351486 - 351500
                                      351501    mond
                                      351502    iqlremote
                                      351503    iqlalarm
   не выделены                        351504 - 351599
   Orion Multisystems                 351600-351855
   не выделены                        351856 - 351899
   NSP lab                            351900 - 351999
   не выделены                        351999 - 352232
                                      352233    asautostart
                                      352234    asmediad1
                                      352235    asmediad2
                                      352236    asmediad3
                                      352237    asmediad4
                                      352238    asmediad5
                                      352239    asmediad6
                                      352240    asmediad7
                                      352241    asmediad8
                                      352242    asmediad9
                                      352243    asmediad10
                                      352244    asmediad11
                                      352245    asmediad12
                                      352246    asmediad13
                                      352247    asmediad14
                                      352248    asmediad15
                                      352249    asmediad16
                                      352250    waruser
                                      352251    warlogd
                                      352252    warsvrmgr
                                      352253    warvfsysd
                                      352254    warftpd
                                      352255    warnfsd
                                      352256    bofproxyc0
                                      352257    bofproxys0
                                      352258    bofproxyc1
                                      352259    bofproxys1
                                      352260    bofproxyc2
                                      352261    bofproxys2
                                      352262    bofproxyc3
                                      352263    bofproxys3
                                      352264    bofproxyc4
                                      352265    bofproxys4
                                      352266    bofproxyc5
                                      352267    bofproxys5
                                      352268    bofproxyc6
                                      352269    bofproxys6
                                      352270    bofproxyc7
                                      352271    bofproxys7
                                      352272    bofproxyc8
                                      352273    bofproxys8
                                      352274    bofproxyc9
                                      352275    bofproxys9
                                      352276    bofproxyca
                                      352277    bofproxysa
                                      352278    bofproxycb
                                      352279    bofproxysb
                                      352280    bofproxycc
                                      352281    bofproxysc
                                      352282    bofproxycd
                                      352283    bofproxysd
                                      352284    bofproxyce
                                      352285    bofproxyse
                                      352286    bofproxycf
                                      352287    bofproxysf
                                      352288    bofproxypo0
                                      352289    bofproxypo1
                                      352290    bofproxypo2
                                      352291    bofproxypo3
                                      352292    bofproxypo4
   не выделены                        352293-370000
                                      370001    [неизвестно]
                                      370002    [неизвестно]
                                      370003    [неизвестно]
                                      370004    [неизвестно]
                                      370005    [неизвестно]
                                      370006    [неизвестно]
                                      370007    [неизвестно]
                                      370008    [неизвестно]
                                      370009    [неизвестно]
                                      370010    [неизвестно]
                                      370011    [неизвестно]
                                      370012    [неизвестно]
                                      370013    [неизвестно]
                                      370014    [неизвестно]
                                      370015    [неизвестно]
                                      370016    [неизвестно]
                                      370017    [неизвестно]
                                      370018    [неизвестно]
                                      370019    [неизвестно]
                                      370020    [неизвестно]
                                      370021    [неизвестно]
                                      370022    [неизвестно]
                                      370023    [неизвестно]
                                      370024    [неизвестно]
                                      370025    [неизвестно]
                                      370026    [неизвестно]
                                      370027    [неизвестно]
   не выделены                        370028 - 379999
                                      380000    opensna
                                      380001    probenet
                                      380002    [неизвестно]
                                      380003    license
                                      380004    na.3com-remote
                                      380005    na.ntp
                                      380006    probeutil
                                      380007    na.vlb
                                      380008    cds_mhs_agent
                                      380009    cds_x500_agent
                                      380010    cds_mailhub_agent
                                      380011    codex_6500_proxy
                                      380012    codex_6500_trapd
                                      380013    na.nm212
                                      380014    cds_mta_metrics_agent
                                      380015    [unkonwn]
                                      380016    na.caple
                                      380017    codexcapletrap
   Swiss Re                           380018-380028
                                      380029    ncstat
                                      380030    ncnfsstat
                                      380031    ftams
                                      380032    na.isotp
                                      380033    na.rfc1006
   не выделены                        380034 - 389999
   Epoch Systems                      390000 - 390049
   Quickturn Systems                  390050 - 390065
   Team One Systems                   390066 - 390075
   General Electric CRD               390076 - 390085
   TSIG NFS subcommittee              390086 - 390089
   SoftLab ab                         390090 - 390099
   Legato Network Services            390100 - 390115
                                      390116    cdsmonitor
                                      390117    cdslock
                                      390118    cdslicense
                                      390119    shm
                                      390120    rws
                                      390121    cdc
   Data General                       390122 - 390141
   Perfect Byte                       390142 - 390171
   JTS Computer Systems               390172 - 390181
   Parametric Technology              390182 - 390191
   Voxem                              390192 - 390199
   Effix Systems                      390200 - 390299
   Motorola                           390300 - 390309
   Mobile Data Intl.                  390310 - 390325
   Physikalisches Institut            390326 - 390330
   Ergon Informatik AG                390331 - 390340
   Analog Devices Inc.                390341 - 390348
   Interphase Corporation             390349 - 390358
   NeWsware                           390359 - 390374
   Qualix Group                       390375 - 390379
   Xerox Imaging Systems              390380 - 390389
   Noble Net                          390390 - 390399
   Legato Network Services            390400 - 390499
   Client Server Tech.                390500 - 390511
   Atria                              390512 - 390517
   GE NMR Instruments                 390518 - 390525
   Harris Corp.                       390526 - 390530
   Unisys                             390531 - 390562
   Aggregate Computing                390563 - 390572
   Interactive Data                   390573 - 390580
   OKG AB                             390581 - 390589
   K2 Software                        390591 - 390594
   Collier Jackson                    390595 - 390599
   Remedy Corporation                 390600 - 390699
   Mentor Graphics                    390700 - 390799
   AT&T Bell Labs (Lucent)            390800 - 390899
   Xerox                              390900 - 390999
   Silicon Graphics                   391000 - 391063
   Data General                       391064 - 391095
   Computer Support Corp.             391096 - 391099
   Quorum Software Systems            391100 - 391199
   InterLinear Technology             391200 - 391209
   Highland Software                  391210 - 391229
   Boeing Comp. Svcs.                 391230 - 391249
   IBM Sweden                         391250 - 391259
   Signature Authority Svc            391260 - 391271
   ZUMTOBEL Licht GmbH                391272 - 391283
   NOAA/ERL                           391284 - 391299
   NCR Corp.                          391300 - 391399
   FTP Software                       391400 - 391409
   Cadre Technologies                 391410 - 391433
   Visionware Ltd (UK)                391434 - 391439
   IBR-Partner AG                     391440 - 391449
   CAP Programator AB                 391450 - 391459
   Reichle+De-Massari AG              391460 - 391474
   Swiss Bank Corp (London)           391475 - 391484
   Unisys Enterprise Svr              391485 - 391489
   Intel - Test Dev. Tech.            391490 - 391499
   Ampex                              391500 - 391755
                                      391756    naas-spare
                                      391757    naas-admin
                                      391758    isps
                                      391759    isps-admin
                                      391760    mars
                                      391761    mars-admin
                                      391762    attcis_spare0
                                      391763    attcis_spare1
                                      391764    mail-server
                                      391765    mail-server-spare
                                      391766    attcis_spare2
                                      391767    attcis_spare3
                                      391768    attcis_spare4
                                      391769    attcis_spare5
                                      391770    attcis_spare6
                                      391771    attcis_spare7
   Integrated Systems, Inc.           391772 - 391779
   Parametric Tech., Inc.             391780 - 391789
   Ericsson Telecom AB                391790 - 391799
   SLAC                               391800 - 391849
                                      391850    qhrdata
                                      391851    qhrbackup
                                      391852    minutedata
                                      391853    prefecture
                                      391854    supc
                                      391855    suadmincrw
                                      391856    suadminotas
                                      391857    sumessage
                                      391858    sublock
                                      391859    sumotd
   staffware dev. (uk)                391860 - 391869
   Staffware Dev. (UK)                391870 - 391879
                                      391880    namesrvr
                                      391881    disksrvr
                                      391882    tapesrvr
                                      391883    migsrvr
                                      391884    pdmsrvr
                                      391885    pvrsrvr
                                      391886    repacksrvr
                                      391887    [неизвестно]
   Convex Computer Corp.              391888 - 391951
                                      391952    lookoutsrv
                                      391953    lookoutagnt
                                      391954    lookoutprxy
                                      391955    lookoutsnmp
                                      391956    lookoutrmon
                                      391957    lookoutfut1
                                      391958    lookoutfut2
   windward                           391959 - 391967
                                      391968    sra_legato
                                      391969    sra_legato_imgsvr
                                      391970    sra_legato_0
                                      391971    sra_legato_1
                                      391972    sra_legato_2
                                      391973    sra_legato_3
                                      391974    sra_legato_4
                                      391975    sra_legato_5
                                      391976    sra_legato_6
                                      391977    sra_legato_7
                                      391978    sra_legato_8
                                      391979    sra_legato_9
   Brooktree Corp.                    391980 - 391989
   Cadence        Design Systems      391990 - 391999
   J. Frank & Associates              392000 - 392999
   Cooperative Solutions              393000 - 393999
   Xerox Corp.                        394000 - 395023
                                      395024    odbc_sqlretriever
   3M                                 395025 - 395091
   Digital Zone Intl.                 395092 - 395099
   Software Professionals             395100 - 395159
   Del Mar Solutions                  395160 - 395164
                                      395165    ife-es
                                      395166    ife-resmgr
                                      395167    ife-aes
                                      395168    ife-bite
                                      395169    ife-loader
                                      395170    ife-satcom
                                      395171    ife-seat
                                      395172    ife-dbmgr
                                      395173    ife-testmgr
                                      395174    atrium_server
                                      395175    ase_director
                                      395176    ase_agent
                                      395177    ase_hsm
                                      395178    ase_mgr
                                      395179    ase_sim
   Hewlett-Packard                    395180 - 395194
   XES, Inc.                          395195 - 395199
   Unitech Products                   395200 - 395249
   TransSys                           395250 - 395505
   Unisys Govt Systems                395506 - 395519
   Bellcore                           395520 - 395529
   IBM                                395530 - 395561
   AT&T Network Services              395562 - 395571
   Data General                       395572 - 395577
   Swiss Bank Corp                    395578 - 395597
   Swiss Bank Corp                    395598 - 395637
   Novell                             395638 - 395643
   Computer Associates                395644 - 395650
   Omneon Video Networks              395651 - 395656
   unassigned                         395657 - 395908
   UK Post Office                     395909 - 395924
   AEROSPATIALE                       395925 - 395944
   Result d.o.o.                      395945 - 395964
   DataTools, Inc.                    395965 - 395980
   CADIS, Inc.                        395981 - 395990
   Cummings Group, Inc.               395991 - 395994
   Cadre Technologies                 395995 - 395999
   American Airlines                  396000 - 396999
   Ericsson Telecom TM Div            397000 - 398023
   IBM                                398024 - 398028
   Toshiba OME Works                  398029 - 398033
   TUSC Computer Systems              398034 - 398289
   AT&T                               398290 - 398320
   Ontario Hydro                      398321 - 398346
   Micrion Corporation                398347 - 398364
   unassigned                         398365 - 398591
   Pegasystems, Inc.                  398592 - 399616
   Spectra Securities Soft            399617 - 399850
   QualCom                            399851 - 399866
   unassigned                         399867 - 399884
   Altris Software Ltd.               399885 - 399899
   ISO/IEC WG11                       399900 - 399919
   Parametric Technology              399920 - 399949
   Dolby Laboratories                 399950 - 399981
   unassigned                         399982 - 399991
   Xerox PARC                         399992 - 399999
   #
   Next Inc.                          200100000 - 200199999
   Netwise (RPCtool)                  200200000
   Concurrent Computer Corp           200200001 - 200200007
   AIM Technology                     200300000 - 200399999
   TGV                                200400000 - 200499999
   #
   # Выделенные Sun номера для аутентификации
   #
   AUTH_NONE       0               /* без аутентификации, см. RFC 1831 */
                                   /* AUTH_NULL */
   AUTH_SYS        1               /* unix style (uid+gids), RFC 1831 */
                                   /* AUTH_UNIX */
   AUTH_SHORT      2               /* короткий стиль unix, см. RFC 1831 */
   AUTH_DH         3               /* стиль des (шифрованная метка времени) */
                                   /* AUTH_DES, см. RFC 2695 */
   AUTH_KERB       4               /* аутентификация kerberos, см. RFC 2695 */
   AUTH_RSA        5               /* аутентификация RSA */
   RPCSEC_GSS      6               /* защита RPC на основе GSS для аутентификации,
                                      целостности и приватности, RFC 5403 */

   AUTH_NW         30001           NETWARE
   AUTH_SEC        200000          TSIG NFS subcommittee
   AUTH_ESV        200004          SVr4 ES

   AUTH_NQNFS      300000          Univ. of Guelph - Not Quite NFS
   AUTH_GSSAPI     300001          OpenVision <john.linn@ov.com>
   AUTH_ILU_UGEN   300002          Xerox <janssen@parc.xerox.com>
                                    - ILU Unsecured Generic Identity
   #
   #  Небольшие блоки, выделенные из 39xxxx
   #
   AUTH_SPNEGO     390000
                   390000 - 390255 псевдо-варианты NFS для RPCSEC_GSS
                   390003 - аутентификация kerberos_v5, RFC 2623
                   390004 - kerberos_v5 с защитой целостности, RFC 2623
                   390005 - kerberos_v5 с защитой приватности, RFC 2623

                   200000000       Reserved
                   200100000       NeXT Inc.

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

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

[RFC2203] Eisler, M., Chiu, A., and L. Ling, «RPCSEC_GSS Protocol Specification», RFC 2203, September 1997.

[RFC4506] Eisler, M., Ed., «XDR: External Data Representation Standard», STD 67, RFC 4506, May 2006.

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

[DH] Diffie & Hellman, «New Directions in Cryptography», IEEE Transactions on Information Theory IT-22, November 1976.

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1094] Sun Microsystems, «NFS: Network File System Protocol specification», RFC 1094, March 1989.

[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, «NFS Version 3 Protocol Specification», RFC 1813, June 1995.

[RFC1831] Srinivasan, R., «RPC: Remote Procedure Call Protocol Specification Version 2», RFC 1831, August 1995.

[RFC1833] Srinivasan, R., «Binding Protocols for ONC RPC Version 2», RFC 1833, August 1995.

[RFC2623] Eisler, M., «NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5», RFC 2623, June 1999.

[RFC2695] Chiu, A., «Authentication Mechanisms for ONC RPC», RFC 2695, September 1999.

[RFC2743] Linn, J., «Generic Security Service Application Program Interface Version 2, Update 1», RFC 2743, January 2000.

[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, «Network File System (NFS) version 4 Protocol», RFC 3530, April 2003.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[VMTP] Cheriton, D., «VMTP: Versatile Message Transaction Protocol», Preliminary Version 0.3, Stanford University, January 1987.

[XRPC] Birrell, A. D. & B. J. Nelson, «Implementing Remote Procedure Calls», XEROX CSL-83-7, October 1983.

Адрес автора

Robert Thurlow

Sun Microsystems, Inc.

500 Eldorado Boulevard, UBRM05-171

Broomfield, CO 80021

Phone: 877-718-3419

EMail: robert.thurlow@sun.com

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

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

nmalykh@protokols.ru

1Generic Security Services Application Programming Interface — базовый интерфейс прикладных программ служб защиты.

Рубрика: RFC | Оставить комментарий

RFC 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

Опубликовано 30.04.2009 автором Nikolai Malykh

Network Working Group                                           J. Arkko
Request for Comments: 5494                                      Ericsson
Updates: 826, 951, 1044, 1329, 2131,                        C. Pignataro
         2132, 2176, 2225, 2834, 2835,                     Cisco Systems
         3315, 4338, 4361, 4701                               April 2009
Category: Standards Track

Рекомендации IANA по выделению значений ARP

IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

PDF

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

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

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

Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Аннотация

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

1. Введение

Этот документ задает рекомендации IANA [RFC5226] по выделению новых значений для различных полей в протоколе преобразования адресов ARP [RFC0826]. Изменения применимы к расширениям ARP, использующим такой же формат сообщений как [RFC0903], [RFC1931] и [RFC2390].

Изменения также оказывают влияние на другие протоколы, которые используют значения из пространства имен ARP. Например пространство типов аппаратного адреса ARP (ar$hrd) используется в полях htype (тип аппаратного адреса) протоколов BOOTP² [RFC0951] и DHCP³ [RFC2131], а также в поле hardware type в DHCP Unique Identifiers протокола DHCPv6 [RFC3315]. Поэтому обновление правил IANA оказывает влияние на эти протоколы. Другие спецификации, на которые влияют новые правила, включают механизмы преобразования адресов в:

HYPERchannel [RFC1044];
опциях DHCP [RFC2132] [RFC4361];
ATM⁴ ARP [RFC2225]
HARP⁵ [RFC2834] [RFC2835]
Dual MAC⁶ FDDI⁷ ARP [RFC1329]
MAPOS⁸ ARP [RFC2176]
FC⁹ ARP [RFC4338]
DNS DHCID Resource Record [RFC4701]

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

Документ также резервирует некоторые значения для экспериментов. Эти значения описаны в разделе 3.

2. Взаимодействие с IANA

Ниже приведены правила, применяющиеся для полей ARP.

ar$hrd (16 битов) – пространство аппаратных адресов

Запросы для значений ar$hrd меньше 256, а также запросы на выделение более одного значения обрабатываются по процедуре Expert Review [RFC5226].

Отметим, что некоторые протоколы типа BOOTP и DHCPv4 используют эти значения в 8-битовых полях. Экспертам следует убедиться в необходимости выделения новых значений, а также в том, что имеющихся значений не достаточно для представления новых типов аппаратных адресов. Экспертам также следует определить применимость запроса и выделять значения больше 255 для запросов, которые не применимы к BOOTP/DHCPv4. Экспертам следует выделять 1-октетные значения для запросов, применимых к BOOTP/DHCPv4, например, IPsec tunnel со значением [RFC3456]. И наоборот, значения, предназначенные только для ARP, без каких-либо причин использовать их для BOOTP/DHCPv4, следует выделять из числа 2-октетных.

Запросы на выделение отдельных новых ar$hrd без указания конкретного значения или с указанием значения больше 255 обрабатываются про процедуре First Come First Served [RFC5226]. В результате всегда выделяется 2-октетное значение.

ar$pro (16 битов) – пространство протокольных адресов

Эти значения используют пространство Ethertype, администрирование которого описано в [RFC5342].

ar$op (16 битов) – коды операций

Запросы на выделение новых значений ar$op обрабатываются про процедуре IETF Review или IESG Approval [RFC5226].

3. Значения, выделенные в этом документе

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

Для экспериментов выделены два новых значения ar$hrd — HW_EXP1 (36) и HW_EXP2 (256). Отметим, что для экспериментов осознанно было выбрано одно значение меньше 256, а другое больше 255, чтобы они различались как в старшем, так и в младшем октете.
Для экспериментов выделены два новых значения ar$op — OP_EXP1 (24) и OP_EXP2 (25).

Отметим, что в Приложении B.2 к [RFC5342] указаны два значения Ethertype, которые могут использоваться в экспериментах.

Кроме того, для ar$hrd и ar$op значения 0 и 65535 были помечены как резервные. Это означает их недоступность для выделения.

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

Эта спецификация не меняет параметров безопасности затрагиваемых документом протоколов.

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

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

Отсутствие каких-либо действующих правил было обнаружено при запросе новых значений у агентства IANA, которое обратилось за консультацией в IESG. Автор признателен Michelle Cotton за поднятие этой проблемы. Спасибо также Brian Carpenter, Thomas Narten, Scott Bradner, Donald Eastlake, Andrew G. Malis, Brian Haberman, Robert Sparks, Larry Zhu и Dave Thaler за их отклики.

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

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

[RFC0826] Plummer, D., «Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware», STD 37, RFC 826, November 1982.

[RFC0951] Croft, B. and J. Gilmore, «Bootstrap Protocol», RFC 951, September 1985.

[RFC1044] Hardwick, K. and J. Lekashman, «Internet Protocol on Network System’s HYPERchannel: Protocol specification», STD 45, RFC 1044, February 1988.

[RFC1329] Kuehn, P., «Thoughts on Address Resolution for Dual MAC FDDI Networks», RFC 1329, May 1992.

[RFC2131] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[RFC2176] Murakami, K. and M. Maruyama, «IPv4 over MAPOS Version 1», RFC 2176, June 1997.

[RFC2225] Laubach, M. and J. Halpern, «Classical IP and ARP over ATM», RFC 2225, April 1998.

[RFC2834] Pittet, J., «ARP and IP Broadcast over HIPPI-800», RFC 2834, May 2000.

[RFC2835] Pittet, J., «IP and ARP over HIPPI-6400 (GSN)», RFC 2835, May 2000.

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3315, July 2003.

[RFC3692] Narten, T., «Assigning Experimental and Testing Numbers Considered Useful», BCP 82, RFC 3692, January 2004.

[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, «Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel», RFC 4338, January 2006.

[RFC4361] Lemon, T. and B. Sommerfeld, «Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)», RFC 4361, February 2006.

[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, «A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)», RFC 4701, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5342] Eastlake. , D., «IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters», BCP 141, RFC 5342, September 2008.

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

[RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, «Reverse Address Resolution Protocol», STD 38, RFC 903, June 1984.

[RFC1931] Brownell, D., «Dynamic RARP Extensions for Automatic Network Address Acquisition», RFC 1931, April 1996.

[RFC2390] Bradley, T., Brown, C., and A. Malis, «Inverse Address Resolution Protocol», RFC 2390, September 1998.

[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, «Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode», RFC 3456, January 2003.

Приложение A. Отличия от исходных RFC

Этот документ задает лишь правила IANA, связанные с различными полями ARP. Эти правила также воздействуют на выделение соответствующих полей в протоколах, перечисленных в разделе 1, которые используют реестр. Этот документ не вносит каких-либо изменений в работу самих протоколов.

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

Jari Arkko

Ericsson

Jorvas 02420

Finland

EMail: jari.arkko@piuha.net

Carlos Pignataro

Cisco Systems

7200-12 Kit Creek Road

Research Triangle Park, NC 27709

USA

EMail: cpignata@cisco.com

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

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

nmalykh@protokols.ru

1Address Resolution Protocol — протокол преобразования адресов.

2Bootstrap Protocol — протокол загрузки.

3Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации хоста.

4Asynchronous Transfer Mode — асинхронный режим передачи.

5High-Performance Parallel Interface ARP — ARP параллельного высокопроизводительного интерфейса.

6Media Access Control — контроль доступа к среде.

7Fiber Distributed Data Interface — оптический распределенный интерфейс передачи данных.

8Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy — протокол множественного доступа в иерархии Sonet/SDH.

9Fibre Channel — оптический канал.

Рубрика: RFC | Комментарии отключены