RFC 2113 IP Router Alert Option

Network Working Group                                        D. Katz
Request for Comments: 2113                             cisco Systems
Category: Standards Track                              February 1997

Опция IP Router Alert

IP Router Alert Option

PDF

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

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

Тезисы

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

1.0 Введение

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

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

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

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

RSVP [1] решает эту проблему, указывая адрес конечного получателя в поле IP Destination Address и запрашивая у каждого маршрутизатора RSVP на пути доставки «внести незначительные изменения в … путь его пересылки», чтобы был определен конкретный тип пакета RSVP и все такие пакеты пересылались бы по отличному от основного пути с их локальной обработкой до дальнейшей пересылки. Это обеспечивает явное преимущество за счет обеспечения возможности туннелирования через маршрутизаторы, не понимающие RSVP, поскольку пакеты пойдут естественным путем в направлении конечного получателя. Однако потеря производительности, связанная с внесением изменений в путь пересылки может оказаться недопустимой, поскольку основной путь пересылки может быть очень точно «настроен» и даже добавление одной команды может снизить производительность на сотни пакетов в секунду.

2.0 Опция Router Alert

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

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

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

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

2.1 Синтаксис

Формат (TLV) опции Router Alert показан на рисунке.

                 +--------+--------+--------+--------+
                 |10010100|00000100|     2 октета    |
                 +--------+--------+--------+--------+

 

Type

Флаг копирования: 1 (опция должна включаться во все фрагменты).

Класс опции: 0 (управление)

Номер опции: 20 (десятичное значение)

Length=4

Value

Двухоктетный код, который может принимать значения:

0 — маршрутизатору следует проверить пакет;

1-65535 — резерв.

2.2 Семантика

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

Семантика других значения поля Value требует дополнительного изучения.

3.0 Влияние на другие протоколы

Для обеспечения эффективности этой опции ее использование должно стать обязательным в протоколах, которые ожидают от промежуточных маршрутизаторов существенной обработки пакетов, не адресованных данному маршрутизатору. В настоящее время к таким протоколам относятся RSVP [1] и IGMP [2].

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

Если опция Router Alert не установлена там, где ей следует быть, поведение протоколов, использующих оповещение маршрутизаторов (таких, как RSVP и IGMPv2), может быть изменено, поскольку работа таких протоколов основана на использовании опции Router Alert.

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

5.0 Литература

[1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, «Resource ReSerVation Protocol (RSVP),» work in progress1, March 1996.

[2] Fenner, W., «Internet Group Management Protocol, Version 2 (IGMPv2),» work in progress2, October 1996.

Адрес автора

Dave Katz

cisco Systems

170 W. Tasman Dr.

San Jose, CA 95134-1706 USA

Phone: +1 408 526 8284

Email: dkatz@cisco.com


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

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

nmalykh@gmail.com

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

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




RFC 2105 Cisco Systems’ Tag Switching Architecture Overview

Network Working Group                                         Y. Rekhter
Request for Comments: 2105                                      B. Davie
Category: Informational                                          D. Katz
                                                                E. Rosen
                                                              G. Swallow
                                                     Cisco Systems, Inc.
                                                           February 1997

 

Обзор архитектуры коммутации по тегам Cisco Systems

Cisco Systems’ Tag Switching Architecture Overview

PDF

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

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

Примечание IESG

Протокол не является результатом работы какой-либо группы IETF или проектом стандарта. Широкое распространение документа и его внимательный обзор со стороны сообщества не обязательно обеспечат какие-либо преимущества.

Тезисы

Этот документ включает обзор новой модели пересылки пакетов на сетевом уровне, названной коммутацией по тегам (tag switching). Описаны две основные компоненты архитектуры коммутации по тегам — пересылка и управление. Пересылка осуществляется с помощью простых механизмов замены меток, а для управления применяются существующие протоколы маршрутизации сетевого уровня вкупе с механизмами привязки и распространения тегов. При коммутации по тегам могут сохраниться и даже улучшиться свойства масштабирования сетей IP. Хотя коммутация тегов не основана на технологии ATM, она может быть применена и в коммутаторах ATM. Рассматривается область применения и сценарии развертывания систем коммутации по тегам.

Оглавление

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

1. Введение

Непрерывное расширение сети Internet требует от сервис-провайдеров (ISP1) повышения пропускной способности их сетей. Однако расширение Internet не является единственным фактором увеличения пропускной способности — расширяющееся использование multimedia-приложений также требует высокой пропускной способности. Запросы пропускной способности, в свою очередь, требуют повышения производительности маршрутизаторов (число пересылаемых пакетов в секунду) как для группового, так и для индивидуального трафика.

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

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

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

Остальная часть этого документа организована следующим образом — в разделе 2 описаны основные компоненты коммутации по тегам, в разделе 3 описана пересылка, в разделе 4 — управление, раздел 5 описывает использование коммутации по меткам с ATM, раздел 6 посвящен использованию коммутации по тегам для расширения диапазона качества обслуживания, в разделе 7 кратко описаны сценарии развертывания, f раздел 8 содержит резюме.

2. Компоненты коммутации по тегам

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

3. Компонента пересылки

Парадигма пересылки в коммутаторах по тегам основана на замене меток. При получении пакета с тегом коммутатором по тегам этот коммутатор использует тег в качестве индекса для поиска в своей базе TIB2. Каждая запись TIB включает входящий тег и один или множество элементов вида (outgoing tag, outgoing interface, outgoing link level information3). Если коммутатор находит в базе запись, соответствующую входящему тегу в пакете, для каждого элемента (outgoing tag, outgoing interface, outgoing link level information) в этой записи он меняет тег в полученном пакете на исходящий тег, меняет в пакете информацию канального уровня (например, MAC-адрес) данными из элемента и пересылает пакет через указанный в элементе выходной интерфейс.

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

Во-вторых, решение о пересылке не зависит от «гранулярности» тегов. Например, один и тот же алгоритм пересылки может применяться для пакетов с индивидуальными и групповыми адресами — для индивидуального адреса в записи будет содержаться один элемент (outgoing tag, outgoing interface, outgoing link level information), а для группового таких элементов может оказаться множество (для каналов с множественным доступом в таких случаях информация канального уровня будет включать групповой MAC-адрес). Это показывает, как одна парадигма пересылки при коммутации по тегам может применяться для поддержки разных функций маршрутизации (например, индивидуальная, групповая и т. п.).

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

3.1. Инкапсуляция тегов

Теги могут передаваться в пакетах несколькими способами:

  • как небольшая вставка4 между заголовками канального и сетевого уровней;

  • как часть заголовка канального уровня, если тот поддерживает подходящую семантику (например, ATM, как описано ниже);

  • как часть заголовка сетевого уровня (например, с использованием поля Flow Label в заголовке IPv6 при изменении семантики).

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

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

4. Управляющая компонента

Существенным для коммутации по тегам является понятие связки тега с маршрутизацией на сетевом уровне (маршрутом). Для обеспечения хорошей масштабируемости при расширении функциональности маршрутизации коммутация по тегам поддерживает широкий диапазон «гранулярности» пересылки. Одним из крайних случаев является привязка тега к группе маршрутов (более конкретно, к значению NLRI5 маршрутов данной группы). Другой крайностью является привязка тега к отдельному потоку трафика приложений (например, потоку RSVP). Тег можно также связать с деревом групповой пересылки (multicast tree).

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

4.1. Маршрутизация по адресатам

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

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

Существует три признанных метода выделения тегов и управления базами TIB7 — (a) выделение тегов в нисходящем направлении, (b) выделение тегов в нисходящем направлении по запросам и (c) выделение тегов в восходящем направлении. Во всех случаях коммутатор выделяет теги и связывает их с адресными префиксами в своей FIB. При нисходящем выделении передаваемый в пакете тег генерируется и привязывается к префиксу коммутатором на нисходящей стороне соединения (относительно направления потока данных). При восходящем выделении теги выделяются и привязываются на восходящей стороне соединения. Выделение по запросу означает, что теги будут выделяться и распространяться нисходящим коммутатором только при их запросе со стороны восходящего коммутатора. Методы (b) и (c) наиболее полезны для сетей ATM (см. раздел 5). Отметим, что при нисходящем выделении коммутатор отвечает за создание привязок тегов, которые применяются для входящих пакетов данных и получает привязки тегов для исходящих пакетов от своих соседей. При восходящем выделении коммутатор отвечает за привязку для исходящих тегов, которые применяются для пакетов данных, уходящих с коммутатора, а привязки входящих тегов получает от своих соседей.

Схема нисходящего выделения тегов работает следующим образом — для каждого маршрута в своей FIB коммутатор выделяет тег, создает запись в своей TIB с выделенным значением в качестве входящего тега и после этого анонсирует привязку (входящего) тега к маршруту смежным коммутаторам с коммутацией по тегам. Анонсирование может осуществляться добавлением (piggybacking) привязки к данным используемых протоколов маршрутизации или за счет использования отдельного протокола распространения тегов [TDP8]. Когда коммутатор получает информацию о привязке тега к маршруту, исходящую от следующего интервала (коммутатора) на этом маршруте, он помещает тег (переданный, как часть данных о привязке) в поле исходящего тега своей записи TIB для соответствующего маршрута. Это создает привязку исходящего тега к маршруту.

При нисходящем выделении меток по запросам для каждого маршрута в своей FIB коммутатор идентифицирует следующий интервал (next hop). После этого он (с помощью TDP) запрашивает у соответствующего коммутатора привязку для этого маршрута. Когда коммутатор следующего интервала получает такой запрос, он выделяет тег, создает запись в своей базе TIB для входящего тега, поместив в нее выделенное значение, и возвращает привязку (входящего) тега к маршруту передавшему запрос коммутатору. При получении привязки коммутатор создает в своей TIB запись и устанавливает в ней для исходящего тега полученное от коммутатора следующего интервала значение.

Схема восходящего выделения тегов работает следующим образом — если коммутатор по тегам имеет один или множество интерфейсов «точка-точка», тогда для каждого маршрута в своей FIB, следующий интервал которого доступен через один из таких интерфейсов, коммутатор выделяет тег, создает запись в своей TIB с выделенным значением в качестве исходящего тега и анонсирует на следующий интервал (с помощью TDP) привязку (исходящего) тега к маршруту. Когда коммутатор по тегам следующего интервала получает эту привязку, он помещает тег (передается как часть информации о привязке) в поле входящего тега записи своей TIB для соответствующего маршрута.

После заполнения TIB входящими и исходящими тегами коммутатор может пересылать пакеты для маршрутов, привязанных к тегам, используя алгоритм пересылки коммутации по тегам (как описано в разделе 3).

Когда коммутатор создает привязку исходящего тега к маршруту, он, в дополнение к включению записи в свою TIB, обновляет свою базу FIB, включая в нее данные о привязке. Это позволяет коммутатору добавлять теги в пакеты, которые их не имели ранее.

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

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

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

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

4.2. Иерархия маршрутной информации

В архитектуре маршрутизации IP сеть представляется в виде набора доменов маршрутизации. Внутри таких доменов маршрутизация обеспечивается протоколами внутренней маршрутизации (например, OSPF), а между доменами — протоколами внешней маршрутизации (например, BGP). Однако все маршрутизаторы в домене (например, в сети Internet-провайдера), используемые для передачи транзитного трафика поддерживают информацию не только от внутреннего протокола, но и от внешних. Это создает некоторые сложности. Во-первых, объем маршрутной информации достаточно велик, что создает дополнительные требования к ресурсам маршрутизаторов. Кроме того, рост объема маршрутной информации зачастую увеличивает время схождения при расчете маршрутов. А это, в свою очередь, снижает общую производительность системы.

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

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

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

Управляющая компонента для этого сценария очень похожа на используемую при маршрутизации по адресам получателей. Фактически, единственным существенным различием является то, что в этом сценарии информация о привязках тегов распространяется как между физически смежными коммутаторами по тегам, так и между граничными коммутаторами по тегам в одном домене. Можно также отметить, что последнее (распространение между граничными коммутаторами) можно тривиально приспособить с помощью простого расширения к протоколу BGP (отдельный атрибут BGP Tag Binding).

4.3. Групповая адресация

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

Для поддержки функций групповой пересылки с коммутацией по тегам каждый коммутатор связывает тег с деревом групповой адресации, как описано ниже. Когда коммутатор по тегам создает запись для групповой пересылки (для общего или связанного с источником дерева) и список выходных интерфейсов для нее, а также локальные теги (по одному на выходной интерфейс). Коммутатор создает запись в своей базе TIB и заполняет ее поля (outgoing tag, outgoing interface, outgoing MAC header) информацией для каждого выходного интерфейса, помещая сгенерированные локально теги в поля outgoing tag. Это организует привязку тегов к дереву групповой адресации. После этого коммутатор анонсирует через каждый из связанных с записью выходных интерфейсов привязку связанного с этим интерфейсом тега к дереву групповой пересылки.

Когда коммутатор по тегам получает привязку тега к multicast-дереву от другого коммутатора, который является его соседом в восходящем направлении (относительно дерева групповой пересылки), этот коммутатор помещает тег из полученной привязки в поле incoming tag записи TIB, связанной с деревом.

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

4.4. Гибкая маршрутизация (явные маршруты)

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

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

5. Коммутация по тегам в ATM

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

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

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

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

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

Реализация коммутации по тегам в коммутаторах ATM будет упрощать интеграцию коммутаторов ATM и маршрутизаторов — коммутатор ATM с поддержкой коммутации по тегам для соседнего маршрутизатора будет выглядеть обычным маршрутизатором. Это может обеспечить жизнеспособную и более масштабируемую альтернативу модели с перекрытием (overlay model). Это также избавляет от необходимости использования схем адресации, маршрутизации и сигнализации ATM. Поскольку маршрутизация по адресам получателей, описанная в параграфе 4.1, управляется топологией, а не трафиком, применение этой модели для коммутаторов ATM не потребует высокой скорости организации соединений и не будет зависеть от продолжительности потоков трафика.

Реализация коммутации по тегам в коммутаторах ATM не препятствует поддержке традиционного уровня управления ATM (например, PNNI) в том же коммутаторе. Компоненты коммутации по тегам и управления ATM могут работать в режиме Ships In the Night10 (с пространствами VPI/VCI и другими ресурсами поделенными так, что эти компоненты не будут взаимодействовать).

6. Качество обслуживания

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

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

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

7. Стратегии перехода к коммутации по тегам

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

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

8. Заключение

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

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

Вопросы безопасности не рассматриваются в этом документе.

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

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

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

Значительный вклад в эту работу внесли Anthony Alles, Fred Baker, Paul Doolan, Dino Farinacci, Guy Fedorkow, Jeremy Lawrence, Arthur Lin, Morgan Littlewood, Keith McCloghrie и Dan Tappan.

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

Yakov Rekhter

Cisco Systems, Inc.

170 Tasman Drive

San Jose, CA, 95134

EMail: yakov@cisco.com

Bruce Davie

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: bsd@cisco.com

Dave Katz

Cisco Systems, Inc.

170 Tasman Drive

San Jose, CA, 95134

EMail: dkatz@cisco.com

Eric Rosen

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: erosen@cisco.com

George Swallow

Cisco Systems, Inc.

250 Apollo Drive

Chelmsford, MA, 01824

EMail: swallow@cisco.com

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

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

nmalykh@gmail.com

1Internet Service Provider.

2Tag Information Base — база информации о тегах.

3Исходящий тег, выходной интерфейс, данные канального уровня на стороне выхода.

4В оригинале shim — прокладка. Прим. перев.

5Network Layer Reachability Information — информация о доступности на сетевом уровне.

6Forwarding Information Base — база данных о пересылке.

7Tag Information Base — база информации о тегах.

8Tag Distribution Protocol.

9Internet Service Provider — поставщик услуг Internet.

10Корабли в ночи.




RFC 2104 HMAC: Keyed-Hashing for Message Authentication

Network Working Group                                       H. Krawczyk
Request for Comments: 2104                                          IBM
Category: Informational                                      M. Bellare
                                                                   UCSD
                                                             R. Canetti
                                                                    IBM
                                                          February 1997

 

Проверка подлинности сообщений HMAC

HMAC: Keyed-Hashing for Message Authentication

PDF

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

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

Тезисы

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

1. Введение

Обеспечение способа проверки целостности информации, передаваемой или сохраняемой в ненадежной среде, является настоятельной необходимостью в мире открытых вычислений и коммуникаций. Механизмы, обеспечивающие проверку целостности на базе секретного ключа обычно называют кодами MAC1. Обычно такие коды применяются между двумя сторонами, знающими общий секретный ключ для валиадации данных, передаваемых между этими сторонами. В этом документе представлен такой механизм MAC, основанный на криптографических хэш-функциях. Этот механизм, названный HMAC, основан на работе [BCK1], в которой представлена конструкция и выполнен криптографический анализ. Эта работа упомянута по причине наличия в ней подробного обоснования и анализа защищенности HMAC, а также сравнение с другими методами хэширования на основе ключей.

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

  • применение без изменения механизма разных доступных хэш-функций (в частности, хэш-функции с открытым кодом и широким распространением);

  • сохранение производительности исходной хэш-функции без существенного снижения;

  • простота использования и обслуживания ключей;

  • понятный криптоанализ стойкости механизма аутентификации на основе разумных предположений об используемой хэш-функции;

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

Этот документ служит спецификацией механизма HMAC использующего обычную криптографическую хэш-функцию (H). Для конкретной реализации HMAC нужно выбрать определенную функцию хэширования. Современные претенденты на эту роль включают SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD]. Такие реализации HMAC будут обозначаться HMAC-SHA1, HMAC-MD5, HMAC-RIPEMD и т. п.

Примечание. На момент подготовки этого документа MD5 и SHA-1 были наиболее распространенными криптографическими хэш-функциями. Недавно была продемонстрирована уязвимость MD5 к атакам с поиском коллизий [Dobb]. Эта атака и другие известные уязвимости MD5 не отменяют применения MD5 для HMAC, указанного в этом документе (см. [Dobb]), однако функция SHA-1 представляется более криптостойкой. На данный момент MD5 может рассматриваться для использования в HMAC для приложений, где важна непревзойденная производительность MD5. В любом случае разработчикам и пользователям следует принимать во внимание возможности криптоаналитических разработок, касающихся применяемых хэш-функций и связанного с этим риска необходимости замены используемой функции (см. обсуждение вопросов безопасности в разделе 6).

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

Определение HMAC требует криптографической хэш функции, которую мы обозначим H, и секретный ключ K. Предполагается, что криптографическая функция H хэширует данные путем итеративного применения базовой функции сжатия к блокам данных. Обозначим размер такого блока в байта буквой B (B=для всех упомянутых выше примеров хэш-функций), а L — выходной размер хэш функции в байтах (L=16 для MD5, L=20 для SHA-1). Ключ аутентификации K может иметь любой размер вплоть до размера блока хэш-функции (B). Приложения, использующие ключи размером больше B, будут сначала хэшировать такой ключ с помощью H, а затем использовать результат размера L в формате строки байтов, как реальный ключ для HMAC. Во всех случаях рекомендуется использовать ключи K размером не менее L байтов (выходной размер хэш-функции). Дополнительные сведения о ключах приведены в разделе 3.

Мы определяем две фиксированных строки ipad и opad (i — вход, o — выход) следующим образом:

ipad = повторенный B раз байт 0x36

opad = повторенный B раз байт 0x5C

Для расчета значения HMAC для строки text выполняется операция

H(K XOR opad, H(K XOR ipad, text))

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

  1. в конце K добавляются нули до создания строки размером B байтов (например, если K имеет размер 20 байтов, а B=64, в конце строки K добавляется 44 байта со значением 0x00);

  2. выполняется операция XOR (побитовое «исключающее-ИЛИ) для строки размера B, полученной на этапе (1), и ipad;

  3. к полученной на этапе (2) строке размера B в конце добавляется поток входной информации text;

  4. к полученному на этапе (3) результату применяется функция H;

  5. выполняется операция XOR (побитовое «исключающее-ИЛИ) для строки размера B, полученной на этапе (1), и opad;

  6. результат H, полученные на этапе (4) добавляется в конец строки размера B, полученной на этапе (5);

  7. к полученному на этапе (6) результату применяется функция H.

Для иллюстрации этого процесса в Приложении дан пример кода, использующего хэш-функцию MD5.

3. Ключи

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

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

4. Примечание для разработчиков

Механизм HMAC определен таким образом, что не требуется вносить изменений в код используемой хэш-функции H. В частности, используется функция H с предопределенным начальным вектором инициализации IV (фиксированное значение, задаваемое каждой итеративной хэш-функцией для инициализации ее функции сжатия). Однако при необходимости можно увеличить эффективность механизма путем (возможного) изменения кода H с целью поддержки изменяемых значений IV.

Идея состоит в том, что промежуточные результаты функции сжатия B-байтовых блоков (K XOR ipad) и (K XOR opad) можно заранее рассчитать только один раз в момент генерации ключа K или до первого его использования. Эти промежуточные результаты сохраняются и позднее используются для инициализации IV функции H каждый раз, когда требуется аутентификация сообщения. Этот метод позволяет при аутентификации каждого сообщения опустить применение функции сжатия из состава H к двум B-байтовым блокам (т. е., K XOR ipad и K XOR opad). Такая экономия может оказаться существенной при аутентификации небольших объемов данных. Подчеркнем, что промежуточные значения требуют такого же отношения и защиты, как секретные ключи.

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

5. Отсечка вывода

Общепринятой практикой применения кодов аутентификации сообщений является отсечка вывода MAC с использованием лишь части битов (например, [MM, ANSI]). Preneel и van Oorschot [Pv] показали некоторые аналитические преимущества отсечки выхода основанных на хэшировании функций MAC. Результаты в этом смысле не являются абсолютными в плане общего повышение уровня защиты в результате отсечки. Имеются как позитивные (снижение объема информации, доступной для атакующего), так и негативные (атакующему нужно угадать меньше битов) эффекты. Приложения HMAC могут выбрать отсечку результата HMAC путем вывода лишь t старших (левых) битов HMAC (расчет выполняется обычным путем, как описано в разделе 2, а кнонечный результат отсекается до размера t битов). Рекомендуется делать размер вывода t не меньше половины выходного размера хэш-функции (атаки birthday2) и не меньше 80 битов (приемлемая нижняя граница числа битов, которые потребуется угадать злоумышленнику). Предлагается обозначать реализации HMAC с хэш-функцией H и отсечкой вывода t, как HMAC-H-t. Например, HMAC-SHA1-80 будет указывать реализацию HMAC с использованием хэш-функции SHA-1 и отсечкой вывода до 80 битов (если параметр t не указан — например, HMAC-MD5 — предполагается вывод без отсечки).

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

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

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

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

  1. Конструкция механизм не зависит от деталей конкретной хэш-функции H и эту функцию можно заменить любой другой защищенной (итеративной) криптографической хэш-функцией.

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

Наиболее сильная атака на HMAC основана на частоте коллизий для хэш-функции H (birthday attack) [PV,BCK2] и практически не реализуема для сколь-нибудь серьезных хэш-функций.

Например, для хэш-функции типа MD5 с выходным размером L=16 байтов (128 битов) атакующему потребуется собрать корректные теги аутентификации сообщений (с тем же секретным ключом K) примерно для 264 известных нешифрованных текстов. Это потребует обработки не менее 264 с помощью H, что на практике не представляется реальным (при размере блока 64 байта это потребует 250 000 лет непрерывных передачи по каналу производительностью 1 Гбит/с без смены ключа K в течение всего времени). Такая атака станет реальной только при обнаружении серьезных проблем с коллизиями функции H (например, обнаруженной после 230 сообщений). Такое событие потребует незамедлительной замены функции H (гораздо сильнее это воздействовало бы на традиционные применения функции H в контексте цифровых подписей, сертификатов открытых ключей и т. п.).

Примечание. Описанная атака сильно отличается от обычных атак с поиском коллизий на криптографические функции без секретного ключа, где можно использовать 264 параллельных (!) операций для поиска коллизий. Эта атака уже представляется возможной на практике [VW], тогда как birthday-атаки на HMAC совершенно не реальны на практике (в приведенном выше примере использование функции с выходом 160 битов потребует уже 280 блоков вместо 264).

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

Приложение — пример кода

Для наглядности ниже представлен образец кода, реализующего HMAC-MD5 и некоторые тестовые векторы (пример основан на коде MD5, описанном в [MD5]).

/*
** Функция - hmac_md5
*/

void
hmac_md5(text, text_len, key, key_len, digest)
unsigned char*  text;                /* указатель на поток данных */
int             text_len;            /* размер потока данных */
unsigned char*  key;                 /* указатель на ключ аутентификации */
int             key_len;             /* размер ключа аутентификации */
caddr_t         digest;              /* дайджест для заполнения (результат функции) */

{
        MD5_CTX context;
        unsigned char k_ipad[65];    /* внутреннее заполнение -  key XOR ipad */
        unsigned char k_opad[65];    /* внешнее заполнение -  key XOR opad */
        unsigned char tk[16];
        int i;
        /* сброс ключа размером более 64 байтов в key=MD5(key) */
        if (key_len > 64) {
                MD5_CTX      tctx;

                MD5Init(&tctx);
                MD5Update(&tctx, key, key_len);
                MD5Final(tk, &tctx);

                key = tk;
                key_len = 16;
        }

        /* преобразование HMAC_MD5 имеет вид:
         *
         * MD5(K XOR opad, MD5(K XOR ipad, text))
         *
         * где K — ключ размером n байтов
         * ipad — байт 0x36, повторенный 64 раза
         * opad — байт 0x5c, повторенный 64 раза
         * text — защищаемые данные
         */

        /* начинаем с сохранения ключа в заполнении */
        bzero( k_ipad, sizeof k_ipad);
        bzero( k_opad, sizeof k_opad);
        bcopy( key, k_ipad, key_len);
        bcopy( key, k_opad, key_len);

        /* выполняем операцию XOR для значений ipad и opad */
        for (i=0; i<64; i++) {
                k_ipad[i] ^= 0x36;
                k_opad[i] ^= 0x5c;
        }
        /* расчет внутреннего значения MD5 */
        MD5Init(&context);                   /* инициализация содержимого для 1-го прохода */
        MD5Update(&context, k_ipad, 64)      /* начало внутреннего заполнения */
        MD5Update(&context, text, text_len); /* текст дейтаграммы */
        MD5Final(digest, &context);          /* завершение  1-го прохода */
        /* расчет внешнего значения MD5 */
        MD5Init(&context);                   /* инициализация содержимого для 2-го прохода */
        MD5Update(&context, k_opad, 64);     /* начало внешнего заполнения */
        MD5Update(&context, digest, 16);     /* используем результат 1-го хэширования */
        MD5Final(digest, &context);          /* завершение  2-го прохода */
}

 

Тестовые векторы (\0 в конце символьной строки не указан).

  key =         0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
  key_len =     16 байтов
  data =        "Hi There"
  data_len =    8  байтов
  digest =      0x9294727a3638bb1c13f48ef8158bfc9d

  key =         "Jefe"
  data =        "what do ya want for nothing?"
  data_len =    28 байтов
  digest =      0x750c783e6ab0b503eaa86e310a5db738

  key =         0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  key_len       16 байтов
  data =        0xDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
                DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
  data_len =    50 байтов
  digest =      0x56be34521d144c88dbb8c733f0e8b3f6

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

Pau-Chen Cheng, Jeff Kraemer и Michael Oehler представили полезные комментарии к предварительным вариантам документа и выполнили первые проверки интероперабельности для этой спецификации. Jeff и Pau-Chen любезно предоставили образец кода и тестовые векторы, приведенные в Приложении. Burt Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir и Paul van Oorschot представили полезные комментарии и предложения в процессе обсуждения конструкции HMAC.

Литература

[ANSI] ANSI X9.9, «American National Standard for Financial Institution Message Authentication (Wholesale),» American Bankers Association, 1981. Revised 1986.

[Atk] Atkinson, R., «IP Authentication Header», RFC 1826, August 1995.

[BCK1] M. Bellare, R. Canetti, and H. Krawczyk, «Keyed Hash Functions and Message Authentication», Proceedings of Crypto’96, LNCS 1109, pp. 1-15. (http://www.research.ibm.com/security/keyed-md5.html)

[BCK2] M. Bellare, R. Canetti, and H. Krawczyk, «Pseudorandom Functions Revisited: The Cascade Construction», Proceedings of FOCS’96.

[Dobb] H. Dobbertin, «The Status of MD5 After a Recent Attack», RSA Labs’ CryptoBytes, Vol. 2 No. 2, Summer 1996. http://www.rsa.com/rsalabs/pubs/cryptobytes.html

[PV] B. Preneel and P. van Oorschot, «Building fast MACs from hash functions», Advances in Cryptology — CRYPTO’95 Proceedings, Lecture Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14.

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

[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982.

[RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, «RIPEMD-160: A strengthened version of RIPEMD», Fast Software Encryption, LNCS Vol 1039, pp. 71-82. ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.

[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

[Tsu] G. Tsudik, «Message authentication with one-way hash functions», In Proceedings of Infocom’92, May 1992. (Also in «Access Control and Policy Enforcement in Internetworks», Ph.D. Dissertation, Computer Science Department, University of Southern California, April 1991.)

[VW] P. van Oorschot and M. Wiener, «Parallel Collision Search with Applications to Hash Functions and Discrete Logarithms», Proceedings of the 2nd ACM Conf. Computer and Communications Security, Fairfax, VA, November 1994.

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

Hugo Krawczyk

IBM T.J. Watson Research Center

P.O.Box 704

Yorktown Heights, NY 10598

EMail: hugo@watson.ibm.com

Mihir Bellare

Dept of Computer Science and Engineering

Mail Code 0114

University of California at San Diego

9500 Gilman Drive

La Jolla, CA 92093

EMail: mihir@cs.ucsd.edu

Ran Canetti

IBM T.J. Watson Research Center

P.O.Box 704

Yorktown Heights, NY 10598

EMail: canetti@watson.ibm.com

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

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

nmalykh@gmail.com

1Message authentication code — код аутентификации сообщения.

2См. описание такие атак в Википедии. Прим. перев.