Рабочая группа по сетямM. Handley
Запрос комментариев: 2974ACIRI
Категория: ЭкспериментальныйC. Perkins
USC/ISI
E. Whelan
UCL
Октябрь 2000

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


Статус данной статьи

Данная статья предоставляет экспериментальный протокол сообществу Интернета. Данная статья не является каким-либо стандартом Интернета. Требуются обсуждение и предложения по улучшению. Распространение данной статьи не ограничивается.

Уведомление об авторских правах

Авторское право (C) за Обществом Интернета (2000). Все права защищены.

Аннотация

Данный документ описывает 2-ю версию протокола аннонсирования каталога мультикастовых сессий, Протокола аннонсирования сессий (Session Announcement Protocol, SAP), а также сопутствующие вопросы, затрагивая безопасность и масштабирование, которые должны быть приняты во внимание сетевыми администраторами.

1. Введение

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

Данная статья раскрывает вопросы, связанные с мультикастовым аннонсированием параметров описания сессий, и характеризует используемый аннонсовый протокол. Сессии описываются с использованием протокола описания сессий, который описывается в сопровождающей статье [4].

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

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

Получатель SAP-ов определяет подпространства мультикаста, в которых он находится (например, используя Протокол аннонсирования мультикастово ограниченных зон [5]) и (для определения) этих подпространств прослушивает общеизвестный SAP-адрес и порт. При таком подходе он в конечном итоге узнает все проанносированные сессии, получяя (возможность) присоединиться к этим сессиям.

Ключевые слова "ОБЯЗАН", "ОБЯЗАН НЕ", "ТРЕБУЕТСЯ", "НУЖНО", "НУЖНО НЕ", "СЛЕДУЕТ", "СЛЕДУЕТ НЕ", "РЕКОМЕНДУЕТСЯ", "МОЖНО" и "ДОПОЛНИТЕЛЬНЫЙ" в данном документе понимаются как описано в [1].

3 Анонсирование сессии

Как указано ранее, SAP-вещатель периодически отправляет анонсирующий пакет на общеизвестный адрес и порт. Не существует согласующего механизма: SAP-вещатель не заботится о присутствии или отсутсвии кого-либо из получателей SAP и никакой дополнительной надежности не предоставляется сверх стандартных наилучших средств UDP/IP.

Такой анонс содержит описание сессии и (ему) СЛЕДУЕТ иметь заголовок проверки подлинности. Описание сессии МОЖЕТ быть зашифровано, хотя это НЕ РЕКОМЕНДУЕТСЯ (см. раздел 7).

Анонсирование - это мультикаст из того же подпространства что и сессия, которую он аносирует, (тем самым) обеспечивая, что получатели анонса находятся внутри подпространства сессии, которую описывает анонсирование. Есть несколько вариантов:

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

SAP-аннонсирования ОБЯЗАНЫ отправляться на порт 9875 и (их) СЛЕДУЕТ отправлять со (значением) времени жизни IP равным 255 (использование ограничения по TTL для мультикаста не поощряется [7]).

Если сессия использует адреса из раздельных произвольно выбранных диапазонов подпространства, то вещателю необходимо отправлять одинаковые экземпляры анонса на каждый из произвольно выбранных диапазонов подпространства. От получателей требуется понимать такие размноженные анонсы как одну и ту же сессию (например, как указано полем источника Протокола описания сессии (Session Description Protocol, SDP, СДП). Скорость анонсирования для каждого произвольно выбранного диапазона подпространства ОБЯЗАНА быть вычислена отдельно как если бы размноженные анонсы были независимы.

Разные вещатели могут анонсировать одну сессию для обеспечения надежности в условиях потери пакетов и отказа одного или нескольких вещателей. Скорость, с которой каждый вещатель повторяет свои анонсы, ОБЯЗАНА быть поделена так, чтобы суммарная скорость анонсирования была равна той, которую выбрал бы один сервер. Анонсы, созданные таким образом ОБЯЗАНЫ быть одинаковыми.

Если для сессии создаются многократные анонсы, то каждый анонс ОБЯЗАН нести заголовок проверки подлинности, подписанный одним и тем же ключом, или быть обработан получателями как полностью отдельный анонс.

САП-получателю в IPv4 СЛЕДУЕТ прослушивать САП-адрес глобального пространства ИПв4 и САП-адреса каждой административной зоны подпространства, в которой находится. Обнаружение административных зон подпространств вне рамок данной статьи, но предполагается, что каждый САП-получатель внутри конкретной зоны подпространства знает (о существовании) этой зоны подпространства. САП-получателю, который поддерживает IPv6 СЛЕДУЕТ также прослушивать САП-адреса ИПв6.

3.1 Интервал анонсирования

Временной период между повторениями анонсов выбирается такой, чтобы суммарная полоса, даваемая всеми анонсами в одной САП-группе, оставалась ниже предустановленного лимита. Если другого не определено, то лимит полосы СЛЕДУЕТ принимать равным 4000 битов в секунду.

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

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

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

2. Учитывая заданную полосу пропускания в битах/секунду и анонсирование размером в размер_анонса байт, базовый интервал анонсирования в секундах будет:

интервал = максимум(300; (8*количество_анонсов*размер_анонса)/полоса)

3. Смещение вычисляется из базового интервала анонсирования:

Смещение = случайное(интервал*2/3) - интервал/3

4. Следующий момент передачи определяется так:

Тслед = Тпосл + интервал + смещение

Затем вещатель выставляет таймер на момент Тслед и ждёт. В момент Тслед вещателю СЛЕДУЕТ пересчитать момент следующей передачи. Если новое значение Тслед меньше текущего времени, то анонс отправляется немедленно. Иначе, отправка перепланируется на новый момент Тслед. Такое переназначение предотвращает всплеск транзитных пакетов при запуске и при восстановлении связи с участками сети.

4 Удаление сеанса

Сеанс может быть удален одним из нескольких способов:

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

5 Изменение сеанса

Ранее проанонсированные сеансы могут быть изменены простым анонсированием измененного дескриптора сеанса. В этом случае содержимое хэша в САП-заголовке ОБЯЗАНО быть изменено для указания приемникам того, что содержимое пакета должно быть проанализировано (или расшифровано и проанализировано, если оно зашифровано). Сам сеанс, в отличие от анонса сеанса, уникально описывается полезными данными а не хэш-кодом сообщения в заголовке.

Те же самые правила применяются для изменения сеанса, что и для удаления сеанса:

Если получен анонс, содержащий заголовок проверки подлинности, а кэшированный анонс не содержит заголовок проверки подлинности или он содержит отличающийся заголовок проверки подлинности, тогда измененный анонс ОБЯЗАН быть обработан как новый и другой анонс и отображен в дополнение к неаутентичному анонсированию. То же самое должно произойти, если измененный пакет без заголовка проверки подлинности получен из источника, отличного от источника первоначального анонса.

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

 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V=1 |A|R|T|E|C|   auth len    |         msg id hash           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                originating source (32 or 128 bits)            :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    optional authentication data               |
   :                              ....                             :
   *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
   |                      optional payload type                    |
   +                                         +-+- - - - - - - - - -+
   |                                         |0|                   |
   + - - - - - - - - - - - - - - - - - - - - +-+                   |
   |                                                               |
   :                            payload                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1 "Формат пакета"

6 Формат пакета

САП-пакеты данных имеют формат, изображенный на рисунке 1.

V: Номер версии.
Поле номера версии ОБЯЗАНО устанавливаться в 1 (анонсы SAPv2, которые используют только функции SAPv1 обратно совместимы, те которые используют новые функциимогут быть распознаны по другим признакам, поэтому номер версии САП изменять не нужно).
A: Тип адреса.
Если бит A равен 0, то поле первоначального источника содержит 32-битный адрес IPv4. Если бит A равен 1, то поле первоначального источника содержит 128-битный адрес IPv6.
R: Зарезервировано.
САП-вещатели ОБЯЗАНЫ устанавливать это (поле) в 0, САП-слушатели ОБЯЗАНЫ игнорировать содержимое этого поля.
T: Тип сообщения.
Если поле T установлено в 0, то это пакет анонсирования сеанса, если в 1 - пакет удаления сеанса.
E: Бит шифрования.
Если бит шифрования равен 1, то полезные данные САП-пакета зашифрованы. Если этот бит равен 0, то пакет не зашифрован. Для подробного описания процесса шифрования смотрите раздел 7.
C: Бит сжатия.
Если бит сжатия равен 1, то полезные данные сжаты с использованием алгоритма сжатия zlib [3]. Если полезные данные подлежат и сжатию, и шифрованию, то сжатие ОБЯЗАНО быть выполнено первым.
Длина (поля) аутентификации.
8-битная беззнаковая величина, обознающая количество 32-битных слов, следующих за главным САП-заголовком, которые содержат аутентификационные данные. Если здесь ноль, то заголовок проверки подлинности отсутствует.
Аутентификационные данные
содержат цифровую подпись пакета длиной, указанной в поле длины заголовка аутентификации. Для подробного описания процесса аутентификации смотрите раздел 8.
Хэш-код сообщения.
16-битная величина, которая используемая в сочетании с первоначальным источником, даёт глобально уникальный идентификатор, указывающий точную версию данного анонсирования. Выбор значения для данного поля здесь не оговаривается, кроме того что оно ОБЯЗАНО быть уникальным для каждого сеанса, проанонсированного отдельно взятым САП-вещателем и оно ОБЯЗАНО быть изменено, если изменен дескриптор сеанса (и СЛЕДУЕТ отправить сообщение удаления сеанса для старой версии сеанса).
Более ранние версии САПов использовали значение ноль для обозначение того, что хэш должен быть проигнорирован и полезная информация должна постоянно анализироваться. Это имело неприятный побочный эффект такой, что САП-вещатели вынуждены были просматривать полезные данные, чтобы определить сколько уникальных сеансов было объявлено, производя вычисление интервала анонсирования более сложно чем необходимо. Для того, чтобы отделить процесс анонсирования сеансов от содержимого этих сеансов, САП-вещателям СЛЕДУЕТ НЕ приравнивать хэш-код сообщения нулю.
САП-слушатели МОГУТ молча отбрасывать сообщения если хэш-код сообщения равен нулю.
Первоисточник.
Сообщает ИП-адрес изначального источника сообщения. Дает адрес IPv4 если поле A установлено в ноль, иначе это адрес IPv6. Адрес хранится в сетевом порядке байтов (ссылка на RFC1035 2.3.2)
SAPv0 разрешал первоисточнику равняться нулю, если хэш-код сообщения тоже был нулем. Такая практика более не разрешена и САП-вещателям СЛЕДУЕТ НЕ ставить в первоисточнике ноль. САП-слушатели МОГУТ молча отбрасывать сообщения если в первоисточнике указан ноль.

За заголовком следуют необязательное поле формата полезных данных и сами полезные данные. Если биты E и C использованы в заголовке, то обе (части): формат данных и сами данные зашифрованы и/или сжаты.

Поле формата полезных данных - это индентификатор типа MIME-содержимого, описывающий формат полезных данных. Это текстовая переменная ASCII переменной длины, завершаемая одним нулевым байтом (ASCII NUL). Формат полезных данных СЛЕДУЕТ вставлять во все пакеты. Если форматом полезных данных являтся "application/sdp", то и формат полезных данных, и его завершающий нулевой байт МОГУТ быть опущены, хотя это предназначено только для обратной совместимости с получателями SAPv1.

Отсутствие поля формата полезных данных может быть отмечено в том случае, если раздел полезных данных такого пакета будет начинаться с SDP-поля "v=0", которое является неофициальным индентификатором типа MIME-содержимого.

Все реализации ОБЯЗАНЫ поддерживать полезные данные формата "application/sdp" [4]. Другие форматы МОГУТ поддерживаться, хотя поскольку в САП нет согласования, (то) вещатель который решает использовать формат описания сеанса отличный от SDP, не может знать что получатели способны понять анонс. Увеличение типов полезных данных имеет потенциал, чтобы привести к серьезным проблемам с совместимостью, и по этой причине использование полезных данных отличного от SDP формата НЕ РЕКОМЕНДУЕТСЯ.

Если пакет является анонсным пакетом, то полезные данные содержат дексриптор сеанса.

Если пакет является пакетом удаления сеанса, то полезные данные содержат сообщение удаления сеанса. Если форматом полезных данных является "application/sdp", то сообщение об удалении это одна SDP-строка, состоящая из поля инициатора (ред: см. origin-field в RFC 2327) подлежащего удалению анонса.

Желательно, чтобы полезные данные были достаточно небольшие, чтобы САП-пакеты не фрагментировались базовой сетью. Для фрагментации свойственны потери составляющих, что как известно значительно влияет на надежность анонсирования. РЕКОМЕНДУЕТСЯ, чтобы САП-пакеты были меньше 1 Кбайта в длину, хотя если известно, что анонсы будут использовать сеть с меньшим MTU чем этот, тогда его (значение) СЛЕДУЕТ использовать в качестве рекомендуемого максимального размера пакета.

7 Шифрованные анонсы

Анонсирование принимается всеми слушателями в подпространстве, в которое оно отправлено. Если анонс зашифрован и большинство приемников не обладают ключом шифрования, то получаем значительный перерасход ширины канала, поскольку эти приемники не могут обработать анонс, который они получили. По этой причине использование шифрованных САП-анонсов НЕ РЕКОМЕНДУЕТСЯ в глобальном пространстве группы САП или в группах административного подпространства, в которых возможно находится большое количество приемников, которые не могут расшифровать эти анонсны.

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

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

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

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

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

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V=1 |P| Auth  |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |              Format  specific authentication subheader        |
   :                        ..................                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2: Формат аутентификационных данных в САП-заголовке

8 Проверяемые анонсирования

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

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

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

САП не привязан к какому-либо отдельно взятому механизму проверки подлинности. Проверочные данные в заголовке самодостаточны, но точный формат зависит от используемого механизма проверки подлинности. Общий формат проверочных данных представлен на рисунке 2. Структура форматозависимого подзаголовка аутентификации оговорена в разделах 8.1 и 8.2 соответственно. Дополнительные форматы могут быть добавлены в будущем.

Номер версии, V:
Номер версии формата аутентификации, определяемого данной статьей, равен 1.
Бит расширения, P:
Если необходимо, проверочные данные дополняются, чтобы быть кратными 32 битам, и используется бит расширения. В этом случае последний байт проверочных данных содержит количество дополнительных байт (включая последний байт), которые обязаны быть отброшены.
Тип аутентификации, Auth:
Тип аутентификации - это 4-х битное кодифицированное поле, которое обозначает способ аутентификации, использование которого отправитель ожидает от приемников для проверки достоверности и целостности информации. Он определяет формат подзаголовка аутентификации и может принимать значения: 0 = PGP-формат, 1 = CMS формат. Все другие значения не определены и (ред: их) СЛЕДУЕТ игнорировать.

Если САП-пакет подвергается сжатию или шифрованию, то это ОБЯЗАНО быть выполнено перед добавлением аутентификации.

Цифровая подпись в аутентификационных данных ОБЯЗАНА вычисляться по всему пакету, включая заголовок. Длина (переводчик: поля) аутентификации ОБЯЗАНА выставляться в ноль и аутентификационные данные исключаться когда вычисляется цифровая подпись.

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

8.1 Аутентификация по PGP

Полное описание протокола PGP можно найти в [2]. Когда используется PGP для SAP-аутентицикации, то базовый форматозависимый подзаголовок аутентификации содержит пакет цифровой подписи как описано в [2]. Тип подписи ОБЯЗАН равняться 0x01, что означает подпись канонического текстового документа.

8.2 Аутентификация по CMS

Полное описание Синтаксиса криптографического сообщения (Cryptographic Message Syntax, CMS) можно найти в [6]. Форматозависимый подзаголовок аутентификации будет, в случае с CMS, иметь тип "ASN.1 ContentInfo" с "ContentType", являющимся "signedData".

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

СЛЕДУЕТ быть только одному signerInfo и подобным полям, соответствующим источнику анонса САП. Атрибуту signingTime СЛЕДУЕТ присутствовать как signedAttribute. Однако, из-за строгих ограничений по размеру пакетов САП, сертификаты и CRL-ы СЛЕДУЕТ НЕ включать в структуру signedData. Полагается, что пользователи протокола будут иметь иные методы для сертификации и распространения CRL.

9 Масштабируемость и кэширование

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

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

Протокол, по которому САП-слушатель связывается со своим локальным кэширующим прокси, здесь не определяется.

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

САП содержит механизмы для обеспечения целостности сеансовых анонсов, для проверки подлинности происхождения анонса и для шифрования таких анонсов (разделы 7 и 8).

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

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

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

А. Сводка отличий между SAPv0 и SAPv1

Для этой цели (ред: сравнение) SAPv0 определяется как протокол, используемый версией 2.2 утилиты каталога сеансов, sdr. SAPv1 - это протокол, описанный в версии данной статьи от 19 ноября 1996 г. Заголовки пакетов САП-сообщений одинаковы в V0 и V1, поэтому утилита для V1 может анализоровать заголовок от V0, но не наоборот. В SAPv0 поля имеют следующие значения:

Б. Сводка отличий между SAPv1 и SAPv2

Заголовки пакетов САП-сообщений одинаковы в V1 и V2, поэтому утилита для V2 может анализоровать заголовок от V1, но не обязательно наоборот.

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

SAP и SDP изначально базировались на протоколе, используемом в каталоге сеансов sd от Ван Якобсона (Van Jacobson) из LBNL. Версия 1 САПа была разработана Марком Хендли (Mark Handley) как часть проектов European Commission MICE (Esprit 7602) и MERCI (Telematics 1007). Версия 2 включает функции проверки подлинности, разработанные Эдмундом Вэланом (Edmund Whelan), Голи Монтассер-Косари (Goli Montasser-Kohsari) и Питером Кирштейном (Peter Kirstein) как часть проекта European Commission ICE-TEL (Telematics 1005), и поддержка IPv6 разработана Марьянном П. Махером (Maryann P. Maher) и Колином Перкинсом (Colin Perkins).

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

Mark Handley
AT&T Center for Internet Research at ICSI,
International Computer Science Institute,
1947 Center Street, Suite 600,
Berkeley, CA 94704, USA

EMail: mjh@aciri.org

Colin Perkins
USC Information Sciences Institute
4350 N. Fairfax Drive, Suite 620
Arlington, VA 22203, USA

EMail: csp@isi.edu

Edmund Whelan
Department of Computer Science,
University College London,
Gower Street,
London, WC1E 6BT, UK

EMail: e.whelan@cs.ucl.ac.uk

Список литературы

  1. Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
  2. Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP message format", RFC 2440, November 1998.
  3. Deutsch, P. and J.-L. Gailly, "Zlib compressed data format specification version 3.3", RFC 1950, May 1996.
  4. Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
  5. Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone announcement protocol (MZAP)", RFC 2776, February 2000.
  6. Housley, R., "Cryptographic message syntax", RFC 2630, June 1999.
  7. Mayer, D., "Administratively scoped IP multicast", RFC 2365, July 1998.

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

Авторское право (C) за Обществом Интернета (2000). Все права защищены.

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

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

Данный документ и содержащаяся в нем информация предоставляется по принципу "что есть, то и есть" и ISOC, и IETF ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ явных или подразумеваемых, включая но не ограничиваясь любыми гарантиями, что ИСПОЛЬЗОВАНИЕ публикуемой информации НЕ НАРУШИТ какие-либо ПРАВА или любые подразумеваемые ГАРАНТИИ рыночной стоимости или (гарантии) применения для определенной цели.

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

Финансирование деятельности редактора RFC в настоящее время осуществляется Обществом Интернета.


Перевод выполнил Колесников Иван.
При использовании материала данного перевода указывайте источник. Пишите.