RFC 4656 A One-way Active Measurement Protocol (OWAMP)

Network Working Group                                        S. Shalunov
Request for Comments: 4656                                 B. Teitelbaum
Category: Standards Track                                        A. Karp
                                                                J. Boote
                                                            M. Zekauskas
                                                               Internet2
                                                          September 2006

A One-way Active Measurement Protocol (OWAMP)

Протокол одностороннего активного измерения (OWAMP)

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

Протокол одностороннего активного измерения OWAMP служит для измерения в одном направлении таких характеристик, как задержка и потеря пакетов. Высокоточное измерение этих односторонних параметров производительности IP стало возможным благодаря доступности надежных источников точного времени (таких как GPS и CDMA). OWAMP обеспечивает совместимость измерений.

Оглавление

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

1. Введение

Рабочая группа IETF IPPM1 определила метрику для односторонней задержки [RFC2679] и потери [RFC2680] пакетов на пути Internet. Хотя уже имеется несколько измерительных платформ ([SURVEYOR] [SURVEYOR-INET] [RIPE] [BRIX]) реализующих такую метрику, пока нет стандарта, позволяющего инициировать тестовые потоки или обмениваться пакетами для сбора отдельных параметров в совместимой манере.

Расширение сферы доступности недорогих систем глобального позиционирования (GPS2) и источников точного времени на базе CDMA, хосты все чаще применяют источники точного времени напрямую или через протокол NTP3 от первичных (stratum 1) серверов точного времени. Путем стандартизации методов односторонних измерений IPPM можно надеяться создать среду, где параметры IPPM можно будет собирать через широкую сеть путей Internet, что не было возможно раньше. Одним из проявлений этого послужит широкое развертывание серверов OWAMP, которые сделают возможным одностороннее измерение задержки, а также времени кругового обхода с использованием основанных на ICMP инструментов, подобных ping.

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

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

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

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

1.1. Связи между протоколами тестирования и управления

OWAMP на деле состоит из двух связанных протоколов — OWAMP-Control и OWAMP-Test. OWAMP-Control служит для инициирования, запуска и остановки тестовых сессий, а также для сбора их результатов, а OWAMP-Test применяется для обмена тестовыми пакетами между измерительными узлами.

Хотя OWAMP-Test можно применять с другим (не OWAMP-Control) протоколом управления, авторы осознанно включили оба протокола в один RFC для стимулирования реализации и развертывания OWAMP-Control в качестве общего протокола управления разделителями для односторонних измерений. Наличие полного и открытого решения для односторонних измерений, которое легко реализовать и развернуть, имеет решающее значение для будущего в плане внутридоменных односторонних активных измерений, которые могут стать столь же привычным инструментом, как ping. Здесь не предлагается и не рекомендуется использовать OWAMP-Control как основу для универсального расширяемого решения в части управления мониторингом и измерениями.

OWAMP-Control разработан для поддержки согласования сессий одностороннего активного измерения и извлечения результатов простым способом. При инициировании сеанса происходит согласование адресов и номеров портов отправителя и получателя, времени начала сессии, ее продолжительности, размера тестовых пакетов, среднего интервала выборки Пуассона и некоторых атрибутов общего назначения [RFC 2330], включая размер пакета и поэтапное поведение (PHB5) [RFC2474], которые могут применяться для поддержки одностороннего измерения характеристик сети через сети с дифференцированным обслуживанием. В дополнение к этому OWAMP-Control поддерживает на уровне сессии шифрование и аутентификацию для тестового и управляющего трафика, серверы измерений, которые могут служить посредниками (proxy) для конечных точек тестового потока, обмен значениями «затравок» (seed) для псевдослучайного процесса Пуассона, описывающего тестовый поток, генерируемый отправителем.

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

1.2. Логическая модель

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

Session-Sender

Передающая сторона сессии OWAMP-Test.

Session-Receiver

Принимающая сторона сессии OWAMP-Test.

Server

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

Control-Client

Конечная система, которая инициирует запрос сессий OWAMP-Test, запускает сессии и может инициировать их прерывание.

Fetch-Client

Конечная система, инициирующая запросы на извление результатов завершенных сессий OWAMP-Test.

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

+----------------+               +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+               +------------------+
  ^                                     ^
  |                                     |
  |                                     |
  |                                     |
  |  +----------------+<----------------+
  |  |     Server     |<-------+
  |  +----------------+        |
  |    ^                       |
  |    |                       |
  | OWAMP-Control         OWAMP-Control
  |    |                       |
  v    v                       v
+----------------+     +-----------------+
| Control-Client |     |   Fetch-Client  |
+----------------+     +-----------------+


Хост может выступать одновременно в нескольких ролях. Например, приведенная на рисунке схема может быть реализована на двух хостах, один из которых играет роли Control-Client, Fetch-Client и Session-Sender, а другой — Server и Session-Receiver, как показано ниже.

+-----------------+                   +------------------+
| Control-Client  |<--OWAMP-Control-->| Server           |
| Fetch-Client    |                   |                  |
| Session-Sender  |---OWAMP-Test----->| Session-Receiver |
+-----------------+                   +------------------+


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

2. Обзор протокола

Как отмечено выше, OWAMP включает два связанных между собой протокола — OWAMP-Control и OWAMP-Test. Первый работает на основе TCP и служит для организации и управления сеансами измерения, а также для сбора результатов. Второй протокол работает на основе UDP и служит для передачи отдельных тестовых пакетов по проверяемому пути Internet.

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

Сообщения OWAMP-Control передаются только до запуска сессий OWAMP-Test и после их завершения (исключением являются сообщения Stop-Sessions).

Протоколы OWAMP-Control и OWAMP-Test поддерживают три режима работы — без аутентификации (unauthenticated), с аутентификацией (authenticated) и шифрованный (encrypted). Для двух последних режимов конечным точкам может потребоваться общий секрет.

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

3. OWAMP-Control

Тип каждого сообщения OWAMP-Control можно определить после чтения первых 16 октетов. Размер сообщения OWAMP-Control можно рассчитать после считывания части сообщения фиксированного размера. Сообщений короче 16 октетов не бывает.

Реализациям следует исключать неиспользуемые состояния для предотвращения атак на службы или неограниченного расхода памяти на сервере. Например, если полное управляющее сообщение не было получено в течение некоторого числа минут после ожидаемого времени, соединение TCP, связанное с сессией OWAMP-Control, следует сбросить (drop). При отсутствии других соображений разумной верхней границей ожидания представляется значение 30 минут.

3.1. Организация соединения

Нужно организовать соединение с сервером (Server) до того, как Control-Client или Fetch-Client смогут подавать команды серверу.

Сначала клиент организует соединение TCP с общеизвестным портом 861 на сервере. Сервер будет отвечать приветственным сообщением, формат которого показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     Unused (12 октетов)                       |
|                                                               |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Modes                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Challenge (16 октетов)                     |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Salt (16 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Count (4 октета)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       MBZ (12 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Режим работы может принимать несколько значений: 1 — без аутентификации, 2 — с аутентификацией и 4 — с шифрованием. Значение поля Modes в сообщении сервера является результатом операции ИЛИ (OR) для всех значений, которые сервер готов поддерживать в этой сессии. Таким образом, используются три последних бита 32-битового поля Modes, а все предшествующие биты (29) должны иметь значение 0. Клиенты должны игнорировать первые 29 битов значения Modes (эти биты доступны для будущих расширений протокола).

Поле Challenge содержит случайную последовательность октетов, создаваемую сервером, которая затем применяется клиентом для подтверждения владения общим секретом, как описано ниже

Параметры Salt и Count применяются при создании ключа из общего секрета, как описано ниже.

Значение Salt должно быть псевдослучайным (генерируется независимо от чего-либо иного в этом документе).

Значение Count должно быть степенью 2 и не менее 1024. Значение Count следует увеличивать по мере роста производительности расчетов.

Значение Modes = 0 указывает, что сервер не хочет взаимодействовать с клиентом и тот может незамедлительно разорвать соединение. Клиенту следует закрывать соединение при получении приветствия с Modes = 0. Клиент может закрыть соединение, если желаемый для него режим не доступен.

В иных случаях клиент дожен вернуть показанное ниже сообщение Set-Up-Response.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Mode                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                      KeyID (80 октетов)                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                       Token (64 октета)                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                    Client-IV (16 октетов)                     .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Поле Mode здесь указывает выбранный клиентом режим для данной сессии OWAMP-Control. Этот режим будет также применяться для всех сессий OWAMP-Test, начатых под управлением этой сессии OWAMP-Control. В поле Mode должен быть установлен один из трех последних битов или сброшены все биты. Если один из трех последних битов установлен, этот бит должен указывать один из поддерживаемых сервером режимов (т. е. этот бит должен быть установлен в полученном ранее приветствии от сервера). Первые 29 битов поля Mode должны быть сброшены (0). Сервер должен игнорировать значения этих битов. Если клиент установил Mode = 0, это говорит о том, что клиент не будет продолжать сессию. В этом случае клиенту и серверу следует закрыть соединение TCP, связанное с сессией OWAMP-Control.

В режиме без аутентификации (1) поля KeyID, Token и Client-IV не используются. В остальных случаях KeyID содержит строку UTF-8 размером до 80 октетов (более короткие значения дополняются нулевыми октетами), которая указывает серверу общий секрет, выбранный клиентом для использования при проверке подлинности или шифровании, а Token содержит конкатенацию 16-октетного вызова (challenge), 16-октетного ключа AES Session-key для шифрования и 32-октетного ключа HMAC-SHA1 Session-key для аутентификации. Сам маркер шифруется с помощью алгоритма AES (Advanced Encryption Standard) [AES] в режиме CBC8. Шифрование должно выполняться с использованием вектора инициализации IV9 = 0 и ключа, выведенного из общего секрета, связанного с KeyID (клиент и сервер используют общее отображение KeyIDs на значения секретов, сервер, готовый работать с множеством клиентов использует KeyID для выбора подходящего ключа, клиент обычно имеет свои ключи для каждого сервера; это похоже на использование паролей).

Общий секрет является парольной фразой и должен быть одной строкой (без символов перевода строки). Секретный ключ выводится из этой парольной фразы с использованием функции PBKDF2 (PKCS #5) [RFC2898]. PBKDF2 требует нескольких параметров — PRF является HMAC-SHA1 [RFC2104], а salt и count берутся из серверного сообщения.

Случайные значения AES Session-key, HMAC Session-key и Client-IV создаются клиентом. AES Session-key и HMAC Session-key должны генерироваться с достаточной энтропией, не снижающей уровень защиты базового шифра [RFC4086]. Значение Client-IV просто должно быть уникальным (т. е. должны быть разные в каждой сессии, использующей один секретный ключ). Простым способом решения этой задачи является генерация Client-IV с помощью криптографически стойкого источника псевдослучайных чисел. В таком случае вероятность повтора значения мала в течение 264 сессий с одним секретным ключом.

Сервер должен ответить приведенным ниже сообщением Server-Start.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        MBZ (15 октетов)                       |
|                                                               |
|                                               +-+-+-+-+-+-+-+-+
|                                               |   Accept      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    Server-IV (16 октетов)                     |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Start-Time (Timestamp)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (8 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

Случайное значение Server-IV генерируется сервером, а в режиме без аутентификации не применяется.

Поле Accept указывает отношение сервера к продолжению сессии. Accept=0 указывает, что сервер принял аутентификацию и готов продолжать транзакции. Отличное от 0 значение говорит о том, что сервер не принял аутентификацию или по иной причине не желает продолжать транзакции в этой сессии OWAMP-Control. Полный список доступных значений поля Accept приведен в параграфе 3.3.

Если передан негативный (не 0) отклик, сервер может (а клиенту следует) закрыть соединение после сообщения.

Start-Time содержит временную метку момента начала работы текущего экземпляра сервера (например, в многопользовательской операционной системе общего назначения это может быть время запуска серверного процесса). Если поле Accept отлично 0, все биты Start-Time следует заполнить 0. В режимах с аутентификацией и шифрованием поле Start-Time шифруется, как описано в параграфе 3.4, если Accept = 0 (режимы с аутентификацией и шифрованием не могут начать работу, пока не будет инициализировано управляющее соединение).

Формат поля Timestamp описан в параграфе 4.1.2. Экземпляру сервера следует сообщать одинаковое значение Start-Time каждому клиенту в каждой сессии.

Предыдущая транзакция считает соединение организованным.

3.2. Защита целостности (HMAC)

Аутентификация каждого сообщения (называется также командой) в OWAMP-Control обеспечивается добавлением HMAC. Протокол OWAMP применяет HMAC-SHA1 с отсечкой до 128 битов, т. е. поле HMAC имеет размер 16 октетов. Для HMAC нужен ключ. HMAC Session-key передается вместе с AES Session-key при организации соединения OWAMP-Control. Значение HMAC Session-key следует создавать независимо от AES Session-key (реализация может применять один механизм для генерации случайных битов обоих ключей). Каждое переданное в данном направлении значение HMAC учитывает все, что было передано в этом направлении после предыдущего HMAC (не включая его) и до начала нового кода HMAC. Таким путем после установки шифрования каждый бит соединения OWAMP-Control аутентифицируется кодом HMAC в точности один раз.

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

Значение HMAC должно проверяться как можно раньше для предотвращение использования и распространения поврежденных данных.

В открытом режиме поля HMAC не используются и имеют такую же семантику, как поля MBZ.

3.3. Значения поля Accept

Значения поля Accept используются протоколом OWAMP-Control для передачи сервером откликов на запросы клиента. Полный набор возможных значений приведен ниже.

0 OK (принято).

1 Отказ без указания причины (подходит все).

2 Внутренняя ошибка.

3 Некоторые аспекты запроса не поддерживаются.

4 Невозможно выполнить запрос по причине постоянного ограничения ресурсов.

5 Невозможно выполнить запрос по причине временного ограничения ресурсов.

Все прочие значения являются резервными. Отправитель сообщения может использовать значение 1 вместо всех отличных от 0 значений Accept. Отправителю следует корректное значение Accept, если оно отличается от 1. Получатель должен интерпретировать все отличающиеся от приведенных выше значения Accept как 1. Это обеспечивает доступность таких значений для будущих расширений.

3.4. Команды OWAMP-Control

В режиме с аутентификацией или шифрованием (они идентичны для OWAMP-Control и различаются лишь в OWAMP-Test) все последующие коммуникации шифруются с помощью AES Session-key (в режиме CBC) и аутентифицируются с использованием HMAC Session-key. Клиент шифрует все, что он передает в только что организованное соединение OWAMP-Control, применяя потоковое шифрование с Client-IV в качестве IV. Соответственно, сервер шифрует на свое стороне соединения с использованием Server-IV в качестве IV.

Сами векторы инициализации IV передаются в открытом виде. Шифрование начинается с блока, следующего непосредственно за блоком с IV. Два потока (от клиента к серверу и обратно) шифруются независимо со своими IV, но используют один ключ AES Session-key.

Для клиента доступны команды Request-Session, Start-Sessions, Stop-Sessions и Fetch-Session. Команда Stop-Sessions доступна клиенту и серверу (сервер также передает другие сообщения в ответ на полученные команды).

После передачи клиентом команды Start-Sessions и до отправки и получения (в любом порядке) команды Stop-Sessions клиент ведет активные измерения. О сервере говорят, что он ведет активные измерения с момента получения им команды Start-Sessions и до передачи и приема (в любом порядке) команды Stop-Sessions.

При выполнении активных измерений доступна лишь команда Stop-Sessions.

Более подробное описание команд приведено ниже.

3.5. Организация тестовых сессий

Отдельные сеансы односторонних активных измерений организуются с использованием протокола запросов-откликов. Клиент OWAMP может (но не обязан) отправить множество сообщений Request-Session серверу OWAMP, который должен ответить на каждое сообщением Accept-Session. Это сообщение может отвергать запрос клиента.

Формат сообщения Request-Session показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      1        |  MBZ  | IPVN  |  Conf-Sender  | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Number of Schedule Slots                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number of Packets                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Sender Port          |         Receiver Port         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sender Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|      Sender Address (продолжение) или MBZ (12 октетов)        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Receiver Address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|      Receiver Address (продолжение) или MBZ (12 октетов)      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       SID (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Padding Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Start Time                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Timeout (8 октетов)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Type-P Descriptor                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (8 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Далее следует одно или несколько описаний временных интервалов расписания (число интервалов указывается полем Number of Schedule Slots)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Slot Type  |                                               |
+-+-+-+-+-+-+-+-+        MBZ (7 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Slot Parameter (Timestamp)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Затем сразу же следует HMAC

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Все эти сообщения образуют одну команду the Request-Session.

На рисунке выше (начало страницы) первый октет со значением 1 указывает команду Request-Session.

IPVN указывает номера версии IP для отправителя и получателя. Для IP версии 4 за адресами IPv4 в Sender Address и Receiver Address следуют 12 неиспользуемых октетов. Эти октеты должны устанавливаться в 0 клиентаом и должны игнорироваться сервером. В настоящее время осмысленными значениями IPVN являются 4 и 6.

В полях Conf-Sender и Conf-Receiver клиент должен указывать значение 0 или 1. Сервер должен интерпретировать отличные от 0 значения как 1. Если поле имеет значение 1, серверу предлагается настроить соответствующий агент (отправитель или получатель). В этом случае соответствующее значение Port серверу следует игнорировать. По крайней мере одно из значений Conf-Sender и Conf-Receiver должно быть 1 (при установке значения 1 для обоих серверу предлагается сессия между двумя хостами, которые он может настроить).

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

Number of Packets указывает число пакетов активного измерения, передаваемых в течение данной сессии OWAMP-Test (отметим, что сессия может прервана раньше клиентом или сервером).

Если поле Conf-Sender не установлено (0), Sender Port задает порт UDP, из которого будут передаваться пакеты OWAMP-Test. Если поле Conf-Receiver не установлено (0), Receiver Port указывает порт UDP в который запрашивается передача пакетов OWAMP-Test.

Поля Sender Address и Receiver Address содержат, соответственно, адреса отправителя и получателя, являющихся конечными точками пути Internet, для которого запрашивается сессия тестирования OWAMP.

SID указывает идентификатор сессии. Он может применяться в последующих сессиях как аргумент команды Fetch-Session. Идентификатор имеет значение лишь при Conf-Receiver = 0. Таким образом, SID всегда генерируется принимающей стороной (информация о создании SID приведена в конце параграфа).

Поле Padding length указывает число октетов, добавляемых в конце обычного пакета OWAMP-Test (см. ниже).

Поле Start Time указывает время начала сессии (не раньше ввода команды Start-Sessions). Это временная метка в том же формате, что и метки OWAMP-Test.

Timeout (или порог потерь) задает интервал времени (в виде временной метки). Пакет, относящийся к тестовой сессии, организованной текущей командой Request-Session, будет считаться потерянным, если он не будет получен в течение Timeout после отправки.

Type-P Descriptor покрывает только часть (очень большого) пространства Type-P. Если первые два бита Type-P Descriptor имеют значение 00, следующие 6 битов указывают запрашиваемое значение DSCP11 для передаваемых пакетов OWAMP-Test, как определено в [RFC2474]. Если первые два бита Type-P имеют значение 01, следующие 16 битов указывают PHB ID12, как определено в [RFC2836].

Значение, содержащее только 0, указывает принятое по умолчанию обслуживание best-effort.

Если поле Conf-Sender установлено (не 0), Type-P Descriptor служит для настройки отправителя на передачу пакетов в соответствии со значением этого поля. Если Conf-Sender = 0, Type-P Descriptor указывает, как будет настроен отправитель.

Если поле Conf-Sender установлено (не 0), а сервер не распознал Type-P Descriptor или не хочет устанавливать соответствующие атрибуты пакетов OWAMP-Test, ему следует отвергнуть запрос сессии. Если Conf-Sender =0, серверу следует воспринимать или отбрасывать сессию, не обращая внимания на значение Type-P Descriptor.

На каждый запрос Request-Session сервер OWAMP должен отвечать показанным ниже сообщением Accept-Session.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Accept     |  MBZ          |            Port               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                                                               |
|                       SID (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       MBZ (12 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


В этом сообщении поле Accept = 0 показывает, что сервер готов продолжать сессию, а все остальные значения отвергают запрос. Полный список значений поля Accept приведен в параграфе 3.3.

Если сервер отвергает сообщение Request-Session, ему следует не сохранять соединение TCP. Клиент может закрыть соединение, получив негативный отклик на сообщение Request-Session.

Смысл поля Port в отклике зависит от значений Conf-Sender и Conf-Receiver в вызвавшем отклик запросе. Если оба поля были установлены (не 0), поле Port не используется. Если было установлено лишь поле Conf-Sender, Port указывает номер порта, из которого ожидаются пакеты OWAMP-Test. Если было установлено только поле Conf-Receiver, Port указывает номер порта, в который передаются пакеты OWAMP-Test.

Если было установлено лишь поле Conf-Sender, поле SID в отклике не используется. В остальных случаях SID содержит уникальный идентификатор сессии, созданный сервером. Позднее он может применяться для сбора результатов данной сессии.

Значения SID следует создавать путем конкатенации 4 октетов адреса IPv4, относящегося к генерирующей идентификатор машине, 8-октетной временной метки и 4 октетов случайного значения. Для снижения вероятности конфликтов при наличии на генерирующей машине любых адресов IPv4 (за исключением loopback) один из таких адресов следует применять при генерации SID даже в случае коммуникаций на основе IPv6. Если адресов IPv4 нет совсем, можно использовать 4 последних октета адреса IPv6. Отметим, что значение SID всегда выбирается получателем. Если случайные значения не доступны, важно обеспечить непредсказуемость SID, поскольку значение идентификатора может быть использовано для контроля доступа.

3.6. Планирование передачи

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

Для реализации этого применяется планирование с заданным числом временных интервалов, каждый из которых имеет тип и параметр. Поддерживается два типа — псевдослучайные значения с экспоненциальным распределением (0) и фиксированные значения (1). Параметры указываются временными метками, задающими интервал времени. Для интервалов типа 0 (псевдослучайные значения с экспоненциальным распределением) этот интервал является средним значением (или 1/lambda, если плотность распределения имеет вид lambda*exp(-lambda*x) с положительными значениями x). Для интервалов типа 1 (фиксированное значение) параметр указывает задержку. Отправитель начинает выполнение расписания и исполняет инструкции временного интервала — для типа 0 время ожидания определяется экспоненциально распределенным значением со средним интервалом, заданным параметром, по истечении которого передается пакет (и обрабатывается следующий интервал), для слотов типа 1 время ожидания фиксировано. Расписание является циклическим и после выполнения всех интервалов отправитель возвращается к первому.

Отправитель и получатель должны быть способны воспроизводить расписание целиком (поэтому при потере пакета получатель все равно может связать с ним временную метку отправки). Воспроизведение интервалов типа 1 является тривиальной задачей. Для воспроизведения интервалов типа 0 нужна возможность воспроизводимой генерации псевдослучайных значений с экспоненциальным распределением. Способы решения этой задачи рассмотрены в разделе 5.

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

  • Поток Пуассона — один интервал типа 0.

  • Периодический поток — один интервал типа 1.

  • Поток Пуассона из последовательных пар пакетов — два интервала типа 0 с отличным от 0 параметром и один интервал типа 1 с параметром 0.

Кроме того, можно задать совершенно произвольное расписание (хоть это и неэффективно) путем создания множества тестовых пакетов, число которых совпадает с числом интервалов расписания. В этом случае полное расписание передается перед сессией OWAMP-Test.

3.7. Запуск тестовой сессии

Запросив одну или несколько тестовых сессий и получив положительные отклики Accept-Session, клиент OWAMP может начать выполнение запрошенного сеанса тестов, передав серверу сообщение Start-Sessions, показанное ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      2        |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                       MBZ (15 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Сервер должен ответить сообщением Start-Ack (его следует отправлять как можно скорей), показанным ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Accept    |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                       MBZ (15 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Если поле Accept отлично от 0, запрос Start-Sessions отвергается, 0 означает восприятие команды. Полный список возможных значений Accept дан в параграфе 3.3. Сервер может, а клиенту следует закрывать соединение отвергнутой сессии.

Серверу следует запускать все потоки OWAMP-Test сразу после отклика или заданного времени старта (что позднее). Если клиент представляет отправителя (Sender), ему следует щапускать свои потоки OWAMP-Test сразу после получения отклика Start-от сервера (если команда Start-Sessions воспринята) или заданного времени старта (что позднее). Поведение отправителя OWAMP-Test более подробно описано ниже.

3.8. Stop-Sessions

Сообщения Stop-Sessions может передавать Control-Client или сервер. Форма сообщения показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      3        |    Accept     |              MBZ              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number of Sessions                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (8 октетов)                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                                                               |
|                       SID (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Next Seqno                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Number of Skip Ranges                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Сразу за этим могут (не обязательно) следовать описания Skip Range, как указано полем Number of Skip Ranges. Диапазоны пропуска — это просто два порядковых номера, указывающие диапазон пакетов, которые не были переданы.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                      First Seqno Skipped                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Last Seqno Skipped                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

В заключение добавляется один блок (16 октетов) HMAC, завершающий сообщение Stop-Sessions.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Все эти записи образуют одно логическое сообщение — команду Stop-Sessions.

Первый октет со значением 3 в приведенном выше формате указывает команду Stop-Sessions.

Отличное от 0 значение Accept показывает тот или иной отказ, а 0 — нормальное (возможно, преждевременное) завершение. Полный список значений поля Accept приведен в параграфе 3.3.

Если поле Accept отлично от 0 (в сообщении любой стороны), результаты всех сессий OWAMP-Test, собранные в этй сессии OWAMP-Control, следует считать непригодными, даже если Fetch-Session с SID из данной сессии работает для другой сессии OWAMP-Control. Если Accept не было передано совсем (по любой причине, включая разрыв соединения TCP, используемого для OWAMP-Control), результаты всех сессий OWAMP-Test, собранные в этй сессии OWAMP-Control, можно считать непригодными.

Number of Sessions указывает число описаний сессий, которые следуют сразу за заголовком Stop-Sessions.

Поле Number of Sessions должно указывать число сеансов передачи, начатых локальной стороной управляющего соединения, которые не были прерваны ранее командой Stop-Sessions (т. е. Control-Client должен учитывать каждое воспринятое сообщение Request-Session с установленным Conf-Receiver, Control-Server должен учитывать каждое воспринятое сообщение Request-Session с установленным Conf-Sender). Если сообщение Stop-Sessions не учитывает точно сеансы передачи, контролируемые данной стороной, он считается недействительным и соединение следует разорвать, а все полученные результаты считать недействительными.

Каждое описание сессии представляет одну сессию OWAMP-Test.

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

Next Seqno указывает следующий порядковый номер, который был бы отправлен из данного сеанса передачи. Для завершенных сессий это поле будет совпадать с NumPackets из Request-Session.

Number of Skip Ranges указывает число реальных пропусков в процессе передачи. Это диапазоны пакетов, которые в действительности не были отправлены передающим процессом. Например, если сеанс передачи начался слишком поздно для передачи первых 10 и это является единственным пропуском в расписании, поле Number of Skip Ranges будет иметь значение 1. Одно описание Skip Range будет иметь First Seqno Skipped = 0 и Last Seqno Skipped = 9. Дополнительная информация приведена в параграфе 4.1.

если соединение OWAMP-Control прерывается при передаче команды Stop-Sessions, получатель может не объявлять все результаты сессии непригодными. Он должен отбросить все записи для пакетов, следующих (с большим порядковым номером) за последним пакетом, который был действительно получен до всех записей о потере пакетов. Это поможет отделить пакеты, потерянные в сети, от пакетов, которые отправитель не передал.

Если принимающая сторона сессии OWAMP-Test узнает из сообщения OWAMP-Control Stop-Sessions, что последний порядковый номер у отправителя OWAMP-Test менбше любого из реально полученных порядковых номеров, результаты всех сессии OWAMP-Test должны быть признаны недействительными.

Получатель в сессии OWAMP-Test по команде OWAMP-Control Stop-Sessions должен отбросить все записи для пакетов (включая записи о потерях) с (рассчитанным) временем отправки в интервале Timeout до текущего времени. Это обеспечивает статистическую согласованность измерения потерь и дубликатов в случаях, когда Timeout больше времени, требуемого на выполнение команды Stop-Sessions.

Для завершения сессии каждой стороне управляющего соединения следует дождаться завершения всех измерительных сессий перед отправкой сообщения Stop-Sessions. Время завершения каждой сессии определяется интервалом Timeout после запланированного времени для последнего порядкового номера. Конечные точки могут немного добавлять к рассчитаному времени завершения для передающей конечной точки, чтобы обеспечить прием получателем сообщения Stop-Sessions уже после интервала Timeout.

Для преждевременного завершения сессии сторона, инициирующая эту команду, должна остановить свой поток передачи OWAMP-Test, чтобы передать значения Session Packets Sent до отправки команды. Этой стороне следует дождаться получения отклика Stop-Sessions перед остановкой приема потоков, чтобы можно было использовать значения из полученного сообщения Stop-Sessions для проверки данных.

3.9. Fetch-Session

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      4        |                                               |
+-+-+-+-+-+-+-+-+                                               |
|                       MBZ (7 октетов)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Begin Seq                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          End Seq                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       SID (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Begin Seq указывает порядковый номер первого запрошенного пакета, а End Seq — номер последнего. Если Begin Seq содержит только 0, а End Seq — только 1, это означает запрос всех пакетов сессии.

Если запрошена сессия целиком и эта сессия продолжается или прервана аномальным способом, запрос на выборку сессии должен отвергаться. Если запрошена неполная сессия, следует возвращать все пакеты, попадающие в запрошенный диапазон. Отметим, что в результате невозможности ввода команд между Start-Sessions и Stop-Sessions неполные запросы могут возникать лишь на другом соединении OWAMP-Control (от того же или другого Control-Client).

Сервер должен отвечать сообщением Fetch-Ack, формат которого показа ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Accept    | Finished      |          MBZ (2 октета)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Next Seqno                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Number of Skip Ranges                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Number of Records                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

Поле Finished имеет отличное от 0 значение, если сессия OWAMP-Test прервана.

Next Seqno указывает следующий порядковый номер, который был бы отправлен из этого сеанса передачи. Для завершенных сессий значение этого поля будет совпадать с NumPackets из Request-Session. Эта информация доступна лишь для прерванных сессий. Если Finished = 0, сервер должен установить Next Seqno = 0.

Number of Skip Ranges указывает число реальных пропусков в процессе передачи. Эта инфоормация доступна лишь для прерванных сессий. Если Finished = 0, сервер должен установить Skip Ranges = 0.

Number of Records указывает число записей для пакетов, попадающих в запрошенный диапазон. Это значение может быть меньше Number of Packets при воспроизведении команды Request-Session, поскольку сессия может быть завершена преждевременно или больше по причине наличия дубликатов.

Отличное от 0 значение Accept говорит о завершении отклика на сообщение Fetch-Session. Если Accept = 0, сервер должен незамедлительно передать данные соответствующей сессии OWAMP-Test.

Данные сессии OWAMP-Test являются конкатенацией перечисленных ниже значений.

  • Воспроизведение команды Request-Session, которая была использована для старта сессии, измененная так, что всегда указываются реальные номера портов отправителя и получателя в сеансе OWAMP-Test.

  • Необязательные (число задано) описания Skip Range. Последний (возможно, неполный) блок (16 октетов) описания Skip Range при необходимости дополняется нулями.

  • 16 октетов HMAC.

  • Необязательные (число задано) записи для пакетов. Последний (возможно, неполный) блок (16 октетов) описания Skip Range при необходимости дополняется нулями.

  • 16 октетов HMAC.

Описание Skip Range является просто двумя порядковыми номерами, указывающими диапазон пропущенных пакетов.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|                      First Seqno Skipped                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Last Seqno Skipped                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Описания Skip Range следует передавать в порядке возрастания First Seqno. Если какие-либо Skip Range перекрываются или нарушают порядок, данные сессии считаются непригодными и соединение следует закрывать, считая результаты недействительными.

Каждая запись для пакета имеет размер 25 октетов и включает 4-октетный порядковый номер, 8-октетную временную метку отправки, 2 октета оценки ошибки этой метки, 8-октетную временную метку приема, 2 октета оценки ошибки этой метки и 1 октет TTL или Hop Limit (IPv6).

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00|                          Seq Number                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04|      Send Error Estimate      |    Receive Error Estimate     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08|                         Send Timestamp                        |
12|                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16|                       Receive Timestamp                       |
20|                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24|    TTL        |
  +-+-+-+-+-+-+-+-+


Записи для пакетов передаются в том же порядке, как передавались реальные пакеты.

Отметим, что потерянные пакеты (при наличии потерь в сеансе OWAMP-Test) должны указываться в последовательности пакетов. Они могут указываться в точке обнаружения потери или в любом месте после нее. Записи для потерянных пакетов отличаются по приведенным ниже признакам.

  • В поле временной метки передачи указывается предполагаемое значение (расписание передающей стороны).

  • В поле оценки ошибки времени передачи указываются Multiplier=1, Scale=64, S=0 (см. описание OWAMP-Test, где приведены определения этих параметров и описан формат временных меток и оценки ошибок).

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

  • Временная метка приема содержит только нули.

  • TTL = 255.

4. OWAMP-Test

В этом разделе описывается протокол OWAMP-Test, который работает на основе UDP с использованием адресов IP и номеров портов отправителя и получателя, согласованных в процессе обмена Request-Session.

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

4.1. Поведение отправителя

4.1.1. Синхронизация пакетов

Расписание передачи основанное на временных интервалах, описанных выше, в сочетании с запланированным временем начала сессии позволяет отправителю и получателю рассчитать точное расписание отправки пакетов независимо друг от друга. Такое планирование передачи выполняется независимо для разных сессий OWAMP-Test даже в рамках одной сессии OWAMP-Control.

Рассмотрим любую сессию OWAMP-Test. После завершения обмена Start-Sessions отправитель готов к началу передачи пакетов. В обычных вариантах применения OWAMP время отправки первого пакета находится в ближайшем будущем (возможно, доли секунды). Отправителю следует передавать пакеты как можно ближе к запланированному времени с одним исключением — если запланированное время уже прошло и отделено от текущего интервалом больше Timeout, отправителю недопустимо передавать пакет (он в любом случае будет считаться потерянным). Отправитель должен отслеживать пакеты, которые не были переданы. Эта информация будет передана получателю путем установки Skip Ranges в сообщении Stop-Sessions получателю по завершении теста. Поле Skip Ranges передается также Fetch-Client как часть результатов сессии. Пропуски в запланированной передаче могут возникать, если в команде Request-Session было указано уже прошедшее время, обмен Start-Sessions занял слишком много времени или отправитель не смог своевременно начать обслуживание сессии OWAMP-Test в результате внутренних проблем планирования ОС. Пакеты из прошлого, отделенного от текущего времени интервалом меньше Timeout, следует передать как можно быстрее. При нормальных скоростях тестирования и значениях тайм-аута число пакетов в таких «пиках» ограничено. Тем не менее, хостам не следует преднамеренно планировать сессии с такими «пиками».

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

4.1.2. Формат и содержимое пакетов OWAMP-Test

Отправитель передает получателю поток пакетов по расписанию, указанному в команде Request-Session. Отправителю следует устанавливать в поле IPv4 TTL (или IPv6 Hop Limit) в пакетах UDP значение 255. Формат пакетов UDP в потоке зависит от используемого режима.

Для режима без аутентификации формат пакета имеет вид, показанный ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
.                                                               .
.                         Packet Padding                        .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Формат пакетов для режимов с аутентификацией и шифрованием показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       MBZ (12 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      HMAC (16 октетов)                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Packet Padding                         .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Формат временных меток совпадает с описанным в [RFC1305] и первые 32 бита представляют беззнаковым целым числом количество целых секунд, прошедших с 0 часов 1 января 1900 г., а следующие 32 бита представляют дробную часть нецелой секунды с указанного момента.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Integer part of seconds                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Fractional part of seconds                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Поле Error Estimate указывает оценку ошибки синхронизации и использует показанный ниже формат.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z|   Scale   |   Multiplier  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Первый бит (S) следует устанавливать, если генерирующая временную метку сторона имеет часы, синхронизированные с UTC от внешнего источника (например, бит следует устанавливать при получении позиции и текущего времени от GPS или использовании NTP для синхронизации с внешним источником stratum 0). Если часы не имеют источника внешней синхронизации, устанавливать бит не следует. Следующий бит имеет семантику полей MBZ, он должен сбрасываться отправителем и игнорироваться в остальных случаях. Следующие 6 битов указывают целое число без знака, так же как поле Multiplier. Эти поля интерпретируются как оценка ошибки выражением Multiplier*2-32*2Scale (в секундах). В поле Multiplier недопустимо значение 0 и пакеты с Multiplier = 0 следует считать поврежденными и отбрасывать.

Порядковые номера начинаются с 0 и увеличиваются на 1 для каждого следующего пакета.

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

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

В режиме с аутентификацией первый блок (16 октетов) каждого пакета шифруется с использованием AES (ECB) mode.

Подобно сессиям OWAMP-Control, каждая сессия OWAMP-Test имеет два ключа — AES Session-key и HMAC Session-key. Однако получение этих ключей происходит иначе — в OWAMP-Control ключи генерируются клиентом и сообщаются (как часть Token) в процессе организации соединения как часть сообщения Set-Up-Response, а в описываемом здесь OWAMP-Test ключи выводятся из ключей OWAMP-Control и SID.

OWAMP-Test AES Session-key получается путем шифрования OWAMP-Control AES Session-key (совпадает с AES Session-key в соответствующей сессии OWAMP-Control, где он применяется в другом режиме цепочки) с помощью AES с 16-октетным идентификатором SID в качестве ключа (шифрование ECB с одним блоком). Результатом является OWAMP-Test AES Session-key, применяемый для шифрования (и расшифровки) пакетов в конкретной сессии OWAMP-Test. Отметим, что все OWAMP-Test AES Session-key, OWAMP-Control AES Session-key и SID состоят из 16 октетов.

OWAMP-Test HMAC Session-key получается путем шифрования OWAMP-Control HMAC Session-key ( совпадает с HMAC Session-key в соответствующей сессии OWAMP-Control) с помощью AES с 16-октетным идентификатором SID в качестве ключа (шифрование с двумя блоками CBC и IV=0). Результатом является OWAMP-Test HMAC Session-key, применяемый для проверки подлинности пакетов в отдельной сессии OWAMP-Test. Отметим, что все OWAMP-Test HMAC Session-key и OWAMP-Control HMAC Session-key состоят из 32 октетов, а SID — из 16.

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

В режиме с шифрованием два первых блока (32 октета) шифруются в режиме AES CBC. Ключ AES Session-key выводится так же, как для режима с аутентификацией. Каждый пакет OWAMPшифруется как отдельный поток, с одной операцией сцепки — цепочка не охватывает множество пакетов, поэтому потеря, дублирование или нарушение порядка пакетов не вызывают проблем. Вектор инициализации для шифрования CBC имеет значение 0 во всех битах.

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

HMAC в OWAMP-Test охватывает лишь часть пакета, которая также шифруется. Таким образом, в режиме с аутентификацией HMAC охватывает первый блок (16 октетов), в режиме шифрования — два первых блока (32 октета). В OWAMP-Test значение HMAC не шифруется (отметим, это отличие от OWAMP-Control, где применяется потоковое шифрование и блоки HMAC тоже зашифрованы).

В режиме без аутентификации шифрование или проверка подлинности не применяются.

В полях Packet Padding пакетов OWAMP-Test следует использовать псевдослучайные значения (они должны генерироваться независимо от других упоминаемых в документе псевдослучайных чисел). Однако реализация должна поддерживать конфигурационный параметр (опция) или другой способ для заполнения Packet Padding нулями.

Интервал между пакетами рассчитывается в соответствии с расписанием, как указано в описании команды Request-Session. Здесь не рассмотрены вопросы расчета псевдослучайных чисел с экспоненциальным распределением предсказуемым способом, поскольку оно описано в другом разделе (см. ниже).

4.2. Поведение получателя

Получателю известно, когда отпревитель будет передавать пакеты. В сообщении Request-Session задается параметр Timeout и при задержке пакета на время, превышающее Timeout пакет считается потерянным (или «похожим на потерянный»). Отметим, что в сети никогда нет гарантии потери и «потерянный» пакет может быть доставлен в любой момент. Исходная спецификация IPv4 требует доставки пакета в течение TTL секунд (максимальное значение TTL = 255) или его «недоставки». Насколько известно авторам, это требование фактически никогда не выполнялось (и оишь полная и универсальная реализация смогла бы бы гарантировать, что пакеты не перемещаются в сети более TTL секунд). В IPv6 имя этого поля было изменено на Hop Limit. Кроме того, спецификация IPv4 не указывает время прохождения пакетом последнего интервала пути.

Выбор разумного значения Timeout является проблемой, с которой сталкивается пользователь протокола OWAMP, а не разработчики. Значение порядка двух минут вполне безопасно. Отметим, что некоторые приложения (например, интерактивный «односторонний ping») могут захотеть получать данные быстрее.

При получении пакета

  • фиксируется временная метка приема;

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

  • сохраняются порядковый номер пакета, время отправки и получения и TTL для IPv4 (Hop Limit для IPv6) из заголовка IP для последующей передачи результатов.

Пакеты, не полученные в интервале Timeout, считаются потерянными. Они записываются с порядковым номером, предполагавшимся временем приема, нулевым временем приема и TTL (или Hop Limit) 255.

Реализациям следует извлекать значение TTL/Hop Limit из IP-заголовка в пакете. Если реализация не извлекает реальное значение TTL (единственной причиной этого может невозможность доступа к полю TTL в приходящих пакетах), она должна записывать TTL = 255.

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

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

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

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

  • Временная метка отличается от текущего времени в ту или иную сторону больше, чем на Timeout.

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

  • В режиме с аутентификацией или шифрованием проверка HMAC не прошла.

5. Расчет псевдослучайных чисел

Здесь описывается способ генерации экспоненциальных случайных значений, используемых протоколом. Хотя имеется достаточно много алгоритмов генерации экспоненциальных случайных переменных, большинство из них основано на логарифмической функции в качестве примитива, что может приводить к разным значениям в зависимости от конкретной реализации математической библиотеки (math). Здесь применяется алгоритм 3.4.1.S из книги [KNUTH], в котором нет упомянутой проблемы и который гарантирует одинаковый результат в любой реализации. Алгоритм относится к семейству ziggurat, разработанному в 1970-х годах G. Marsaglia, M. Sibuya и J. H. Ahrens [ZIGG]. Логарифмическая функция в нем заменена манипуляциями с битами, которые дают на выходе экспоненциальные переменные.

5.1. Высокоуровневое описание алгоритма

Для простоты описания алгоритм сначала рассматривается с естественной интерпретацией арифметических операций. Затем приводятся точные детали типов данных, арифметики и генерации случайных переменных с однородным распределением. Это почти дословная цитата из книги [KNUTH], стр.133.

Алгоритм S. Для данного положительного действительного числа mu, создается случайная переменная с экспоненциальным распределением и средним значением mu.

Сначала заранее рассчитываются константы

   Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!),  1 <= k <= 11

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

S1. [Получение U и сдвиг] Генерируется 32-битовая случайная дробная часть с однородным распределением

   U = (.b0 b1 b2 ... b31)    [обратите внимание на точку в начале]

Находится первый нулевой бит b_j и выполняется сдвиг начальных j+1 битов путем установки U <- (.b_{j+1} … b31)

Примечание. В редких случаях отсутствия нулевого бита алгоритм возвращает mu*32*ln2.

S2. [Подходит сразу?] Если U < ln2, устанавливается X <- mu*(j*ln2 + U) и алгоритм завершает работу (Q[1] = ln2.)

S3. [Минимизация.] Находится наименьшее k >= 2 такое, что U < Q[k]. Генерируется k новых дробных частей с однородным распределением U1,…,Uk и устанавливается V <- min(U1,…,Uk).

S4. [Выдача результата] Устанавливается X <- mu*(j + V)*ln2.

5.2. Типы данных, представление и арифметика

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

Целые числа u_int64_t интерпретируются как действительные путем установки запятой (точки) после первых 32 битов. Иными словами, интерпретация имеет форму отображения

          u_int64_t u;
          u  |--> (double)u / (2**32)

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

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

   #1      0xB17217F8,
   #2      0xEEF193F7,
   #3      0xFD271862,
   #4      0xFF9D6DD0,
   #5      0xFFF4CFD0,
   #6      0xFFFEE819,
   #7      0xFFFFE7FF,
   #8      0xFFFFFE2B,
   #9      0xFFFFFFE0,
   #10     0xFFFFFFFE,
   #11     0xFFFFFFFF

Например, Q[1] = ln2 действительно интерпретируется как 0xB17217F8/(2**32) = 0,693147180601954, а для j > 11, Q[j] = 0xFFFFFFFF.

Небольшое целое число j в алгоритме верхнего уровня представляется как значение j*232 типа u_int64_t.

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

      (u, v) |---> (u * v) >> 32.

Реализации должны точно рассчитывать произведение u*vy. Например, для этого может применяться часть арифметики 128-битовых целых чисел без знака (см. пример реализации в приложении A).

5.3. Однородные случайные величины

Процедура получения последовательности 32-битовых случайных чисел (например, U в алгоритме S) основана на использовании алгоритма AES в режиме счетчика. Для точного описания работы алгоритма применяется два примитива Rijndael. Из прототипы и спецификация даны ниже и предполагается, что они будут представлены поддерживающей Rijndael реализацией, такой как [RIJN].

  • Функция, инициализирующая ключ Rijndael байтами из seed (идентификатор SID), имеет вид

       void KeyInit(unsigned char seed[16]);
  • Функция, шифрующая 16-октетный блок inblock с помощью заданного ключа, возвращая 16-октетный шифрованный блок (keyInstance является «непрозрачным» типом, представляющим ключи Rijndael) имеет вид

       void BlockEncrypt(keyInstance key, unsigned char inblock[16]);

Алгоритм Unif. Для данного 16-октетного значения seed создается последовательность 32-битовый случайных чисел без знака с однородным распределением. В OWAMP в качестве seed применяется значение SID (идентификатор сессии) из протокола управления.

U1. [Инициализация ключа Rijndael] key <- KeyInit(seed) [Инициализация 16-октетного беззнакового счетчика с сетевым порядком байтов] c <- 0

U2. [Требуются дополнительные случайные байты?] Set i <- c mod 4. If (i == 0) set s <- BlockEncrypt(key, c)

U3. [Инкрементирование счетчика как 16-октетного числа без знака] c <- c + 1

U4. [Вывод] Выводится i_th квартетов октетов из s, начиная со старших октетов, с преобразованием к естественному порядку байтов и представлением в виде значения OWPNum64 (как в 3.b).

U5. [Цикс=л] переход к U2.

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

6.1. Введение

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

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

Цель режима с шифрованием несколько иная — он осложняет посторонним на пути через сеть возможность представить результаты Лучше», чем на самом деле. Это особенно важно в тех случаях, когда клиент или сервер не является ни отправителем, ни получателем.

Шифрование OWAMP-Control в режиме AES CBC с блоками HMAC после каждого сообщения нацелено на (i) обеспечение конфиденциальности обмена и (ii) проверки подлинности каждого сообщения.

6.2. Предотвращение атак на службы

Сессии OWAMP-Test, нацеленные на ничего не подозревающую систему, могут служить для организации DoS13-атак. В режиме без аутентификации серверам следует ограничивать получателей хостами, которые они контролируют или клиентами OWAMP-Control client.

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

В любом случае пакеты OWAMP-Test с данным адресом отправителя должны передаваться лишь с узла, которому этот адрес назначен (т. е. подмена адресов не разрешается).

6.3. Скрытые информационные каналы

Сессии OWAMP-Test могут использоваться в качестве скрытых каналов передачи информации. Это обстоятельство следует учитывать в средах, где возможность утечки имеет значение.

6.4. Требование включения AES в реализации

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

6.5. Ограничение использования ресурсов

Сервер OWAMP может потреблять ресурсы разных типов, наиболее важными из которых являются пропускная способность сети и память (первичная и вторичная) для хранения результатов тестирования.

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

Одним из способов реализации механизмов ограничения ресурсов является привязка каждой сессии к классу пользователей. Классы частично упорядочиваются отношениями «включения», один класс (все пользователи) всегда присутствует и включает все остальные классы. Привязка сессии к классу пользователей может основываться на наличии аутентификации сессии, KeyID, диапазоне адресов IP, времени суток или иных факторах. Для каждого класса задается предел используемых ресурсов пропускной способности (в бит/с) и памяти для хранения результатов (в октетах). octets). Наряду с ограничением сервер будет отслеживать текущее использование ресурсов. Когда сеанс запрашивается пользователем определенного класса, рассчитываются требуемые для сессии ресурсы — средняя пропускная способность (на основе планирования передачи) и максимальное использование памяти (на основе числа пакетов и октетов каждого пакета, которые нужно хранить14). Эти параметры использования ресурсов добавляются к текущим параметрам загрузки ресурсов для данного класса пользователей. Если полученные значения выходят за установленные для данного класса пределы, сессия отвергается. При возврате ресурсов добавленные ранее значения вычитаются из параметров загрузки ресурсов для данного класса. Пропускная способность возвращается по завершении сеанса, а память — после удаления данных. Для сессий без аутентификации потребляемую сессией OWAMP-Test память следует возвращать после закрытия (любым способом) соединения OWAMP-Control, инициировавшего данную сессию. Для сессий с аутентификацией администратору, настраивающему сервис, следует давать возможность установить точные правила. Полезными для реализации могут быть механизмы, способные автоматически возвращать память по истечении настраиваемого (на основе класса пользователей) интервала после завершения сессии OWAMP-Test.

6.6. Использование криптографических примитивов в OWAMP

На начальном этапе разработки протокола рассматривалось использование TLS15 [RFC2246, RFC3546] и IPsec [RFC2401] в качестве механизмов криптографической защиты OWAMP, а позднее был рассмотрен протокол DTLS. Недостатки этих механизмов частично указаны ниже.

TLS

  • TLS можно применить для защиты TCP-соединений OWAMP-Control, но сложно использовать для UDP-сессий OWAMP-Test. При потере пакетов OWAMP-Test они не повторяются, поэтому пакету нужно аутентифицировать и (опционально) шифровать по-отдельности для сохранения применимости каждого пакета. Потоковый сервис TLS сложно приспособить для этого.

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

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

  • TLS требует достаточно большой реализации. Например, OpenSSL превышает реализацию всего OWAMP. Это может вызвать проблемы для встраиваемых систем.

DTLS

  • Дублирование и нарушение порядка — это те явления, которые OWAMP должен измерять, поэтому меры защиты от повторов (anti-replay) и нарушения порядка в DTLS будут препятствовать измерениям, поскольку пакеты не попадут в соответствующие части кода OWAMP. Конечно, можно изменить DTLS так, чтобы эти меры были ослаблены или даже задать проверку сообщений в тщательно продуманной последовательности где-то между проверками DTLS, но тогда преимущества этого протокола просто не будут использоваться.

  • В режиме с аутентификацией временные метки передаются в открытом виде и не защищены криптографически, тогда как остальная часть сообщения имеет такую же защиту как в режиме с шифрованием. Это является компромиссом с отказом от криптографической в пользу точности временных меток. Например, аппаратная реализация OWAMP APAN [APAN] может поддерживать режим с аутентификацией. Точность измерений составляет доли микросекунд. Ошибки в измерениях OWAMP реализации Abilene [Abilene] (программная реализация с шифрованием) превосходят 10 мксек. Пользователи в разных средах сталкиваются с различными проблемами и для некоторых микросекундная точность может быть важна. В то же время пользователи этих же систем могут быть озабочены контролем доступа к сервису. Режим с аутентификацией позволяет им контролировать доступ к серверу с одновременным использованием незащищенных временных меток, возможно создаваемых на аппаратном уровне.

IPsec

  • То, что названо здесь режимом с аутентификацией, невозможно (IPsec не позволяет аутентифицировать часть пакета).

  • Развертывание путем IPsec и OWAMP может быть раздельным, если OWAMP не зависит от IPsec. После 9 лет применения IPsec, лиль 0,05% трафика в крупных магистральных сетях, таких как Abilene, использует IPsec (для сравнения SSH применяется в 2-4%, а HTTPS — 0,2-0,6%). Желательно иметь возможность развертывания OWAMP на максимально большом числе разных платформ.

  • Проблемы развертывания протокола, зависящего от IPsec, обостряются для облегченных встраиваемых устройств. Коммутаторы Ethernet, «модемы» DSL и другие устройства часто не поддерживают IPsec.

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

По указанным причинам было принято решение применять криптографический протокол (на базе блочного шифра в режиме CBC), отличающийся от TLS и IPsec.

6.7. Замена криптографического примитива

В будущем может возникнуть потребность в замене алгоритма AES или способа его использования в OWAMP другим криптографическим примитивом или внести в протокол другие изменения, связанные с защитой. OWAMP обеспечивает четко указанные точки расширения — слово Modes в приветствии сервера и отклик Mode в сообщении Set-Up-Response. Например, при необходимости заменить AES другим блочным шифром с размером блока 128 битов это можно сделать достаточно просто. Берутся два бита из резервной (MBZ) части слова Modes в приветствии сервера, один из этих битов применяется для индикации режима шифрования с новым алгоритмом, а другой — для режима с аутентификацией, использующей новый шифр. На практике можно обойтись даже одним битом, если клиенту разрешено возвращать выбор режима с несколькими установленными битами, один из которых будет указывать поддержку нового шифра (в случае сервера) или выбор (в случае клиента) и продолжение использования уже выделенных режимов аутентификации и шифрования. Такая оптимизация концептуально не важна, но может обеспечить на практике более эффективное использование битов. Затем, если новый шифр согласован, все последующие операции просто используют его вместо AES. Отметим, что в этом случае будет применяться обычная последовательность перехода — реализации вероятно начнут с поддержки и предпочтения нового шифра, а затем прекратят поддержку старого (например, сочтенного небезопасным).

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

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

Если потребуется шифр с иным размером ключа (скажем, 256 битов), нужна будет и новая функция вывода ключей для OWAMP-Test. Семантику смены шифра следует в таком случае связывать с семантикой замены функции вывода ключей KDF16. Одной из KDF для таких целей может служить псевдослучайная функция (PRF17) с выходом подходящего размера, таким как 256 битов (возможно, HMAC-SHA256, если она еще будет считаться защищенной PRF), который можно применить для создания сеансовых ключей OWAMP-Test на основе сеансового ключа OWAMP-Control с использованием его в качестве ключа HMAC и идентификатора SID в качестве сообщения HMAC.

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

6.8. Долгосрочные ключи с ручным управлением

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

6.9. Отказ от использования времени в качестве «затравки»

Вполне естественно использовать текущее время в качестве «затравки» (salt) при создании сеансовых ключей. К сожалению это оказывается слишком ограниченным.

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

С учетом этого время не применяется в качестве затравки при создании ключей.

6.10. Использование AES-CBC и HMAC

Конфиденциальность OWAMP опирается на AES-CBC, а проверка подлинности сообщений — на HMAC-SHA1, урезанный до 128 битов. Случайный выбор IV важен для предотвращения атак codebook на первый блок (следует также отметить, что, благодаря 128-битовым блокам, алгоритм AES более устойчив к codebook-атакам, чем шифры с более короткими блоками). В любом случае здесь применяется случайное значение IV.

Значения HMAC должны проверяться. Важно выполнить эту проверку до использования сообщения, поскольку иначе будут возможны подделки. Полное сообщение, для которого проверка HMAC привела к отказу, должны отбрасываться (как короткие из нескольких блоков, так и длинные сообщения, такие как отклики на команду Fetch-Session). Если такое сообщение является частью сессии OWAMP-Control, соединение должно разрываться.

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

Особым случаем является первое (фиксированного размера) сообщение, переданное клиентом. Здесь маркер представляет собой конкатенацию 128-битового вызова (challenge), передаваемого сервером в открытом виде, 128-битового ключа AES Session-key (генерируется клиентом, шифруется AES-CBC с IV=0) и 256-битового ключа HMAC-SHA1 Session-key, служащего для аутентификации. Поскольку IV=0, challenge (один блок шифра) просто шифруется с секретным ключом. Поэтому протокол полагается на устойчивость AES к атакам по выбранному открытому тексту (когда атакующий может подменить challenge). Следует отметить, что число блоков выбранного атакующим открытого текста, которые он может зашифровать с помощью секретного ключа, ограничено количеством сессий, которые клиент хочет инициировать. Атакующий, который знает шифрование серверного вызова (challenge) может подделать сеансовый ключ и в результате нарушить сессию, однако любой атакующий может прервать сессию путем повреждения протокольных сообщений. Поэтому никакой новой угрозы здесь не возникает, но тем не менее требуется, чтобы сервер не применял дважды один и тот же вызов (challenge). При случайной генерации challenge повтор может происходить в среднем после 264 сессий, что представляется удовлетворительным, поскольку даже для очень сильно загруженных серверов, поддерживающих миллионы сессий в секунду, повтор случиться через 500 веков. Что касается второй части маркера, атакующий может создать поддельный сеансовый ключ, изменив вторую часть маркера клиента, не затрагивая первую. Такая подделка будет сразу же обнаружена клиентом, когда проверка HMAC в следующем сообщении от сервера (восприятие или отклонение соединения) завершится отказом.

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

Авторы благодарны Guy Almes, Mark Allman, Jari Arkko, Hamid Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Scherrer, Henk Uijterwaal и Sam Weiler за их комментарии, предложения, обзоры, дискуссии и правки.

8. Взаимодействие с IANA

Агентство IANA выделило номер порта TCP 861 для компоненты OWAMP-Control протокола OWAMP.

9. Поддержка естественных языков

Протокол не переносит какой-либо информации на естественных языках за исключением KeyID в OWAMP-Control с кодировкой UTF-8.

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

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

[AES] Advanced Encryption Standard (AES), http://csrc.nist.gov/encryption/aes/

[BCP107] Bellovin, S. and R. Housley, «Guidelines for Cryptographic Key Management», BCP 107, RFC 4107, June 2005.

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

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

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, May 1998.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Delay Metric for IPPM», RFC 2679, September 1999.

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Packet Loss Metric for IPPM», RFC 2680, September 1999.

[RFC2836] Brim, S., Carpenter, B., and F. Le Faucheur, «Per Hop Behavior Identification Codes», RFC 2836, May 2000.

[RFC2898] Kaliski, B., «PKCS #5: Password-Based Cryptography Specification Version 2.0», RFC 2898, September 2000.

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

[APAN] Z. Shu and K. Kobayashi, «HOTS: An OWAMP-Compliant Hardware Packet Timestamper», In Proceedings of PAM 2005, http://www.springerlink.com/index/W4GBD39YWC11GQTN.pdf

[BRIX] Brix Networks, http://www.brixnet.com/

[ZIGG] J. H. Ahrens, U. Dieter, «Computer methods for sampling from the exponential and normal distributions», Communications of ACM, volume 15, issue 10, 873-882, 1972. http://doi.acm.org/10.1145/355604.361593

[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, revised reprint with updates, 1997.

[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd edition, 1998.

[Abilene] One-way Latency Measurement (OWAMP), http://e2epi.internet2.edu/owamp/

[RIJN] Reference ANSI C Implementation of Rijndael, http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip

[RIPE] RIPE NCC Test-Traffic Measurements home, http://www.ripe.net/test-traffic/.

[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.

[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, «Surveyor: An Infrastructure for Network Performance Measurements», Proceedings of INET’99, June 1999. http://www.isoc.org/inet99/proceedings/4h/4h_2.htm

[RFC1305] Mills, D., «Network Time Protocol (Version 3) Specification, Implementation and Analysis», RFC 1305, March 1992.

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

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, November 1998.

[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, «Transport Layer Security (TLS) Extensions», RFC 3546, June 2003.

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

Приложение A. Пример кода C для экспоненциальных переменных

Массив Q[] содержит точные значения, которые должны использоваться всеми реализациями (см. параграфы 5.1 и 5.2). Данное приложение дано лишь для иллюстрации.

   /*
   ** Пример использования - генерируется поток экспоненциальных (mean 1)
   ** случайных величин (с игнорированием проверки ошибок при инициализации).
   ** Если нужна переменная со средним значением mu, отличным от 1, выход
   ** алгоритма можно умножить на mu в соответствии с правилами описываемой
   ** арифметики.

   ** Предположим, что 16-октетная «затравка» (seed) инициализирована
   ** (например, в качестве общего секрета OWAMP) значением
   ** unsigned char seed[16];

   ** OWPrand_context next;

   ** (инициализация состояния)
   ** OWPrand_context_init(&next, seed);

   ** (генерация последовательности экспоненциальных переменных)
   ** while (1) {
   **    u_int64_t num = OWPexp_rand64(&next);
         <операции с num>
                    ...
   ** }
   */

   #include <stdlib.h>

   typedef u_int64_t u_int64_t;

   /* (K - 1) является первым k, для которого Q[k] > 1 - 1/(2^32). */
   #define K 12

   #define BIT31   0x80000000UL    /* проверка того, что первый из младших 
                                      32 битов имеет значение 0. */
   #define MASK32(n)       ((n) & 0xFFFFFFFFUL)

   #define EXP2POW32       0x100000000ULL

   typedef struct OWPrand_context {
           unsigned char counter[16];/* Счетчик (сетевой порядок байтов).*/
           keyInstance key;          /* Ключ для шифрования счетчика.*/
           unsigned char out[16];    /* Зашифрованный блок.*/
   } OWPrand_context;

   /*
   ** Массив рассчитывается по формуле
   **
   **       Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
   **
   ** как описано в алгоритме S. (Tприведенные ниже значения были 
   ** умножены на 2^32 и округлены до ближайшего целого числа.)
   ** Эти точные значения ДОЛЖНЫ применяться так, чтобы разные
   ** реализации давали одинаковые последовательности.
   */
   static u_int64_t Q[K] = {
           0,        /* Заменитель, чтобы индексы массива начинались с 1. */
           0xB17217F8,
           0xEEF193F7,
           0xFD271862,
           0xFF9D6DD0,
           0xFFF4CFD0,
           0xFFFEE819,
           0xFFFFE7FF,
           0xFFFFFE2B,
           0xFFFFFFE0,
           0xFFFFFFFE,
           0xFFFFFFFF
   };

   /* Этот элемент представляет ln2 */
   #define LN2 Q[1]

   /*
   ** Преобразует 32-битовое целое число без знака в u_int64_t.
   */
   u_int64_t
   OWPulong2num64(u_int32_t a)
   {
           return ((u_int64_t)1 << 32) * a;
   }

   /*
   ** Арифметические функции для чисел u_int64_t.
   */

   /*
   ** Сложение.
   */
   u_int64_t
   OWPnum64_add(u_int64_t x, u_int64_t y)
   {
           return x + y;
   }

   /*
   ** Умножение. Допускается переполнение. Простая реализация
   ** алгоритма 4.3.1.M (стр. 268) из [KNUTH].
   */
   u_int64_t
   OWPnum64_mul(u_int64_t x, u_int64_t y)
   {
           unsigned long w[4];
           u_int64_t xdec[2];
           u_int64_t ydec[2];

           int i, j;
           u_int64_t k, t, ret;

           xdec[0] = MASK32(x);
           xdec[1] = MASK32(x>>32);
           ydec[0] = MASK32(y);
           ydec[1] = MASK32(y>>32);

           for (j = 0; j < 4; j++)
                   w[j] = 0;

           for (j = 0; j < 2; j++) {
                   k = 0;
                   for (i = 0; ; ) {
                           t = k + (xdec[i]*ydec[j]) + w[i + j];
                           w[i + j] = t%EXP2POW32;
                           k = t/EXP2POW32;
                           if (++i < 2)
                                   continue;
                           else {
                                   w[j + 2] = k;
                                   break;
                           }
                   }
           }
           ret = w[2];
           ret <<= 32;
           return w[1] + ret;
   }


   /*
   ** «Затравка» генератора случайных чисел с использованием 16-байтового
   ** значения seed (идентификатор сессии вOWAMP). Эта функция реализует
   ** этап U1 алгоритма Unif.
   */

   void
   OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
   {
           int i;

           /* Инициализация ключа */
           rijndaelKeyInit(next->key, seed);

           /* Инициализация счетчика нулями */
           memset(next->out, 0, 16);
           for (i = 0; i < 16; i++)
                   next->counter[i] = 0UL;
   }


   /* Функции генерации случайных чисел. */
   /*
   ** Создает и возвращает 32-битовые случайные значения с однородным
   ** распределением (сохраняются в младшей половине the u_int64_t). 
   ** Эта функция реализует этапы U2-U4 алгоритма Unif.
   */
   u_int64_t
   OWPunif_rand64(OWPrand_context *next)
   {
           int j;
           u_int8_t  *buf;
           u_int64_t  ret = 0;

           /* Этап U2 */
           u_int8_t i = next->counter[15] & (u_int8_t)3;
           if (!i)
                   rijndaelEncrypt(next->key, next->counter, next->out);

           /* Этап U3. Инкрементирование next.counter как 16-октетного
              значения в сетевым порядком байтов для AES в режиме счетчика. */
           for (j = 15; j >= 0; j--)
                   if (++next->counter[j])
                           break;

           /* Этап U4. Вывод. Последние 4 байта ret содержат случайное
              целое число с сетевым порядком байтов. */
           buf = &next->out[4*i];
           for (j=0; j<4; j++) {
                   ret <<= 8;
                   ret += *buf++;
           }
           return ret;
   }

   /*
   ** Генерация экспоненциальной переменной со средним значением 1.
   */
   u_int64_t
   OWPexp_rand64(OWPrand_context *next)
   {
           unsigned long i, k;
           u_int32_t j = 0;
           u_int64_t U, V, J, tmp;

           /* Этап S1. Получение U и сдвиг */
           U = OWPunif_rand64(next);

           while ((U & BIT31) && (j < 32)) { /* Сдвиг до первого 0. */
                   U <<= 1;
                   j++;
           }
           /* Удаление 0. */
           U <<= 1;

           U = MASK32(U);  /* Сохранение дробной части. */
           J = OWPulong2num64(j);

           /* Этап S2. Принимается сразу? */
           if (U < LN2)       /* возврат (j*ln2 + U) */
                   return OWPnum64_add(OWPnum64_mul(J, LN2), U);

           /* Этап S3.  Минимизация. */
           for (k = 2; k < K; k++)
                   if (U < Q[k])
                           break;
           V = OWPunif_rand64(next);
           for (i = 2; i <= k; i++) {
                   tmp = OWPunif_rand64(next);
                   if (tmp < V)
                           V = tmp;
           }

           /* Этап S4. Возврат (j+V)*ln2 */
           return OWPnum64_mul(OWPnum64_add(J, V), LN2);
   }

Приложение B. Тестовые векторы

Важно, чтобы расписания тестов, создаваемые разными реализациями при дентичных входных данных, были идентичны. Нетривиальной задачей является генерация псевдослучайных переменных с экспоненциальным распределением. Чтобы помочь разработчикам в проверке совместимости, здесь представлено несколько тестовых векторов. Для каждого из приведенных 4 приведенных 128-битовых значения SID в шестнадцатеричном формате, генерируется 1 миллион 64-битовых переменных с экспоненциальным распределением, как описано выше. По мере генерации значения складываются и сумма всех 1 000 000 значений представляется в виде шестнадцатеричного числа для каждого SID. Реализации должны выдавать именно такие шестнадцатеричные числа. Чтобы помочь при проверке преобразования этих чисел в секунды задержки, приведены приблизительные значения (для lambda = 1). Реализациям следует выдавать число секунд, близкое к приведенным ниже значениям.

       SID = 0x2872979303ab47eeac028dab3829dab2
       SUM[1000000] = 0x000f4479bd317381 (1000569,739036 сек.)

       SID = 0x0102030405060708090a0b0c0d0e0f00
       SUM[1000000] = 0x000f433686466a62 (1000246,524512 сек.)

       SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
       SUM[1000000] = 0x000f416c8884d2d3 (999788,533277 сек.)

       SID = 0xfeed0feed1feed2feed3feed4feed5ab
       SUM[1000000] = 0x000f3f0b4b416ec8 (999179,293967 сек.)

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

Stanislav Shalunov

Internet2

1000 Oakbrook Drive, Suite 300

Ann Arbor, MI 48104

EMail: shalunov@internet2.edu

WWW: http://www.internet2.edu/~shalunov/

Benjamin Teitelbaum

Internet2

1000 Oakbrook Drive, Suite 300

Ann Arbor, MI 48104

EMail: ben@internet2.edu

WWW: http://people.internet2.edu/~ben/

Anatoly Karp

Computer Sciences Department

University of Wisconsin-Madison

Madison, WI 53706

EMail: akarp@cs.wisc.edu

Jeff W. Boote

Internet2

1000 Oakbrook Drive, Suite 300

Ann Arbor, MI 48104

EMail: boote@internet2.edu

Matthew J. Zekauskas

Internet2

1000 Oakbrook Drive, Suite 300

Ann Arbor, MI 48104

EMail: matt@internet2.edu


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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

1IP Performance Metrics — метрика производительности IP.

2Global positioning systems.

3Network Time Protocol — протокол сетевого времени.

4Man-in-the-middle — перехват и изменение пакетов с участием человека.

5Per-hop behavior.

6Simple Network Management Protocol — простой протокол сетевого управления.

7Segmentation and reassembly.

8Cipher Block Chaining — цепочка шифрованных блоков.

9Initialization Vector.

10MUST be zero — должно быть 0.

11Differentiated Services Codepoint — код дифференцированного обслуживания.

12PHB Identification Code — код идентификации PHB.

13Denial of service — отказ в обслуживании.

14Отметим, что исходящие сессии не требуют использования памяти.

15Transport Layer Security — защита на транспортном уровне.

16Key derivation function.

17Pseudo-random function.




RFC 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Network Working Group                                          J. Fenton
Request for Comments: 4686                           Cisco Systems, Inc.
Category: Informational                                   September 2006

Анализ угроз, связанных с протоколом DKIM

Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

В этом документе приводится анализ некоторых угроз для почтовой системы Internet, связанных с аутентификацией на основе подписей (signature-based mail authentication), в частности DKIM1. Обсуждается природа и местоположение отрицательных персонажей, их возможности и цели проведения атак.

Оглавление

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

1. Введение

Протокол DomainKeys Identified Mail (DKIM) был разработан группой IETF DKIM. Этот протокол определяет механизм, с помощью которого сообщения электронной почты подписываются с использованием криптографии. Наличие подписи домена в сообщении указывает на то, что домен принимает на себя ответственность за использование данного почтового адреса. Получатели могут проверить цифровую подпись, запрашивая подписавший сообщение домен напрямую для получения соответствующего открытого ключа, подтверждающего, что сообщение проверено владельцем закрытого ключа, подписавшего это сообщение домена. В этом документе рассматриваются угрозы, связанные с двумя еще незавершенными работами группы DKIM — спецификацией подписей DKIM [DKIM-BASE] и практическими рекомендациями по подписанию сообщений отправителем [DKIM-SSP].

После того, как подтверждение получено, принимающая сторона может оценить сообщение с использованием дополнительных методов таких, как локально поддерживаемые «белые списки», проверенные службы общего пользования и/или гарантии третьей стороны. Описание таких механизмов не входит в число задач рабочей группы IETF DKIM. Ставя подпись, легитимные отправители дают проверяющему возможность связать с этим сообщением позитивную репутацию в надежде, что она будет подобающим образом трактоваться получателем.

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

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

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

Адрес отправителя (origin address) представляет собой адрес в почтовом сообщении, который обычно имеет формат RFC 2822 From:, — адрес, связываемый с заявленным автором сообщения и выводимый пользовательским почтовым агентом (MUA3), как адрес источника сообщения.

                 +---------------------------------+
                 |       Создание подписи          |
                 | (исходная или транслирующая AU) |
                 |                                 |
                 |   Sign (Message, Domain, Key)   |
                 |                                 |
                 +---------------------------------+
                                  | - Message (Domain, Key)
                                  |
                              [Internet]
                                  |
                                  V
                 +---------------------------------+
+-----------+    |     Проверка подписи            |
|           |    |(транслирующ. или доставляющ. AU)|
|  Запрос   |    |                                 |
|  ключа    +--->|  Verify (Message, Domain, Key)  |
|           |    |                                 |
+-----------+    +----------------+----------------+
                                  |  - Проверенный домен
+-----------+                     V  - [Отчет]
| Запрос    |    +----------------+----------------+
| практики  |    |                                 |
| подписыв. +--->|    Оценка подписывающего        |
| у отправ. |    |                                 |
|           |    +---------------------------------+
+-----------+


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

DKIM полностью работает в контексте со-общения (тело и некоторые поля заголовка), как определено в RFC 2822 [RFC2822]. Передача сообщения по протоколу SMTP определена в RFC 2821 [RFC2821] и такие элементы, как адреса envelope-from и envelope-to, а также домен HELO не имеют отношения к верификации DKIM. По специальному решению для верификации сообщений могут использоваться протоколы, отличные от SMTP, — такие, как POP [RFC1939] и IMAP [RFC3501], которые может использовать агент MUA, являющийся проверяющей стороной.

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

1.2. Структура документа

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

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

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

Влияние

Сильное: воздействие на верификацию сообщений из целого домена или множества доменов.

Среднее: воздействие на верификацию сообщений от отдельных пользователей, агентов MTA6 и/или в течение ограниченного интервала времени.

Слабое: воздействие лишь на верификацию отдельных сообщений.

Вероятность

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

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

Низкая: атаки предполагаются редкими.

2. Отрицательные персонажи

2.1. Характеристики

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

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

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

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

2.2. Возможности

В общем случае следует ожидать, что перечисленные выше отрицательные персонажи имеют доступ:

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

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

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

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

  1. подавать сообщения агентам MTA и MSA7 во множестве точек Internet;

  2. создавать произвольные поля заголовков, включая те, которые используются списками рассылки, средствами пересылки (resender) и другими почтовыми агентами;

  3. подписывать сообщения от имени доменов, находящихся под их контролем;

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

  5. заново отправлять (resend) сообщения, которые ранее были подписаны доменом;

  6. передавать сообщения с использованием в конверте (envelope) любой желаемой информации;

  7. действовать в качестве уполномоченного агента подачи сообщений (authorized submitter0 на захваченных компьютерах;

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

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

  2. ограниченное влияние на часть системы DNS с использованием таких механизмов, как “отравление” кэша (cache poisoning); это может служить для воздействия на маршрутизацию сообщений и фальсификации анонсов основанных на DNS ключей или практики подписывания сообщений;

  3. доступ к значительным компьютерным ресурсам (например, путем создания крупных сетей специально инфицированных компьютеров — зомби), которые могут позволять организацию атак методом грубой силы ((brute-force attack);

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

Любой из двух первых механизмов может использоваться для того, чтобы отрицательные персонажи могли организовать атаки с участием человека (man-in-the-middle) на пути от отправителя к получателю, если такая атка потребуется.

2.3. Местоположение

Отрицательные персонажи или их посредники (proxy) могут располагаться в любой части сети Internet. Некоторые атаки, возможные прежде всего в пределах административной единицы домена заявленного источника и/или получателя, предоставляют отрицательным персонажам возможности, не доступные в других условиях, как описано ниже. Отрицательные персонажи могут также сговариваться между собой, действуя из множества мест (“распределенный отрицательный персонаж”).

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

2.3.1. Внешние отрицательные персонажи

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

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

2.3.2. Внутри административной единицы заявленного источника

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

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

2.3.3. Внутри административной единицы получателя

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

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

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

3. Примеры негативных действий

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

3.1. Использование подложной идентификации отправителя

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

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

3.2. Использование конкретной идентификации

Вторым из основных классов негативных действий является указание в сообщениях конкретной идентификации.

Отметим, что некоторые из негативных действий, включающих конкретную идентификацию, могут совершенствоваться (хотя иной раз и со сниженной эффективностью) путем использования похожих внешне идентификаторов, которые могут обмануть некоторых получателей. Например, если отрицательный персонаж может контролировать домен examp1e.com (между буквами p и e находится цифра 1), он может убедить некоторых получателей, что сообщение с адреса admin@examp1e.com реально отправлено с адреса admin@example.com. Подобные типы атак с использованием символов других языков могут оказаться весьма затруднительными в силу одинакового написания части символов в распространенных шрифтах. Подобно сказанному выше, если отрицательный персонаж контролирует домен example2.com, он может подписывать сообщения от bigbank.example2.com, способные ввести в заблуждение некоторых получателей. DKIM не обеспечивает защиты от таких атак, хотя этот протокол поддерживает возможность использования систем аккредитации и/или учета репутации, помогающих пользователю идентифицировать эти атаки.

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

3.2.1. Использование социальных аспектов

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

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

3.2.2. Связанное с идентификацией мошенничество

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

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

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

3.2.3. Атаки на репутацию

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

3.2.4. Атаки с отражением

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

DKIM в общем случае не пытается проверить корректность адреса возврата RFC2821.mailfrom в сообщениях, указанного непосредственно (отметим, что адрес mailfrom является элементом протокола SMTP, а не сообщения, с которым работает DKIM), или в необязательном поле заголовка Return-Path. Более того, как отмечено в параграфе 4.4 документа RFC 2821 [RFC2821], допустимо и рекомендуется указывать в сообщения различные адреса в поле отправителя и поле возврата. По этой причине DKIM не обеспечивает защиты против атак с отражением.

4. Атаки на системы подписывания сообщений

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

4.1. Атаки против сигнатур в сообщениях

Ниже приведен список предполагаемых атак, нацеленных на сигнатуры DKIM.

 

Название

Влияние

Вероятность

Кража секретных ключей домена

Сильное

Низкая

Кража делегированных секретных ключей

Среднее

Средняя

Восстановление секретных ключей путем атаки на канал

Сильное

Низкая

Повтор избранных сообщений

Слабое

Средняя/высокая

Повтор подписанных сообщений

Слабое

Высокая

DoS-атаки на проверяющих

Сильное

Средняя

DoS-атаки на службы ключей

Сильное

Средняя

Злоупотребление канонизацией имен

Слабое

Средняя

Злоупотребление размером сообщения

Среднее

Средняя

Использование вышедших из употребления ключей

Среднее

Низкая

Захват серверов ключей

Сильное

Низкая

Фальсификация откликов службы ключей

Среднее

Средняя

Публикация некорректно сформированных ключей и подписей

Сильное

Низкая

Криптографическая слабость генерации подписей

Сильное

Низкая

Злоупотребление отображаемыми именами

Среднее

Низкая

Захваченные системы в сети отправителя

Сильное

Средняя

Атаки с пробной верификацией

Среднее

Средняя

Публикация ключей доменом верхнего уровня

Сильное

Низкая

 

4.1.1. Кража секретных ключей домена

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

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

4.1.2. Кража делегированных секретных ключей

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

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

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

4.1.3. Восстановление секретных ключей путем атаки на канал

Все популярные алгоритмы создания цифровых подписей являются объектами широкого спектра атак на каналы передачи. К наиболее распространенным относятся Timing Attack [Kocher96], Differential Power Analysis [Kocher99] и Cache Timing Attack [Bernstein04]. Большинство таких атак требует физического доступа к машине или возможности запуска процессов непосредственно на целевой машине (адресат). Защита от таких атак не входит в задачи DKIM.

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

Ниже перечислены три наиболее распространенных меры против временного анализа.

  1. Сделать операции используемыми в фиксированное время. На практике это может оказаться достаточно сложным.

  2. Сделать время независимым от входных данных. Это может оказаться сложнее, но в работе [Boneh03] приведены детальные рекомендации.

  3. Использовать «затемнение». Эта мера обычно считается наиболее практичной и, хотя и не обеспечивает общей защиты, является мерой против Timing-атак. Использование этого метода на 2-10% повышает стоимость операций, а сам метод реализован в большинстве современных криптографических библиотек. К сожалению алгоритмы DSA11 и ECDSA12 не имеют стандартных методов, хотя некоторые средства защиты могут поддерживаться.

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

4.1.4. Повтор избранных сообщений

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

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

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

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

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

Требуется дополнительное исследование для сравнения преимуществ отзыва (на основе возможной скорости replay-атак) и издержек на запросы к базе данных об отзывах.

4.1.5. Повтор подписанных сообщений

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

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

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

4.1.6. DoS-атаки на проверяющих

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

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

4.1.7. DoS-атаки на службы ключей

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

Лучшей защитой от таких атак является наличие избыточных серверов ключей, предпочтительно в разнесенных географически частях Internet. Кэширование также сильно помогает, снижая нагрузку на полномочные серверы ключей при наличии множества одновременных запросов. Предпочтительно также использовать протокол обслуживания ключей, минимизирующий «стоимость» транзакции поиска ключа. Отмечено, что такими своствами обладает система доменных имен DNS (Domain Name System).

4.1.8. Злоупотребление канонизацией имен

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

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

4.1.9. Злоупотребление размером сообщения

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

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

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

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

4.1.10. Использование вышедших из употребления ключей

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

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

4.1.11. Захват серверов ключей

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

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

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

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

4.1.12. Фальсификация откликов службы ключей

Отклики службы ключей атакующий с подходящим местоположением может подделать. Для DNS одним из способов является «отравление кэша» (cache poisoning), когда атакующий предоставляет ненужную (и неверную) дополнительную информацию в отклики DNS и эта информация кэшируется.

DNSSEC [RFC4033] является предпочтительным способом смягчения этой угрозы, но скорость внедрения DNSSEC достаточно мала, поэтому не хотелось бы попадать в зависимость от развертывания этой системы. В случае атаки с отравлением кэша создаваемые уязвимости локализованы и имеют ограниченную длительность, хотя записи со сравнительно большим значением TTL могут сохраняться за пределами самой атаки.

4.1.13. Публикация некорректно сформированных ключей и подписей

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

4.1.14. Криптографическая слабость генерации подписей

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

Одним из следствий слабости алгоритма хэширования являются атаки с конфликтом хэш-значений. Такие атаки на систему подписи включают человека, создающего два разных сообщения с совпадающими хэш-значениями, из которых нормальным способом подписывается лишь одно сообщение. Атака основана на втором сообщении, наследующем подпись первого. Для DKIM это означает, что отправитель может создать «хорошее» и «плохое», а некий фильтр на подписывающей стороне будет подписывать хорошее сообщение, а не плохое. Атакующий получает подписанное хорошее сообщение и помещает его подпись в плохое сообщение. Этот вариант не распространен, но может встречаться, например, на сайте, где содержимое анализируется сообщений перед их подписыванием.

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

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

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

4.1.15. Злоупотребление отображаемыми именами

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

   From: "Dudley DoRight" <whiplash@example.org>

В этом примере атакующий whiplash@example.org может подписать сообщение и все же убедить некоторых получателей, что его отправил Dudley DoRight, которому получатель доверяет. При использовании «мусорных» доменов и/или адресов привлечь атакующего к ответственности за указание чужого имени может быть сложно.

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

4.1.16. Захваченные системы в сети отправителя

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

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

4.1.17. Атаки с пробной верификацией

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

Одна из таких атак, которую назовем «пробой проверки» (verification probe) заключается в отправке сообщения с подписью DKIM по каждому из множества адресов в списке рассылки. Сообщениям не нужны действительные подписи и каждый экземпляр обычно будет использовать свой селектор. Затем атакующий может отследить запросы к службе ключей и определить, какие селекторы были запрашивались и, соответственно, для каких адресатов использовалась проверка DKIM. Это может использоваться для нацеливания будущих сообщений получателям, которые не применяют проверку DKIM, при условии, что эти адресаты с высокой вероятностью будут влиять на содержимое сообщения.

4.1.18. Публикация ключей доменом верхнего уровня

Для поддержки способности домена подписывать субдомены, административно контролируемые им, DKIM разрешает домены подписей (тег d=) быть доменом более высокого уровня, нежели подписываемый адрес (i= или эквивалент). Однако по причине отсутствия механизма определения общего административного контроля над субдоменом, родитель может публиковать ключи, которые действительны для любого домена, расположенного ниже в иерархии DNS. Иными словами, почта из домена example.anytown.ny.us может быть подписана с использованием ключей доменов anytown.ny.us, ny.us или us в дополнение к ключам самого домена.

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

4.2. Атаки на методы подписывания сообщений

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

Название атаки

Степень воздейстия

Вероятность

Похожие имена доменов

Высокая

Высокая

Неправомерное использование доменных имен на других языках

Высокая

Высокая

Атака на отказ в обслуживании при подписи

Средняя

Средняя

Использование множества адресов From:

Слабая

Средняя

Неправомерное использование подписей третьей стороны

Средняя

Высокая

Фальсификация откликов SSP13

Средняя

Средняя

4.2.1. Похожие имена доменов

Атакующие могут попытаться обойти методы подписания в домене, используя имя, близкое по написанию к имени домена, но отличающееся от имени домена подписи (например, заменить example.com на examp1e.com). Если сообщение не должно быть подписано, DKIM не будет требовать реального существования домена (хотя это могут требовать другие механизмы). Существуют службы мониторинга регистрации доменов для обнаружения возможных злоупотреблений именами, но они не могут заметить использование незарегистрированных доменных имен.

Похожие атаки возможны в тех случаях, когда MUA не выводит имя домена в легко узнаваемом формате. Если, например, китайский домен отображается в punycode как xn--cjsp26b3obxw7f.com, его легко подменить другим столь же малопонятным доменным именем.

Пользователи, не знакомые с соглашениями об именовании доменов в Internet, также могут ошибаться при восприятии некоторых имен. Например, они могут спутать online.example.com и online-example.com.

4.2.2. Неправомерное использование доменных имен на других языках

Интернационализация доменных имен открывает возможность для дополнительных атак с использованием схожих имен, как описано выше. Внешнее сходство многих символов Unicode позволяет создавать домена, имена которых в текстовом представлении будут неотличимы (особенно при использовании символов из разных групп) от других, возможно, более значимых имен. Этот вопрос подробно рассмотрен в Unicode Technical Report 36 [UTR36].

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

4.2.3. Атака на отказ в обслуживании при подписи

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

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

4.2.4. Использование множества адресов отправителя

Хотя большинство получателей никогда с этим не сталкивается, RFC 2822 [RFC2822] позволяет указывать в поле From: множество спецификаций адресов. Поиск SSP основан на адресах From:, поэтому при наличии здесь адресов из разных доменов возникает вопрос о выборе методов подписания. Можно задать правило (например, использовать первый адрес), но тогда атакующий может указать «проходной» (одноразовый) адрес перед адресом значимого домена. SSP может просматривать все адреса и выбирать правило с максимальными ограничениями, но это требует дальнейшего изучения.

4.2.5. Неправомерное использование чужих подписей

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

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

4.2.6. Фальсификация откликов SSP

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

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

4.3. Прочие атаки

В этом параграфе рассмотрена другая атака на инфраструктуру Internet, которая возможна при развертывании DKIM.

Название атаки

Степень воздейстия

Вероятность

«Усиление» пакетов через DNS

Средняя

4.3.1. Атаки с усилением через DNS

В последнее время возросло число атак на отказ в обслуживании, включающих передачу фиктивных запросов UDP DNS к открытым для доступа серверам доменных имен [US-CERT-DNS]. Если отклик от сервера имен по размеру превышает запрос, сервер имен позволяет усилить такую атаку.

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

5. Производные требования

Здесь приведены требования к DKIM, не указанные в явной форме выше. Эти требования включают:

  • хранилище ключей и записей SSP должно поддерживать территориально распределенные серверы;

  • записи ключей и SSP должны быть кэшируемыми проверяющей стороной или иной инфраструктурой;

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

  • идентификатор алгоритма подписи в сообщении должен быть указан в записи ключа для домена;

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

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

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

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

[Bernstein04] Bernstein, D., «Cache Timing Attacks on AES», April 2004.

[Boneh03] Boneh, D. and D. Brumley, «Remote Timing Attacks are Practical», Proc. 12th USENIX Security Symposium, 2003.

[DKIM-BASE] Allman, E., «DomainKeys Identified Mail (DKIM) Signatures», Work in Progress, August 2006.

[DKIM-SSP] Allman, E., «DKIM Sender Signing Practices», Work in Progress, August 2006.

[Kocher96] Kocher, P., «Timing Attacks on Implementations of Diffie-Hellman, RSA, and other Cryptosystems», Advances in Cryptology, pages 104-113, 1996.

[Kocher99] Kocher, P., Joffe, J., and B. Yun, «Differential Power Analysis: Leaking Secrets», Crypto ’99, pages 388-397, 1999.

[RFC1939] Myers, J. and M. Rose, «Post Office Protocol — Version 3», STD 53, RFC 1939, May 1996.

[RFC2821] Klensin, J., «Simple Mail Transfer Protocol», RFC 282114, April 2001.

[RFC2822] Resnick, P., «Internet Message Format», RFC 282215, April 2001.

[RFC3501] Crispin, M., «INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1», RFC 3501, March 2003.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[US-CERT-DNS] US-CERT, «The Continuing Denial of Service Threat Posed by DNS Recursion».

[UTR36] Davis, M. and M. Suignard, «Unicode Technical Report #36: Unicode Security Considerations», UTR 36, July 2005.

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

Автор благодарит Phillip Hallam-Baker, Eliot Lear, Tony Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla, Paul Hoffman, Hector Santos и множество других участников почтовой конференции ietf-dkim за полезные предложения и конструктивную критику ранних версий документа.

Адрес автора

Jim Fenton

Cisco Systems, Inc.

MS SJ-9/2

170 W. Tasman Drive

San Jose, CA 95134-1706

USA

Phone: +1 408 526 5914

EMail: fenton@cisco.com

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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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

1DomainKeys Identified Mail.

2Administrative unit.

3Mail User Agent.

4Sender Signing Practices Query.

5Sender Signing Practices

6Mail Transfer Agent — агент передачи почты.

7Message Submission Agent — агент подачи сообщений.

8Mail Delivery Agent

9Происходит от имени Joe Doll — владельца службы Joe’s CyberPost, которая одной из первых столкнулась с крупномасштабной акцией описанного здесь типа. См. также http://www.joes.com/spammed.html. Прим. перев.

10Отсутствует физический доступ персонала. Прим. перев.

11Digital Signature Algorithm — алгоритм цифровой подписи.

12Elliptic Curve DSA

13Sender Signing Practices — практика подписания в домене.

14Заменен RFC 5321. Прим. перев.

15Заменен RFC 5322. Прим. перев.




RFC 4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks

Network Working Group                                   W. Augustyn, Ed.
Request for Comments: 4665                               Y. Serbest, Ed.
Category: Informational                                             AT&T
                                                          September 2006

Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks

Требования к предоставляемым провайдерами услугам L2VPN

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

Этот документ описывает требования для предоставляемых провайдерами услуг виртуальных частных сетей канального уровня (L2VPN1). Здесь впервые определены терминология и систематика, а также заданы общие и базовые требования к сервису. Документ охватывает VPN типа «точка-точка», называемые VPWS2, а также многоточечные VPN, называемые VPLS3. Требования детализированы и выражены с точки зрения абонентов и сервис-провайдеров.

Оглавление

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

1. Введение

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

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

Этот документ описывает требования к предоставляемым провайдером услугам L2VPN. Документ определяет требования, которые могут применяться к одному или нескольким подходам, которые SP4 может применять для предоставления услуг L2 VPN. В документе используется терминология, определенная в [RFC4026], и базовые компоненты развертывания L2VPN, описанные в [RFC4664].

Технические спецификации для предоставления услуг L2VPN выходят за рамки этого документа. Эти вопросы рассматриваются в базовом документе [RFC4664] и нескольких других документах, описывающих технические аспекты предоставления услуг L2VPN, — [VPLS_LDP], [VPLS_BGP], [IPLS].

Документ описывает требования к двум типам L2VPN: (1) услуги виртуальных частных проводов (VPWS) и (2) услуги виртуальных частных ЛВС (VPLS). Подход, используемый в этом документе, различает типы L2VPN по способам организации соединений («точка-точка» или многоточечные), как описано в [RFC4664].

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

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

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

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

1.2. Структура документа

В разделе 4 приведены определения и систематика типов сервиса. В разделе 5 описаны общие требования, применимые к абоненты и SP, раздел 6 представляет требования с точки зрения абонента, а раздел 7 — с точки зрения SP. В разделе 8 рассматриваются требования к управлению SP, в разделе 9 описаны инженерные требования, в частности, для уровней данных и управления. Раздел 10 посвящен вопросам безопасности, в разделе 11 приведены благодарности, а в разделе 12 — список литературы.

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

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

3. Участники работы

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

Waldemar Augustyn
Marco Carugi
Giles Heron
Vach Kompella
Marc Lasserre
Pascal Menezes
Hamid Ould-Brahim
Tissa Senevirathne
Yetik Serbest

4. Определения и систематика

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

Используемая в документе терминология определена в [RFC4026]. Базовый документ L2VPN [RFC4664] содержит описание концепций в контексте эталонной модели, определяющей многоуровневые соотношения между устройствами и одним или несколькими уровнями туннелирования.

4.2. Систематика типов L2VPN

Требования различают две основных модели L2VPN — виртуальные провода VPWS и виртуальные сети VPLS.

На рисунке 1 представлена эталонная модель сервиса L2VPN.

+-----+                                       +-----+
+ CE1 +--+                                +---| CE2 |
+-----+  |    ........................    |   +-----+
L2VPN A  |  +----+                +----+  |   L2VPN A
         +--| PE |--- Опорная  ---| PE |--+
            +----+      сеть      +----+
           /  .      провайдера      .  \     -   /\-_
+-----+   /   .          |           .   \   / \ /   \     +-----+
+ CE4 +--+    .          |           .    +--\  Сеть  \----| CE5 |
+-----+       .        +----+        .       | доступа |   +-----+
L2VPN B       .........| PE |.........        \       /    L2VPN B
                       +----+     ^            -------
                         |        |
                         |        |
                      +-----+     |
                      | CE3 |     +-- Экземпляр логического коммутатора
                      +-----+
                      L2VPN A

Рисунок 1. Эталонная модель L2VPN.


4.3. VPWS

Устройства PE обеспечивают логическое соединение между парой устройств CE, как будто они соединены одним логическим устройством L2. Устройства PE действуют как коммутаторы устройств (каналов) L2. Затем устройства L2 отображаются на туннели в сети SP. Эти туннели могут использоваться для конкретного экземпляра VPWS или быть общими для нескольких услуг. Сервис VPWS применим для Ethernet, ATM, Frame Relay и т. п. На рисунке 1 сеть L2VPN B представляет собой VPWS.

Каждое устройство PE отвечает за направление абонентских кадров L2 подходящему экземпляру VPWS и корректную пересылку заданному получателю.

4.4. VPLS

В случае VPLS устройства PE обеспечивают логические соединения так, что устройства CE, относящиеся к одной сети VPLS, представляются подключенными к одной ЛВС. Сквозной сервис VPLS включает модуль моста и модуль эмуляции ЛВС ([RFC4664]). VPLS может включать одну или множество сетей VLAN([IEEE_802.1Q]). Вариантом этого сервиса является IPLS ([RFC4664]), где поддерживается лишь абонентский трафик IP.

В VPLS абонентский сайт получает обслуживание L2 от SP. Устройство PE подключается через каналы доступа к одному или множеству CE. PE выполняет пересылку пользовательских пакетов данных на основе информации в заголовках L2, таклй как MAC-адрес получателя. На рисунке 1 сеть представляет L2VPN A сервис VPLS.

Детали рассматриваемой здесь эталонной модели описаны в [RFC4664]. В VPLS устройство PE можно рассматривать как содержащее экземпляр виртуального коммутатора (VSI9) для каждого поддерживаемого устройством сервиса L2VPN. Устройства CE подключаются (возможно, через сеть доступа) к модулю моста в PE. Внутри PE модуль моста соединяется через интерфейс эмулируемой ЛВС (Emulated LAN Interface) с эмулируемой ЛВС. Для каждого сервиса VPLS имеется экземпляр эмулируемой ЛВС. Emulated LAN состоит из модуля пересылки — VPLS Forwarder (один экземпляр на PE на сервис VPLS), подключенного псевдопроводом (PW10), который может проходить через туннели в сети пакетной коммутации (PSN11) по маршрутизируемой магистрали. VSI — это логический объект, содержащий модуль пересылки VPLS и часть модуля моста, отнсящуюся к экземпляру сервиса VPLS [RFC4664]. Следовательно VSI завершает PW для соединения с другими VSI, а также завершает устройства (каналы) присоединения — AC12 (см. определение в [RFC3985]) для подключения устройств CE. VSI включает базы данных пересылки для L2VPN [RFC4664], которая представляет собой набор данных, определяющих пересылку кадров L2, принятых через AC от CE для VSI в других PE, поддерживающих тот же сервис L2VPN (и/или для других AC), а также данные для пересылки кадров L2, принятых из PW для устройств AC. Базы данных пересылки могут заполняться динамически (например, путем изучения MAC-адресов) или статически (например, в конфигурации). Каждое устройство PE отвечает за корректную пересылку абонентского трафика заданным получателям на основе базы данных пересылки соответствующего VSI.

5. Общие требования для абонента и сервис-провайдера

В этом разделе описаны общие требования для абонентов и провайдеров или те, что имеют общую природу.

5.1. Область действия эмуляции

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

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

  • Надежность может снижаться, т. е. вероятность того, что широковещательное сообщение через VPLS не будет замечено одним из модулей моста в PE выше, чем в реальной сети Ethernet.

  • Кадры VPLS могут дублироваться, если в PW не включена опция упорядочения. Кадры данных передаются через PW в виде дейтаграмм IP и при некоторых отказах сети IP могут дублировать пакеты. Если протокол передачи данных в PW не гарантирует порядка пакетов, кадры могут дублироваться ил приниматься в нарушением порядка. Если абонентские кадры BPDU13 передаются как пакеты данных, они могут дублироваться и последовательность BPDU может нарушаться, хотя это может и не создавать проблем для протокола RSTP14.

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

  • Кадры 802.3x Pause не будут передаваться через VPLS, поскольку модули мостов ([RFC4664]) будут останавливать их.

  • Поскольку решение IPLS нацелено на транспортировку инкапсулированного трафика (а не самих кадров L2), оно не требует сохранения заголовков L2 на пути от CE к CE. Например, адреса Source MAC могут не сохраняться в IPLS.

5.2. Типы трафика

Сеть VPLS должна поддерживать индивидуальный, групповой и широковещательный трафик. Весьма желательна поддержка эффективной репликации для группового и широковещательного трафика.

5.3. Топология

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

  • «точка-точка» (Point-to-point);

  • «один со многими» (Point-to-multipoint) или «звезда» (hub and spoke — концентратор и лучи);

  • «каждый с каждым» (Any-to-any) или полносвязная (full mesh);

  • смешанная или частично полносвязная (partial mesh);

  • иерархическая.

Независимо от развернутой SP топологии сервис для абонентов должен сохранять тип соединений, предполагаемый решением L2VPN. Например, в VPLS должны поддерживаться многоточечные (multipoint-to-multipoint) соединения даже при реализации на каналах «точка-точка». Это требование не предполагает, что все характеристики трафика (такие как пропускная способность, QoS, задержки и т. п.) обязательно одинаковы между любой парой конечных точек L2VPN. Важно подчеркнуть, что требования SLS для сервиса связаны с типом топологии, которая может применяться.

Насколько это возможно, сервису L2VPN следует поддерживать работу через административные границы.

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

5.4. Изолированный обмен данными и информацией о пересылке

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

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

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

Внутреннюю структуру L2VPN не следует анонсировать за пределы L2VPN.

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

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

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

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

  • Протокольные атаки:

    • организация/удаление избыточных отношений смежности;

    • избыточная сигнализация/отзыв.

  • Расход ресурсов:

    • репликация на уровне пересылки (VPLS);

    • петли (в основном VPLS);

    • размер таблицы MAC (VPLS).

  • Несанкционированный доступ:

    • неразрешенные участники VPN;

    • некорректный абонентский интерфейс;

    • некорректный тег VLAN для обозначения сервиса;

    • несанкционированный доступ к PE.

  • Вмешательство в сигнализацию:

    • некорректная сигнализация FEC;

    • некорректное назначение метки PW;

    • передача некорректных параметров VPN (например, QoS, MTU и пр.).

  • Вмешательство в пересылку данных:

    • некорректные записи изучения MAC;

    • некорректные метки PW;

    • некорректные идентификаторы AC;

    • некорректная инкапсуляция в сторону абонента;

    • некорректная инкапсуляция PW

    • перехват PW путем использования ложных туннелей;

    • некорректная туннельная инкапсуляция.

5.5.1. Безопасность пользовательских данных

Решение L2VPN должно обеспечивать разделение трафика разных L2VPN.

В случае VPLS для указания сервиса могут применяться идентификаторы VLAN. В таких случаях должно обеспечиваться аккуратное выделение тегов и разделение трафика.

5.5.2. Контроль доступа

Решение L2VPN может позволять использование подходящих средств фильтрации по запросу абонента.

5.6. Адресация

Решение L2VPN должно поддерживать использование перекрывающихся блоков адресов а разных L2VPN. Например, недопустимо препятствовать использованию абонентом одних MAC-адресов в разных L2VPN. Если сервис-провайдер использует теги VLAN для обозначения сервиса, решение L2VPN должно гарантировать отсутствие совпадений тегов VLAN. Если теги VLAN не применяются для обозначения сервиса, решения L2VPN могут разрешать совпадение тегов.

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

По-возможности, для L2VPN QoS следует обеспечивать независимость от технологии сетей доступа.

5.7.1. Стандарты QoS

Как указано в [RFC3809], L2VPN нужно поддерживать QoS15 в одном или нескольких стандартизованных режимах:

  • Best Effort (поддержка обязательна для всех типов предосатвляемых провайдером VPN);

  • Aggregate CE Interface Level QoS (уровень «шланга»);

  • Site-to-site QoS (уровень «трубы»).

Отметим, что во всех случаях использования QoS может потребоваться выполнение функций «формовки» и политики от устройств CE и/или PE.

Отображение и трансляция параметров L2 QoS на PSN QoS (например, DSCP or или поле MPLS EXP ), а также отображение QoS на основе VC (например, FR/ATM или VLAN) может выполняться для обеспечения «прозрачности» QoS. Реальные механизмы такого отображения или трансляции выходят за рамки этого документа. В дополнение к этому может применяться поддержка Diffserv базовыми технологиями туннелирования (например, [RFC3270] или [RFC3308]) и модель Intserv ([RFC2205]). Поэтому требования L2VPN SLS следует поддерживать подходящими механизмами в ядре сети.

5.7.2. Модели сервиса

Сервис-провайдер может предложить абонентам по меньшей мере базовые услуги QoS — управляемый доступ к услугам VPN или сквозной сервис QoS. Детали моделей сервиса приведены в [RFC3809] и [RFC4031].

В L2VPN для этих целей могут применяться поля DSCP ([RFC2474]) и 802.1p ([IEEE_802.1D]).

5.8. Спецификация уровня сервиса

Для сервиса L2VPN следует поддерживать возможности мониторинга и уведомлений для SLS [RFC3809].

5.9. Защита и восстановление

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

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

5.10. Требования к каналам CE-PE и PE-PE

В качестве каналов между CE и PE могут применяться:

  • прямые физические соединения (например, 100BaseTX, T1/E1 TDM);

  • логические каналы (например, ATM PVC, каналы с инкапсуляцией RFC2427);

  • транспортные сети Ethernet;

  • туннели L2 через сети L3 (например, сессии L2TP).

Кадры L2 могут туннелироваться через магистрали L3 от PE к PE с использованием подходящего протокола (например, IP-in-IP, GRE, MPLS, L2TP и т. п.).

5.11. Управление

Должны обеспечиваться стандартные интерфейсы для управления услугами L2VPN (например, модули SNMP MIB). Этим интерфейсам следует предоставлять доступ к протоколам настройки, верификации и мониторинга работы.

Управление сервисом может включать функциональность TMN FCAPS16, описанную в [ITU_Y.1311.1].

5.12. Совместимость

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

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

Решениям L2VPN недопустимо препятствовать использованию разных технологий доступа.

Например, абонентские подключения для доступа к сервису L2VPN могут быть разными на различных устройствах CE (например, Frame Relay, ATM, 802.1D, MPLS).

5.13. Взаимодействие

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

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

6. Абонентские требования

В этом разделе рассматриваются требования с точки зрения абонентов.

6.1. Независимость от SP

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

Абонент может начать с сервиса L2VPN в одной AS с той или иной спецификацией SLS, а затем запросить расширение сервиса на множество AS и/или SP. В этом случае, а также в других вариантов межпровайдерских и многодоменных (AS) услуг L2VPN, сервису L2VPN следует поддерживать возможность обеспечения одной спецификации SLS для всех сайтов VPN независимо от AS/SP, к которым они подключены.

6.2. Поддержка L3

За исключением IPLS, услугам L2VPN следует независимыми от типа абонентского трафика L3 (например, IP, IPX, Appletalk), инкапсулированного в кадры L2.

В IPLS должна обеспечиваться поддержка абонентского трафика IPv4 и IPv6, инкапсулированного в кадры L2. В IPLS следует также обеспечивать «прозрачную» передачу трафика ISIS и MPLS между CE, когда он используется с IP.

6.3. Качество обслуживания и параметры трафика

Предполагается QoS является важным параметром сервиса L2VPN для некоторых абонентов.

Абонентам нужно, чтобы служба L2VPN обеспечивала параметры QoS, подходящие для приложений, которые могут занимать диапазон от PW (например, эмуляция SONET) до голоса, интерактивного видео и multimedia-приложений. Поэтому сервис L2VPN должен поддерживать режим best-effort, а также чувствительный к задержкам и потерям трафик. Абонентским приложениям следует обеспечивать согласованные параметры QoS независимо от технологии сетей доступа на разных сайтах одной сети L2VPN.

6.4. Спецификация уровня сервиса

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

Следует предоставлять стандартные интерфейсы для мониторинга L2VPN (например, модули SNMP MIB).

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

6.5.1. Изоляция

Решение L2VPN должно обеспечивать изоляцию трафика а также данных пересылки для абонентов, как это делается на частных каналах, а также в сетях FR и ATM.

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

6.5.2. Контроль доступа

Решение L2VPN может включать механизмы фильтрации по запросу абонента. Например, может применяться фильтрация по MAC-адресам и/или тегам VLAN между устройствами CE и PE в VPLS.

6.5.3. Добавленные услуги защиты

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

Службам L2VPN недопустимо конфликтовать с механизмами защиты, развернутыми абонентами на уровне L3 и выше. Механизмы защиты L2, такие как 802.10b ([IEEE_802.10]) и 802.1AE ([IEEE_802.1AE]) могут мешать службам L2VPN, когда указывающие сервис теги VLAN оказываются зашифрованными.

6.6. Доступ в сеть

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

6.6.1. Технология физического и канального уровня

Решениям L2VPN следует поддерживать широкий диапазон технологий доступа на физическом и канальном уровне, таких как PSTN, ISDN, xDSL, кабельные модемы, арендованные линии, Ethernet, Ethernet VLAN, ATM, Frame Relay, беспроводные сети, сети сотовой связи и т. п. Пропускная способность и QoS могут зависеть от применяемой технологии.

6.6.2. Подключения для доступа

Должны поддерживаться разные варианты физического подключения, такие как многодомные сайты, «закулисные» (backdoor) соединения между сайтами, устройства подключенные к нескольким сетям SP. В случае VPLS следует поддерживать агрегирование каналов IEEE 802.3ad-2000. Решениям L2VPN следует поддерживать по меньшей мере подключения физического и канального уровня, показанные на рисунках 2 — 4 (в дополнение к рисунку 1). Как показано на рисунке 2, CE может иметь два подключения к одному или разным SP через разные сети доступа.

                +----------------                    +---------------
                |                                    |
             +------+                            +------+
   +---------| Устр.|                  +---------| Устр.|
   |         |  PE  |                  |         |  PE  |  Сеть SP
   |         +------+                  |         +------+
+------+         |                  +------+         |
| Устр.|         |                  | Устр.|         +---------------
|  CE  |         |   Сеть SP        |  CE  |         +---------------
+------+         |                  +------+         |
   |         +------+                  |         +------+
   |         | Устр.|                  |         | Устр.|
   +---------|  PE  |                  +---------|  PE  |  Сеть SP
             +------+                            +------+
                 |                                   |
                 +----------------                   +---------------
                (a)                                 (b)

Рисунок 2. Двудомный доступ устройств CE.


Отказоустойчивость сервиса L2VPN может быть повышена дополнительно, как показано на рисунке 3, где устройства CE имеют «закулисное» соединение через одного или разных SP.

                 +----------------                  +---------------
                 |                                  |
+------+     +------+               +------+     +------+
| Устр.|-----| Устр.|               | Устр.|-----| Устр.|
|  CE  |     |  PE  |               |  CE  |     |  PE  |  Сеть SP
+------+     +------+               +------+     +------+
   |             |                     |             |
   | «Закулисный»|                     | «Закулисный»+---------------
   | канал       |   Сеть SP           | канал       +---------------
   |             |                     |             |
+------+     +------+               +------+     +------+
| Устр.|-----| Устр.|               | Устр.|-----| Устр.|
|  CE  |-----|  PE  |               |  CE  |-----|  PE  |  Сеть SP
+------+     +------+               +------+     +------+
                 |                                   |
                 +----------------                   +---------------
                   (a)                                  (b)

Рисунок 3. «Закулисные» соединения между CE.

                 +----------------                   +---------------
                 |                                   |
+------+     +------+               +------+     +------+
| Устр.|-----| Устр.|               | Устр.|-----| Устр.|
|  CE  |     |  PE  |               |  CE  |     |  PE  |  Сеть SP
+------+\    +------+               +------+\    +------+
   |     \       |                     |     \       |
   |«Закул\      |                     |«Закул\      +-------------
   |исный» \     |   SP network        |исный» \     +-------------
   |канал   \    |                     |канал   \    |
+------+     +------+               +------+     +------+
| Устр.|-----| Устр.|               | Устр.|-----| Устр.|
|  CE  |     |  PE  |               |  CE  |     |  PE  |  Сеть SP
+------+     +------+               +------+     +------+
                 |                                   |
                 +----------------                   +---------------
                (a)                                 (b)

Рисунок 4. Комбинация двудомных подключений и «закулисных» каналоа для CE.


Произвольные комбинации описанных методов (см. рисунок 4) следует поддерживать любым решениям L2VPN.

6.7. Абонентский трафик

6.7.1. Пересылка индивидуального, группового и широковещательного трафика

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

6.7.2. Изменение порядка пакетов

При нормальной работе механизмам постановки в очередь и правилам пересылки следует сохранять порядок пакетов с одинаковыми параметрами QoS.

6.7.3. Минимальное значение MTU

В VPLS должно поддерживаться теоретическое значение MTU предлагаемого сервиса.

Принятое минимальное значение MTU должно быть одинаковым в рамках экземпляра VPLS. Разные службы L2VPN могут иметь разные значения MTU. При использовании абонентских VLAN в качестве обозначения сервиса все VLAN в данном экземпляре VPLS должны наследовать общее значение MTU.

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

6.7.4. Сквозная трансляция тегов VLAN

Сервис L2VPN может поддерживать трансляцию идентификаторов абонентских AC (например, тегов VLAN при их применении для обозначения сервиса). Такие услуги упрощают соединения между сайтами, которые хотят сохранить назначения своих AC, или сайтов, относящихся к разным административным доменам. В последнем случае соединения иногда называют L2 extranet. С другой стороны следует отметить, что трансляция тегов VLAN влияет на поддержку множества связующих деревьев (802.1s [IEEE_802.1s]) и может нарушать работу.

6.7.5. «Прозрачность»

Сервис L2VPN должен быть незаметным (прозрачным) для абонентских сетей L2. Решениям L2VPN не следует требовать какой-либо специальной обработки пакетов конечными пользователями перед их отправкой в сеть SP.

Если идентификаторы VLAN назначает SP, «прозрачность» VLAN не обеспечивается. Поэтому «прозрачность» в данном случае не применима, как и в модели сервиса FR/ATM.

Поскольку решение IPLS предназначено для транспортировки инкапсулированного трафика (а не кадров L2), ему недопустимо менять пакеты, инкапсулированные в кадры L2, которые транспортируются IPLS. Однако от решения IPLS не требуется сохранять заголовок L2 при передаче между устройствами CE. Например, адрес Source MAC может не сохраняться. Решение IPLS может удалять заголовки L2 при транспортировке через магистральную сеть и затем восстанавливать тх на выходе без ущерба для транспортировки инкапсулированного трафика.

6.8. Поддержка протоколов управления L2

Решению L2VPN следует обеспечивать прозрачность для протоколов управления L2, используемых абонентом.

В случае VPLS сервис L2VPN должен гарантировать предотвращение петель. Это может обеспечиваться беспетлевой топологией или соответствующими правилами пересылки. Может также применяться протокол связующего дерева (STP17) или похожие протоколы. Решение L2VPN может использовать индикацию абонентских протоколов управления L2 (например, STP BPDU snooping) для повышения эффективности работы VPLS.

6.9. Предоставление CE

Решение L2VPN должно ограничиваться минимальными требованиями к настройке CE (в зависимости от типа устройства), вплоть до полного отсутствия требований к настройке CE.

7. Требования сервис-провайдера

В этом разделе рассматриваются требования с точки зрения SP.

7.1. Расширяемость

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

7.1.1. Оценка пропускной способности сервиса

В [RFC3809] приведены требования и показатели для размера и расширяемости L2VPN, а также примеры.

7.1.2. Параметры конкретных решений

Для каждого решения L2VPN нужен документ с количественными характеристиками расширяемости.

7.2. Идентификаторы

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

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

7.3. Обнаружение относящейся к L2VPN информации

Настройка устройств PE (U-PE и N-PE [RFC4664]) является важной задачей SP. Решениям следует обеспечивать методы динамического обнаружения информации L2VPN устройствами PE для минимизации работ по настройке.

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

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

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

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

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

7.4. Качество обслуживания (QoS)

Важным аспектом предоставляемых провайдерами VPN является поддержка QoS. SP управляет выделением ресурсов и конфигурацией параметров по меньшей мере в устройствах PE и P, а в некоторых с лучаях и в CE. Поэтому SP предоставляет управляемый уровень QoS при доступе или сквозной сервис QoS, как определено в [RFC4031].

7.5. Изолированный обмен данными и информацией о пересылке

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

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

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

Требования безопасности описаны в параграфе 6.5. Следует соблюдать требования безопасности, указанные в [RFC3809]. Следует соблюдать требования безопасности, указанные в [RFC4031], исключая требования к L3 и выше.

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

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

Когда решение L2VPN работает частично через Internet, следует обеспечивать конфигурационные опции для поддержки одного или нескольких перечисленных ниже методов IPsec для защиты абонентского трафика VPN:

  • защита конфиденциальности, позволяющая расшифровать трафик лишь уполномоченным устройствам;

  • защита целостности для сохранения данных неизменными;

  • проверка подлинности отправителей;

  • защита от атак с повторным использованием пакетов.

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

Эти такие защиты должны настраиваемыми между парами конечных точек, такими как PE-PE и PE-MTU при передаче трафика данных L2VPN по протоколу IP [RFC4023]. Методы защиты потоков данных на естественном уровне сервиса (L2) в парах CE-CE, CE-MTU и CE-PE выходят за рамки этого документа. Желательно также обеспечивать найтройку защиты на уровне VPN.

Решение VPN может поддерживать одну или несколько схем шифрования, включая AES и 3DES. Шифрование, дешифрование и распространение ключей следует включать в профили как часть системы управления безопасностью.

7.7. Межпровайдерские L2VPN

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

Решение L2VPN должно выполнять требования конкретных услуг L2VPN, организуемых через несколько AS и/или SP.

Решение L2VPN должно поддерживать распространение пригодных рабочих параметров всем элементам сервиса L2VPN при наличии множества AS и/или SP. Решение L2VPN должно реализовать механизмы совместного использования рабочих параметров в разных AS.

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

7.7.1. Управление

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

  • средства диагностики;

  • защищенный доступ к системе управления одной AS из других;

  • средства запроса конфигурации и состояния;

  • уведомления об отказах и средства поиска неисправностей.

7.7.2. Запросы пропускной способности и QoS

При организации L2VPN через несколько AS требуется механизм-посредник (брокер) для запроса некоторых параметров SLS (таких, как пропускная способность и QoS) в других доменах и сетях, вовлеченных в передачу трафика на разные сайты. Важно отметить, что решение должно быть способно определить, может ли множество вовлеченных AS организовать и гарантировать однородные параметры QoS для поддержки предоставляемой VPN.

7.8. «Оптовые» услуги L2VPN

Архитектура должна поддерживать возможность предоставления одним SP услуг L2VPN для других SP. Например, один SP продает сервис L2VPN «оптом» другому SP, которые может перепродать их своим абонентам.

7.9. Требования к туннелированию

Соединениям между CE на сайтах и PE в магистрали следует поддерживать возможность использования разных технологий туннелирования, таких как L2TP, GRE, IP-in-IP, MPLS и т. п.

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

  • Относящиеся к делу идентификаторы.

  • Параметры QoS/SLS.

  • Параметры восстановления.

  • Идентификаторы мультиплексирования.

  • Параметры безопасности.

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

  • Статистика (такая как время в активном и отключенном состоянии).

  • Счетчик переходов из активного в неактивное состояние и обратно.

  • События (такие как переходы между активным и неактивным состоянием).

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

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

7.10. Поддержка технологий доступа

Соединения между устройствами PE и CE называются AC и могут проходить через сети других провайдеров и сети общего пользования.

Имеется несколько вариантов реализации AC, среди которых наиболее популярны Ethernet, ATM (DSL), Frame Relay, виртуальные каналы на базе MPLS и т. п.

В случае VPLS устройства AC должны использовать кадры Ethernet в качестве блоков данных сервиса (SPDU).

Подключение CE через AC должно быть двухсторонним.

Устройства PE могут поддерживать множество AC на одном физическом интерфейсе. В таких случаях устройствам PE недопустимо различать соединения на основе управляемых абонентом параметров. Например, если для этого применяются теги VLAN, провайдер должен контролировать назначение тегов и строго проверять их соответствие на устройствах CE.

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

7.11. Магистральные сети

В идеале соединениям в сети SP между устройствами PE и P следует быть независимыми от технологии физического и канального уровня. В любом случае характеристики магистральной технологии должны приниматься во внимание при задании аспектов QoS в спецификациях SLS для предлагаемых услуг VPN.

7.12. Разделение и совместное использование ресурсов сети разными L2VPN

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

7.13. Совместимость

Сервис-провайдеры заинтересованы в собеспечении совместимости по меньшей мере для перечисленных вариантов:

  • упрощение использования PE и управляемых CE в одной сети SP;

  • реализация услуг L2VPN через несколько сетей SP;

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

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

7.14. Тестирование

Решениям L2VPN следует поддерживать возможность тестирования и проверки работы и управления на уровне экземпляра L2VPN, а в случае VPLS — на уровне VLAN, если абонентские VLAN служат обозначением сервиса.

Механизмам L2VPN следует поддерживать механизмы проверки связности, а также детектирования и поиска отказов.

Примерами механизмов тестирования являются:

  • проверка связности между знающими о сервисе (service-aware) узлами сети;

  • проверка целостности уровней данных и управления;

  • проверка членства для сервиса.

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

7.15. Поддержка имеющихся PE

Насколько это возможно, решениям IPLS следует упрощать поддержку IPLS на имеющихся устройствах PE, которые уже могли быть развернуты SP, и может быть разработана прежде всего для услуг L3.

8. Требования SP к управлению

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

Детали требований сервис-провайдеров к системам сетевого управления (NMS18) в традиционных категориях настройки, контроля отказов, учета, производительности и безопасности (FCAPS19) приведены в [ITU_Y.1311.1].

9. Инженерные требования

Эти требования определяются характеристиками реализации, которые делают достижимыми требования сервиса и SP.

9.1. Требования к уровню управления

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

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

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

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

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

9.2. Требования к уровню данных

9.2.1. Инкапсуляция

Решениям L2VPN следует применять методы инкапсуляции, определенные PWE3 ([RFC3985]), и не следует вносить новых требований к этим методам.

9.2.2. Отклики на перегрузку

Решениям L2VPN следует применять методы предотвращения перегрузок, определенные PWE3 ([RFC3985]).

9.2.3. Область широковещания

Должна поддерживаться отдельная область широковещания (Broadcast Domain) для каждой сети VPLS.

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

9.2.4. Экземпляры виртуальных коммутаторов

В L2VPN устройства PE должны поддерживать отдельный коммутатор VSI20 для каждой сети VPLS. Каждый VSI должен быть способен пересылать кадры на основе параметров абонентского трафика, таких как MAC-адреса, теги VLAN (при использовании) и т. п, в соответствии с локальными правилами с учетом As well as local policies.

Устройства L2VPN PE должны иметь возможность распределять входящий абонентский трафик по VSI.

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

9.2.5. Изучение MAC-адресов

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

Динамическое заполнение таблиц пересылки (например, путем изучения MAC-адресов) должно выполняться на уровне VSI, т. е. в контексте VPLS и VLAN (при использовании последних).

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

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

Требования, основанные на вопросах безопасности и возможных угрозах описаны в параграфе 6.5. Дополнительные требования для абонентов и сервис-провайдеров рассмотрены в параграфах 6.5 и 7.6, соответственно. Требования к изоляции трафика и маршрутной информации рассмотрены в параграфах 5.4 и 7.5. Меры защиты сетевых ресурсов, таких как память, CPU, пропускная способность, рассмотрены в параграфе 7.12.

Для обеспечения дополнительной защиты можно использовать IPsec после туннелирования трафика L2.

В случаях, когда сервис L2VPN работает на основе IP [RFC4023] через несколько сетей SP с передачей через незащищенные SP, POP, NAP или IX, должны обеспечиваться механизмы защиты, включая шифрование, проверку подлинности и защиту ресурсов, как описано в параграфе 5.5. Например, провайдеру следует рассмотреть использование шифрования и аутентификации для туннеля, служащего частью L2VPN и проходящего через сеть другого провайдера.

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

Авторы благодарны за комментарии и предложения Loa Andersson, Joel Halpern, Eric Rosen, Ali Sajassi, Muneyoshi Suzuki, Ananth Nagarajan, Dinesh Mohan, Yakov Rekhter, Matt Squire, Norm Finn, Scott Bradner и Francois Le Faucheur. Хотелось бы также выразить признательность своим работодателям и другим людям, которые ознакомились с этой работой и предоставили свои отзывы. В работе принимала участие вся команда L2 PPVPN. Значительная часть текста этого документа заимствована из документа с требованиями L3 VPN, разработанного одноименной командой.

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

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

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

[RFC4026] Andersson, L. and T. Madsen, «Provider Provisioned Virtual Private Network (VPN) Terminology», RFC 4026, March 2005.

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

[VPLS_LDP] Lasserre, M., Kompella, V. «Virtual Private LAN Services over MPLS», Work in Progress21.

[VPLS_BGP] Kompella, K., Rekhter, Y. «Virtual Private LAN Service», Work in Progress22.

[IPLS] Shah, H., et al. «IP-Only LAN Service (IPLS)», Work in Progress23.

[IEEE_802.1Q] IEEE Std 802.1Q-1998, «Virtual Bridged Local Area Networks», 1998

[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, «Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification», RFC 2205, September 1997.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[RFC2685] Fox, B. and B. Gleeson, «Virtual Private Networks Identifier», RFC 2685, September 1999.

[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, «Multi-Protocol Label Switching (MPLS) Support of Differentiated Services», RFC 3270, May 2002.

[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, «Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension», RFC 3308, November 2002.

[RFC3809] Nagarajan, A., «Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)», RFC 3809, June 2004.

[RFC3985] Bryant, S. and P. Pate, «Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture», RFC 3985, March 2005.

[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, «Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)», RFC 4023, March 2005.

[RFC4031] Carugi, M. and D. McDysan, «Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)», RFC 4031, April 2005.

[RFC4664] Andersson, L. and E. Rosen, «Framework for Layer 2 Virtual Private Networks (L2VPNs)», RFC 4664, September 2006.

[IEEE_802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98), «Part 3: Media Access Control (MAC) Bridges», 1998.

[ITU_Y.1311.1] Carugi, M. (editor), «Network Based IP VPN over MPLS architecture»,Y.1311.1 ITU-T Recommendation, May 2001.

[IEEE_802.10] EEE Std 802.10-1998 Edition (Revision IEEE Std 802.10-1992, incorporating IEEE Std 802.10b-1992, 802.10e-1993, 802.10f-1993, 802.10g-1995, and 802.10h-1997), «Standard for Interoperable LAN/MAN Security (SILS)», 1998.

[IEEE_802.1AE] IEEE 802.1AE/D5.1, «Draft Standard for Local and Metropolitan Area Networks — Media Access Control (MAC) Security», P802.1AE/D5.1, January 19, 2006.

[IEEE_802.1s] IEEE Std 802.1s-2002, «Virtual Bridged Local Area Networks-Amendment 3: Multiple Spanning Trees», 2002.


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

Waldemar Augustyn

EMail: waldemar@wdmsys.com

Yetik Serbest

AT&T Labs

9505 Arboretum Blvd.

Austin, TX 78759

EMail: yetik_serbest@labs.att.com


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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

1Layer 2 Provider-Provisioned Virtual Private Network.

2Virtual Private Wire Service — услуги виртуальных частных проводов.

3Virtual Private LAN Service — услуги виртуальных частных ЛВС.

4Service Provider — сервис-провайдер.

5Service Level Specification.

6Service Level Agreement.

7Customer Edge.

8Provider Edge.

9Virtual Switching Instance.

10Pseudo wire.

11Packet Switched Network.

12Attachment Circuit.

13Bridge Protocol Data Unit — блок данных протокола мостов.

14Real-Time Streaming Protocol — протокол потоков в реальном масштабе времени.

15Quality of service — качество обслуживания.

16Fault, Configuration, Accounting, Performance, and Security — отказы, настройка, учет, производительность и защита.

17Spanning Tree Protocol — протокол связующего дерева.

18Network Management System.

19Fault, configuration, accounting, performance, and security.

20Virtual Switching Instance — экземпляр виртуального коммутатора.

21Работа опубликована в RFC 4762. Прим. перев.

22Работа опубликована в RFC 4761. Прим. перев.

23Работа опубликована в RFC 7436. Прим. перев.




RFC 4664 Framework for Layer 2 Virtual Private Networks (L2VPNs)

Network Working Group                                  L. Andersson, Ed.
Request for Comments: 4664                                      Acreo AB
Category: Informational                                    E. Rosen, Ed.
                                                     Cisco Systems, Inc.
                                                          September 2006

Framework for Layer 2 Virtual Private Networks (L2VPNs)

Модель виртуальный частных сетей L2 (L2VPN)

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Тезисы

Этот документ определяет модель предоставляемых провайдерами услуг виртуальных частных сетей на канальном уровне (L2VPN1). Цель модели заключается в оказании помощи при стандартизации протоколов и механизмов для поддержки взаимодействия L2VPN.

Оглавление

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

1. Введение

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

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

1.2. Цели и область действия документа

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

Термин «предоставляемые провайдером VPN» обозначает виртуальные частные сети (VPN2), для которых сервис-провайдер (SP3) участвует в управлении и обеспечении VPN.

Требования к услугам L2VPN описаны в [RFC4665].

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

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

1.3. Виртуальные частные сети L2

Имеется два фундаментально различающихся типа услуг L2 VPN, предлагаемых сервис-провайдерами своим абонентам — VPWS4 и VPLS5. Возможна также поддержка услуг IPLS6.

VPWS — это сервис VPN, основанный на предоставлении соединений «точка-точка» на уровне L2. Природа такого сервиса не создает проблем с расширяемостью. Проблемы могут быть связаны лишь с числом конечных точек, которые может поддерживать отдельное устройство PE.

VPLS — это сервис канального уровня (L2), основанный на эмуляции услуг ЛВС через распределенную сеть (WAN7). Объем данных состояния, который должен храниться на краевых устройствах для поддержки функций пересылки, определяет параметры расширяемости ЛВС. Другие проблемы расширяемости могут быть связаны лишь с числом конечных точек, которые может поддерживать отдельное устройство PE (см. параграф 3.4.4).

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

Услуги VPLS могут вносить большие задержки и обеспечивать менее надежный транспорт по сравнению с естественными ЛВС. Стандартные протоколы управления ЛВС могут оказаться не готовыми к работе в таких средах и это может создавать дополнительные проблемы расширяемости сервиса.

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

Список технических терминов, используемых при обсуждении L2VPN, приведен в [RFC4026].

2. Модели

2.1. Эталонная модель для VPWS

Эталонная модель VPWS приведена на рисунке 1.

       Устройства       Туннель        Устройства
      присоединения       PSN         присоединения
                          +
 +-----+             псевдопровод                 +-----+
|     |                                           |     |
| CE1 |--+                                     +--| CE2 |
|     |  |    +-----+   +-----+     +-----+    |  |     |
+-----+  +----|---- |   |  P  |     | ----+----+  +-----+
              |VPWS\|---|-----|-----|/VPWS|
              | PE1 |===|=====|=====| PE2 |
              |    /|---|-----|-----|\    |
+-----+  +----|---- |   |     |     | ----|----+  +-----+
|     |  |    +-----+   +-----+     +-----+    |  |     |
| CE3 |--+                                     +--| CE4 |
|     |                                           |     |
+-----+                                           +-----+

Рисунок 1.


2.1.1. Элементы эталонной модели VPWS

Устройства P, PE (VPWS-PE) и CE, а также туннели PSN определены в [RFC4026]. Устройства присоединения и псевдопровода (PW8) описаны в разделе 3. PE просто отображает PW на устройство присоединения в соответствии с локальной информацией, т. е. демультиплексором PW и входным/выходным физическим или логическим портом.

2.2. Эталонная модель для VPLS

+-----+                                            +-----+
+ CE1 +--+                                     +---| CE2 |
+-----+  |    .............................    |   +-----+
 VPLS A  |  +----+                     +----+  |    VPLS A
         |  |VPLS|                     |VPLS|  |
         +--| PE |--Маршрутизируемая---| PE |--+
            +----+     магистраль      +----+
           /  .            |              .  \     _   /\_
+-----+   /   .            |              .   \   / \ /   \     +-----+
+ CE  +--+    .            |              .    +--\  Сеть  \----| CE  |
+-----+       .         +----+            .       | доступа |   +-----+
 VPLS B       ..........|VPLS|.............        \       /     VPLS B
                        | PE |          ^           -------
                        +----+          |
                          |             |
                          |             |
                       +-----+          |
                       | CE3 |          +-- Эмулируемая ЛВС
                       +-----+
                        VPLS A

Рисунок 2.


На рисунке 2 показана эталонная модель VPLS, где устройства PE с поддержкой VPLS обеспечивают логические соединения так, что устройства CE, относящиеся к одной VPLS, представляются подключенными к одной сети на базе мостов Ethernet. VPLS может включать одну виртуальную сеть (VLAN) или множество VLAN с тегами. Логическая модель VPLS представлена на рисунке 3.


                        |-----Маршрутизируемая----|
                        |        магистраль       |Туннели PSN,
  Эмулируемая ЛВС       |    (маршрутизаторы P)   |псевдопровода
.......................................................................
.                       |                         |                   .
. |---------------------|----|           |--------|-----------------| .
. | --------------------|--- |           | -------|---------------- | .
. |      VPLS Forwarder      |           |      VPLS Forwarder      | .
. | ----------|------------- |           | ----------|------------- | .
..|.................................................................|..
  |           | Интерфейс    |           |           | Интерфейс    |
  |           | эмулируемой  | VPLS-PEs  |           | эмулируемой  |
  |           | ЛВС          |  <---->   |           | ЛВС          |
  | ----------|------------  |           | ----------|------------  |
  | |        Мост         |  |           | |        Мост         |  |
  | -|--------|---------|--  |           | ---|-------|---------|-  |
  |--|--------|---------|----|           |----|-------|---------|---|
     |        |         |                     |       |         |
     |        | Сети    |                     |       | Сети    |
     |        | доступа |                     |       | доступа |
     |        |         |                     |       |         |
     |        |         |                     |       |         |
         Устройства CE                            Устройства CE

Рисунок 3.

На рисунке 3 показано, что в VPLS устройства CE подключаются (возможно через сеть доступа) к модулю моста в VPLS-PE. Внутри VPLS-PE модуль моста соединяется через интерфейс эмулируемой ЛВС с эмулируемой ЛВС. Для каждого экземпляра VPLS имеется экземпляр эмулируемой ЛВС. На рисунке 3 показана некая внутренняя структура эмулируемой ЛВС, включающая модули пересылки (VPLS Forwarder) соединенные псевдопроводами, которые могут проходить через туннели PSN в маршрутизируемой магистральной сети.

Экземпляр VPLS состоит из набора модулей пересылки (не более одного на PE), соединенных псевдопроводами.

Требуемая от моста функциональнсть зависит от сервиса, который SP предоставляет своим абонентам, а также от устройства сети SP. По меньшей мере мост должен поддерживать стандартное MAC-обучение и старение записей. Однако, если устройства PE имеют «закулисные» соединения между собой через сеть L2, может потребоваться полная функциональность мостов IEEE ([IEEE8021D]) с поддержкой протокола связующего дерева между всеми мостами. Точная спецификация требований к модулям мостов в конкретных обстоятельствах выходит за рамки этого документа.

Эта схема задает у каждого модуля моста наличие одного интерфейса эмулируемой ЛВС. Не задается число модулей моста, которые могут присутствовать в VPLS-PE, а также число экземпляров VPLS, которые могут быть подключены к модулю моста через один интерфейс эмулируемой ЛВС.

Эта схема совместима по меньшей мере с перечисленными ниже тремя моделями.

  • Модель 1

    VPLS-PE включает один модуль моста и поддерживает один экземпляр VPLS, которым служит эмулируемая ЛВС. Если эта ЛВС поддерживает VLAN, должны применяться теги 802.1Q [IEEE8021Q] для привязки пакетов к VLAN.

  • Модель 2

    VPLS-PE включает один модуль моста, но поддерживает множество экземпляров VPLS, каждый из которых считается VLAN (по сути, эмулируемой ЛВС). Множество экземпляров VPLS рассматривается как набор VLAN в одной ЛВС. Поскольку каждая сеть VLAN использует свой набор PW, нет необходимости в тегах 802.1Q.

  • Модель 3

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

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

Каждому решению VPLS следует указывать поддерживаемую модель или модели. Каждле решение должно также задавать требуемую от модуля моста функциональность.

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

2.2.1. Элементы эталонной модели VPLS

Устройства PE (VPLS-PE) и CE определены в [RFC4026].

2.3. Эталонная модель для распределенных VPLS-PE и VPWS-PE


           Функциональнсть
           VPLS-PE/VPWS-PE      . . . . . . .
        . . . . . . . . . . .   .           .
        .                   .   .           .
+----+  .  +----+    +----+ .   .Магистраль .
| CE |--.--|U-PE|----|N-PE|-.---.сервис-    .
+----+  .  +----+    +----+ .   .провайдера .
        . . . . . . . . . . .   .           .

2.3.1. Элементы эталонной модели распределенного PE

Функциональность VPLS-PE и VPWS-PE может быть распределена между несколькими устройствами. Устройства, расположенные ближе к клиенту, называют U-PE9, а расположенные ближе к ядру сети — N-PE10 (параграф 3.4.3).

Определения U-PE и N-PE приведены в [RFC4026].

2.4. VPWS-PE и VPLS-PE

Устройства VPWS-PE и VPLS-PE функционально очень похожи в том, что оба применяют модуль пересылки (forwarder) для отображения устройств присоединения на псевдопровода. Единственное различие заключается в том, что модуль пересылки VPWS-PE сопоставляет одно устройство присоединения с одним псевдопроводом, а модуль пересылки в VPLS-PE является экземпляром виртуального коммутатора VSI11, который отображает множество устройств присоединения на множество псевдопроводов (раздел 3).

3. Функциональные компоненты L2 VPN

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

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

3.1. Типы L2VPN

Типы L2VPN различаются характеристиками услуг, предоставляемых клиентам сервис-провайдером (SP).

3.1.1. Услуги VPWS

В VPWS каждое устройство CE представлено набором виртуальных устройств (каналов) «точка-точка».

На другой стороне каждого виртуального канала размещается другое устройство CE. Кадры, передаваемые CE в такое виртуальное устройство принимаются CE на другой стороне виртуального соединения. Пересылка между устройствами CE не зависит от содержимого кадра и полностью определяется виртуальным устройством, в которое кадр передается. Устройства PE выступают в качестве коммутаторов виртуальных каналов.

Этот тип L2VPN был доступен достаточно давно в сетях ATM и Frame Relay. Предоставление таких услуг L2VPN через сети MPLS и/или IP актуально сегодня.

Требования к этому типу сервиса L2VPN указаны в [RFC4665].

3.1.2. Услуги VPLS

В VPLS каждое устройство CE имеет один или несколько интерфейсов ЛВС, ведущих в «виртуальную магистраль».

Два CE подключаются к одной виртуальной магистрали лишь в том случае, когда они относятся к одному экземпляру VPLS (т. е. в одной сети VPN). Когда CE передает кадр, принявшее его устройство PE проверяет поле MAC-адреса получателя для решения вопроса о пересылке кадра. Таким образом, PE играет роль моста. Как показано на рисунке 3, если набор устройств PE поддерживает общий экземпляр VPLS, создается эмулируемая ЛВС, соответствующая этому экземпляру VPLS, к которой подключен каждый из этих PE (через эмулируемый интерфейс). С точки зрения CE виртуальная магистраль представляет набор мостов PE и эмулируемую ЛВС, к которой они относятся. Таким образом, для устройства CE ЛВС, которая соединяет его с мостом, распространяется через магистральную сеть MPLS и/или IP.

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

Сервис VPLS похож на VPWS в том смысле, что решение о пересылке принимается без привлечения заголовка сетевого уровня (L3). Отличия VPLS от VPWS указаны ниже.

  • VPLS позволяет PE использовать адресную информацию из заголовка L2 в кадре для решения вопроса о пересылке кадра.

  • VPLS позволяет использовать одно соединение CE-PE для передачи кадров множеству удаленных CE. В этом отношении VPLS больше напоминает L3VPN, нежели VPWS.

Требования к этому типу сервиса L2VPN указаны в [RFC4665].

3.1.3. Услуги IPLS

Сервис IPLS очень поход на VPLS, за исключением перечисленных ниже отличий.

  • Предполагается, что устройства CE являются хостами или маршрутизаторами, а не коммутаторами.

  • Предполагается, что сервис будет работать только с пакетами IP и протоколами поддержки, такими как ICMP и ARP для IPv4 или Neighbor Discovery для IPv6. Кадры L2, содержащие другие протоколы, не поддерживаются.

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

3.2. Функциональные компоненты базового транспорта L2VPN

Все типы L2VPN должны транспортировать «кадры» через ядро сети, соединяющее устройства PE. Для всех типов L2VPN устройство PE (PE1) получает кадр от CE (CE1), затем передает его другому устройству PE (PE2), которое доставляет кадр CE (CE2). В этом параграфе рассматриваются функциональные компоненты, которые нужны для транспортировки кадров L2 во всех типах L2VPN.

3.2.1. Устройства присоединения

Во всех типах L2VPN устройство CE подключается к PE через то или иное устройство или виртуальный канал. Будем называть это устройством присоединения (подключения) или AC12. Термин применяется очень широко, устройствами подключения могут служить Frame Relay DLCI, ATM VPI/VCI, порты Ethernet, VLAN, соединения PPP на физических интерфейсах, сессии PPP из туннелей L2TP, MPLS LSP и т. п. Устройством CE может быть маршрутизатор, коммутатор, хост, или что-либо иное, подключенное клиентом к VPN. AC передает кадры между CE и PE.

Процедуры организации и поддержки AC выходят за рамки этой архитектуры.

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

Любой кадр будет проходить через AC от CE к PE на одной стороне, а затем через другое устройство AC от PE к CE.

Первое устройство AC будем называть входным (ingress AC), а второе — выходным (egress AC). Отметим, что устройства AC служат входным и выходным для конкретного кадра и указывают лишь направления в данном AC.

3.2.2. Псевдопровода

Псевдопровод (PW) обеспечивает связь между двумя устройствами PE. Как AC служит для передачи кадров между CE и PE, так PW используется для передачи кадров между PE. Термин PW используется в соответствии с определением [RFC3985].

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

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

Процедуры организации и поддержки PW типа «один со многими» не рассматриваются в этой версии модели.

Любой конкретный кадр приходит сначала на входное устройство AC, затем в PW, а затем на выходное устройство AC.

Групповые кадры могут реплицироваться PE, поэтому информация, передаваемая в групповых кадрах, может проходить через множество PW и множество выходных AC.

Таким образом, применительно к данному кадру PW можно связать с несколькими AC. Если эти AC используют одну технологию (например, ATM, Ethernet, Frame Relay), говорят, что PW обеспечивает однородны транспорт, в противном случае транспорт будет неоднородным. Для неоднородного транспорта требуется использовать ту или иную функцию межсетевого взаимодействия. Есть по меньшей мере 3 разных подхода к такому взаимодействию, приведенных ниже.

  1. Одно из устройств CE может локально выполнять функции межсетевого взаимодействия. Например, если устройство CE1 подключено к PE1 через ATM, а устройство CE2 подключено к PE2 через Ethernet, CE1 может принять решение о приеме и передаче кадров Ethernet через ATM с использованием инкапсуляции RFC 2684. В таком случае устройству PE1 нужно знать, что оно завершает ATM VC локально и принимает/передает через PW лишь кадры Ethernet.

  2. Функции межсетевого взаимодействия может выполнять одно из устройств PE. Например, если устройство CE1 подключено к PE1 через ATM, а устройство CE2 подключено к PE2 через Frame Relay, PE1 может выполнять функцию «ATM/FR Service Interworking». CE не будут видеть этого и через PW будут передаваться только кадры Frame Relay.

  3. Можно использовать IPLS. В этом случае «кадрами» в PW будут дейтаграммы IP и двум PE нужно взаимодействовать для обмана (spoof) различных относящихся к L2 процедур, применяемых IP (параграф 3.5).

При использовании разнородных PW протокол организации должен гарантировать, что каждая из конечных точек знает MTU удаленного AC. Если у двух AC значения различаются, нужно выполнять три перечисленных ниже правила.

  • Недопустимо активизировать PW.

  • Конечная точка AC с большим MTU должна уменьшить MTU своего AC до значения MTU удаленного AC.

  • Конечные точки должны согласовать использование процедуры фрагментации-сборки.

3.2.3. Модули пересылки

Во всех типах L2VPN устройство PE (PE1) получает кадр через AC и пересылает его через PW другому PE (PE2). Затем PE2 пересылает этот кадр другому AC.

Случай, когда PE1 и PE2 являются одним устройством, важен в плане корректности обработки для правильного функционирования сервиса L2VPN. Однако для него не нужен какой-либо протокол, поэтому далее этот случай в документе не рассматривается.

Когда PE1 получает кадр от конкретного AC, нужно определить PW, куда должен пересылаться кадр. В общем случае это выполняется на основе следующей информации:

  • входное устройство AC;

  • возможно, содержимое заголовка L;

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

Если рассматривается статическая или динамическая информация, она относится к определенному экземпляру L2VPN (т. е. отдельной VPN).

Аналогично при получении кадра PE2 на конкретном PW нужно определить AC, куда должен пересылаться кадр. Это определяется следующей информацией:

  • входной PW;

  • возможно, содержимое заголовка L;

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

Если рассматривается статическая или динамическая информация, она относится к определенному экземпляру L2VPN (т. е. отдельной VPN).

Процедуры, используемые для принятия решения о пересылке, называют «модулем пересылки» (forwarder). Будем считать PW «привязанным» в каждой из конечных точек к модулю пересылки. Эти модули, в свою очередь, «привязывают» псевдопровода PW к устройствам AC. В разных типах L2VPN применяются разные модули пересылки.

Например, forwarder может связывать одно устройство AC с одним PW, игнорируя содержимое кадров и не используя для пересылки другой информации. Другой модуль пересылки может связывать AC с множеством PW и AC, передавая отдельные кадры из AC в PW, из PW в AC или из AC в AC на основе сравнения данных в заголовке L2 с базой данных пересылки. Это более подробно рассматривается при описании разных типов L2VPN.

3.2.4. Туннели

PW организуется в «туннеле» от PE1 до PE2. Предполагается возможность организации в одном туннеле произвольного числа PW13, если все они завершаются на PE2.

Не требуется даже начинать все PW в туннеле на устройство PE1, это могут быть туннели типа multipoint-to-point. Не требуется и передача всех PW между парой устройств PE в одном туннеле. Все, что требуется, — это возможность PE2 связать проходящий через туннель кадр с определенным PW.

Для организации туннелей между PE могут применяться различные технологии. Все, что реально требуется от такой технологии, — это поддержка демультиплексирования организованных в туннеле PW. В качестве туннеля могут служить MPLS LSP, туннели L2TP, IPsec, MPLS-in-IP и т. п. В общем случае технология туннелирования будет требовать применения инкапсуляции, содержащей поле демультиплексора, служащее для идентификации PW. Процедуры организации и поддержки туннелей выходя за рамки этой схемы (см. параграф 3.2.6. Сигнализация PW).

При наличии множества туннелей от PE1 до PE2 может оказаться желательной привязка определенного PE1-PE2 PW к конкретному туннелю на основе тех или иных характеристик PW и/или туннеля. Например, можно размещать PW с определенными требованиями QoS в туннель с подходящими параметрами QoS. Процедуры такой привязки выходят за рамки этой модели.

Хотя PW «точка-точка» являются двухсторонними, туннели, через которые они проходят, не обязаны быть двухсторонними и/или относиться к типу «точка-точка». Например, PW «точка-точка» может проходить через односторонний путь multipoint-to-point MPLS LSP.

3.2.5. Инкапсуляция

Поскольку пакеты L2VPN передаются через псевдопровода, следует применять стандартные для псевдопровода форматы и методы инкапсуляции (заданные рабочей группой IETF PWE3), когда они подходят.

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

Может потребоваться определение дополнительных вариантов инкапсуляции PW с учетом потребностей L2VPN, но это может выходить за рамки задач группы PWE3. Примером может служить неоднородный (гетерогенный) транспорт.

3.2.6. Сигнализация PW

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

Сигнализация для псевдопровода «точка-точка» должна обеспечивать перечисленные ниже функции.

  • Распространение демультиплексора.

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

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

  • Выбор модуля пересылки (Forwarder) на удаленном PE.

    Сигнальный протокол должен содержать достаточно информации, чтобы удаленный маршрутизатор PE мог выбрать подходящий модуль пересылки, к которому будет привязан PW. Эту информацию называют селектором удаленного модуля пересылки (Remote Forwarder Selector). Требуемая для этого информация зависит от типа L2VPN и модели предоставления услуг (см. параграфы 3.3.1 и 3.4.2). Remote Forwarder Selector может однозначно указывать конкретный модуль пересылки или задавать атрибуты таких модулей. В последнем случае выбор конкретного модуля пересылки будет определяться этими атрибутами.

  • Поддержка эмуляции псевдопроводов.

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

  • Распространение смены состояний.

    Изменения состояний AC могут потребовать смены состояний PW, к которым привязаны эти устройства AC, и наоборот. Спецификация способов отражения изменений обычно относится к задачам рабочей группы PWE3.

  • Задание характеристик псевдопровода.

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

Как отмечено выше, сигнализация для PW «точка-точка» должна передавать достаточно информации, чтобы удаленный маршрутизатор PE мог должным образом связать PW с модулем пересылки, а также связать конкретное значение демультиплексора с этим PW. Когда два PE имеют корректные привязки PW-Forwarder и согласовали значения демультиплексоров, можно считать создание PW завершенным. Если нужно согласовать дополнительные характеристики или параметры конкретного PW или передать информацию о состоянии определенного PW, этот псевдопровод должен указываться значением демультиплексора.

Сигнальные процедуры для псевдопроводов «точка-точка» чаще всего представляют обычные процедуры «точка-точка», применяемые двумя конечными точками PW. Однако имеются предложения использовать сигнализацию point-to-multipoint для организации псевдопроводов «точка-точка», поэтому это включено в описание модели. Когда PW сами по себе организуют соединения «один со многими» (point-to-multipoint), для их организации можно применять сигнализацию point-to-point или point-to-multipoint. Эти вопросы рассматриваются ниже.

3.2.6.1. Сигнализация «точка-точка»

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

  • LDP

    Можно определить расширения протокола LDP [RFC3036] для сигнализации псевдопроводов. Эта форма сигнализации может применяться для псевдопроводов, организуемых в туннелях MPLS или MPLS с инкапсуляцией в другие протоколы.

  • L2TP

    Протокол L2TP [RFC2661] можно применять для сигнализации псевдопроводов, организуемых как «сессии» в туннелях L2TP. Для этого могут потребоваться специальные расширения L2TP.

Возможны и другие методы сигнализации.

Одно управляющее соединение между парой PE может применяться для управления множеством PW.

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

3.2.6.2. Многоточечная сигнализация

Рассмотрим следующие условия:

  • нужно организовать множество PW с одинаковыми характеристиками;

  • не требуется использовать сигнальный протокол PW для передачи изменения состояний псевдопроводов;

  • для всех PW можно использовать одно значение Remote Forwarder Selector.

Назовем эти условия «условиями среды» (Environmental Conditions).

Предположим, что имеется механизм, с помощью которого каждое из множества устройств PE может делать уникальный и детерминированный выбор из заданного набора значений демультиплексора. Назовем это «условием демультиплексора» (Demultiplexor Condition). В качестве альтернативы предположим, что кто-то пытается организовать PW типа «множество с одним» вместо PW «точка-точка». Назовем это «многоточечным условием» (Multipoint Condition).

Если

  • выполняются «условия среды»;

  • и выполняется какое-либо из двух условий:

    • Demultiplexor Condition;

    • Multipoint Condition.

Тогда для данного набора PW, завершающихся на выходном PE1, информация, которую устройству PE1 нужно передать входным (входному) PE для каждого псевдопровода будет совпадать и все входные PE получат одно значение Forwarder Selector, а также получать одинаковые наборы параметров PW (если они имеются). Они также получат одно значение демультиплексора (для PW типа «точка-точка») или общий набор значений демультиплексора из которого каждое устройство может выбрать свое уникальное значение.

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

Этот метод сигнализации называется «один со многими» (point-to-multipoint). Он может применять, например, протокол BGP [RFC1771] для устройств PE, не являющихся партнерами BGP, но имеющими в качестве партнера один или несколько рефлекторов маршрутов BGP [RFC2796].

3.2.6.3. Работа через несколько AS

Псевдопровода могут потребоваться между PE в сети одного SP и PE в сети другого SP. Это имеет ряд последствий, перечисленных ниже.

  • Протокол сигнализации, применяемый для организации PW, должен работать через границы сетей. Такая возможность обеспечивается всеми протоколами на основе IP.

  • Два PE в конечных точках PW должны иметь маршрутизируемые и доступные один для другого адреса.

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

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

Качество обслуживания характеризует способность сети обеспечить заданный уровень сервиса (SLS14) для таких атрибутов обслуживания, как защита, безопасность и QoS15. Качество обслуживания зависит от требований абонента и может характеризоваться множеством параметров.

Требуемое качество обслуживания должно обеспечиваться на устройствах присоединения (AC), а также на псевдопроводах (PW). Механизмы обеспечения качеств обслуживания на PW могут быть обусловлены PW или туннелем. В последнем случае привязка PW к туннелю может определяться требованиями качества сервиса.

3.2.7.1. QoS

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

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

Функции QoS перечислены ниже.

  • Приоритизация абонентского трафика. Для услуг L2VPN может применяться доставка «по мере возможностей» (best effort) или гарантия QoS. Для трафика абонента может потребоваться изменение приоритета по отношению к другому трафику при распределении общих ресурсов сети. Это требует поддержки решением L2VPN классификации и маркировки приоритета для обеспечения требований абонента к QoS.

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

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

    Правила обычно применяются на входном устройстве AC.

  • Формование (Shaping). В некоторых случаях неоднородный (случайный) трафик L2VPN может приводить к неоптимальному использованию ресурсов сети. С помощью механизмов управления очередями и пересылкой трафик можно «формовать» без нарушения порядка доставки пакетов.

    Формование трафика обычно выполняется на входном устройстве AC.

3.2.7.2. Отказоустойчивость

Отказоустойчивость описывает способность инфраструктуры L2VPN защищать потоки данных при отказах в сети с сохранением доступности сервиса.

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

Желательно обнаруживать отказы «немедленно» и позволять механизмам защиты быстро восстанавливать работу, чтобы сбои практически не отражались на сервисе L2VPN. Восстановление следует выполнять до того, как устройства CE смогут отреагировать на отказ. Важные аспекты обеспечения отказоустойчивости приведены ниже.

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

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

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

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

3.2.8. Управление

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

3.3. VPWS

VPWS — сервис L2VPN, в котором каждый модуль пересылки связывает одно устройство AC с одним PW. Кадры, полученные устройством AC, передаются в PW, а кадры, принятые из PW, передаются в AC. Содержимое заголовков L2 в кадрах не играет роли при решении о пересылке за исключением того, что содержимое заголовка L2 используется для связывания кадра с определенным AC (например, поле DLCI в кадре Frame Relay указывает AC).

Комбинация <AC, PW, AC> определяет «виртуальное устройство» (канал) между двумя устройствами CE.

Конкретная сеть VPN (экземпляр VPWS) может рассматриваться как набор таких виртуальных каналов или «наложение» (overlay) псевдопроводов PW на магистраль MPLS или IP. Эито создает наложенную топологию, которая служит «виртуальной магистралью» отдельной сети VPN.

Вопрос принадлежности двух виртуальных устройств (каналов) к одной или разным VPN является административным и решается на основе соглашения между SP и абонентом. Решение этого вопроса может влиять на модель предоставления услуг (см. ниже), а также на связывание конкретных PW с туннелями, способ назначения QoS конкретным AC и PW и т. п.

Отметим, что VPWS использует исключительно PW «точка-точка».

3.3.1. Предоставление и автоматическое обнаружение сервиса

Предоставление услуг VPWS включает:

  1. предоставление устройств (каналов) AC;

  2. предоставление устройствам PE информации, позволяющей им организовать PW между устройствами AC для создания наложенной топологии;

  3. настройку нужных характеристик PW.

3.3.1.1. Предоставление AC

Во многих случаях устройства AC должны предоставляться индивидуально для PE и/или CE. Это безусловно будет возникать в случаях, когда для соединения CE — PE используется коммутируемая сеть, такая как ATM или FR и в качестве VC применяются PVC18, а не SVC19. Это также возникает в случаях, когда для отдельных AC требуются определенные параметры (например, QoS, гарантированная пропускная способность) различающиеся у разных устройств.

Имеются также случаи, когда специально предоставлять AC не нужно. Например, если в качестве AC используется MPLS LSP между CE и PE, соединение может быть организовано в результате создания PW и его не требуется организовывать до создания PW. То же самое применимо в случае, когда AC является коммутируемым виртуальным устройством любого типа, хоты в таких случаях могут потребоваться другие правила управления предоставлением канала (например, ограничение числа AC, которые могут быть организованы между данной парой CE — PE).

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

3.3.1.2. Предоставление PW для произвольной наложенной топологии

Для поддержки произвольных наложенных топологий нужно разрешить предоставление отдельных PW. В этой модели при предоставлении PW на устройстве PE, псевдопровод локально связывается с конкретным AC. Предоставляется также информация, указывающая конкретное соединение AC на удаленном PE.

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

  • Двухстороннее предоставление, когда PE на каждой стороне PW предоставляется приведенная ниже информация.

    • Идентификатор локального AC, с которым связан PW.

    • Тип и параметры PW.

    • IP-адрес удаленного PE (PE на удаленном конце PW).

    • Значимый для удаленного PE идентификатор, который может быть передан протоколом сигнализации PW, чтобы позволить удаленному PE связать PW с нужным AC. Это может быть идентификатор PW или удаленного AC. При использовании идентификатора PW он должен быть уникальным на каждом из двух PE. Если используется идентификатор AC, он должен быть уникальным на удаленном PE.

    Этот идентификатор применяется в качестве Remote Forwarder Selector по завершении сигнализации (параграф 3.2.6.1).

  • Одностороннее предоставление, когда PE на одном конце PW предоставляется приведенная ниже информация.

    • Идентификатор локального AC, с которым связан PW.

    • Тип и параметры PW.

    • Уникальный в глобальном масштабе идентификатор удаленного AC.

    Этот идентификатор применяется в качестве Forwarder Selector по завершении сигнализации (параграф 3.2.6.1).

    В этой модели IP-адрес удаленного PE не предоставляется, а вместо этого будет применяться схема автоматического обнаружения для отображения уникального в глобальном масштабе идентификатора на IP-адрес удаленного PE вместе с идентификатором (возможно уникальным лишь в этом PE) для AC на этом PE. Затем сигнальный протокол PW организует соединение с удаленным PE, передавая идентификатор AC, чтобы удаленный маршрутизатор PE связал PW с нужным AC.

    Эта схема требует предоставления PW лишь на одном PE, но не избавляет от необходимости (если она имеется) предоставления AC на обоих PE.

Эти модели предоставления хорошо подходят для сигнализации «точка-точка». Когда каждый псевдопровод PW предоставляется индивидуально, не возникает необходимости применять сигнализацию point-to-multipoint.

3.3.1.3. Модель предоставления PW с цветными группами

Предположим, что каждый маршрутизатор PE собирает AC в группу (pool) и с каждой группой связывает определенный цвет (например, группа может содержать все AC от данного PE к отдельному CE и не включать других соединений). Далее предположим, что вводится правило, в соответствии с которым при наличии у PE1 и PE2 групп одного цвета между PE1 и PE2 будет псевдопровод PW, привязанный на PE1 и PE2 к произвольно выбранному AC из данной группы (не исключается случай наличия в PE нескольких групп одного цвета).

Например, каждая группа в определенном PE может представлять определенное устройство CE, для которого AC из этой группы являются AC, соединяющими данный CE с данным PE. В качестве «цвета» может использоваться VPN-id. Применение этой модели предоставления приведет к полносвязным соединениям между всеми CE в сети VPN, где каждое устройство CE в сети VPN имеет виртуальный канал (устройство) к каждому другому CE в данной VPN.

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

  • Набор AC, относящихся к группе (ни одно устройство AC не входит в несколько групп).

  • «Цвет».

  • Идентификатор группы, уникальный по меньшей мере в части «цвета».

    Затем используется процедура автоматического обнаружения с целью отобразить каждый цвет на список упорядоченных пар <IP-адрес PE, pool id>. Наличие пары <X, Y> в таком списке означает, что PE с IP-адресом X имеет группу заданного цвета с идентификатором (pool id) Y.

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

  • PE определяет наличие у себя группы с цветом C.

  • С помощью автоматического обнаружения PE получает набор упорядоченных пар <X,Y> для цвета C.

  • Для каждой такой пары <X,Y> устройство PE:

    • удаляет AC из группы;

    • привязывает AC к определенному PW;

    • сообщает PE X с помощью сигнализации «точка-точка» о привязке PW к AC из группы Y.

Другой возможный метод сигнализации описан ниже.

  • PE определяет наличие у себя группы с цветом C, содержащей n каналов AC.

  • PE связывает каждый канал AC с PW, создавая набор PW, который организуется в форме последовательности (например, с каждым PW может быть связано значение демультиплексора и PW упорядочиваются по числовым значениям полей демультиплексора).

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

  • PE сообщает каждому такому маршрутизатору PE последовательность Q из псевдопроводов PW.

  • Если PE получает такой сигнал и имеет группу Y с заданным цветом, этот PE:

    • удаляет AC из группы;

    • привязывает AC к определенному PW, являющемуся Y-м в последовательности Q.

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

Отметим, что по причине передачи некой информации всем удаленным PE этот метод может поддерживаться с помощью сигнализации point-to-multipoint.

Эта модель предоставления применима при выполнении всех перечисленных ниже условий.

  • Не требуется обеспечение различных характеристик для разных PW.

  • Не важно, какая пара устройств AC связывается PW, если оба AC в паре относятся группам одного цвета.

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

3.3.2. Требования к процедурам автоматического обнаружения

Некоторые из требований к автоматическому обнаружению могут быть выведены из написанного выше.

Для поддержки модели одностороннего предоставления автоматическое обнаружение должно быть способно отобразить уникальный в глобальном масштабе идентификатор (PW или устройства AC) на IP-адрес PE.

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

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

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

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

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

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

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

3.3.3. Разнородные PW

В некоторых случаях могут быть желательны PW, связывающие пару AC, которые используют разные технологии (например, ATM и Ethernet). Имеется много способов решения этой задачи в зависимости от типа AC.

  • Если одно устройство AC использует ATM, а другое — FR, можно применить стандартное решении ATM/FR Network Interworking. В этом случае для сигнализации PW может применяться ATM, а межсетевое взаимодействие происходить между PW и FR AC.

  • Может применяться общая для обоих AC инкапсуляция. Например, если одно устройство AC использует Ethernet, а другое FR, на втором устройстве можно использовать инкапсуляцию Ethernet over FR. В этом случае для сигнализации PW используется Ethernet с локальной обработкой инкапсуляции Ethernet over FR на PE с FR AC.

  • Если известно, что два AC подключены к маршрутизаторам или хостам IP и передают лишь трафик IP, можно применять PW, передающий пакеты IP и выбор инкапсуляции L2 будет локальной задачей для обоих PE. Однако, если одно из устройств AC является ЛВС, а другое — каналом «точка-точка», нужно будет обеспечить корректную работу таких процедур, как ARP и Inverse ARP, а для этого может потребоваться та или иная сигнализация и функции прокси. Кроме того, при использовании в CE алгоритма маршрутизации с разными процедурами для ЛВС и каналов «точка-точка» могут потребоваться дополнительные механизмы межсетевого взаимодействия.

3.4. Эмулируемые ЛВС в VPLS

VPLS — это сервис L2VPN, в котором:

  • AC соединяют устройства CE с модулями мостов в PE;

  • каждый модуль моста в PE подключается через «интерфейс эмулируемой ЛВС» к «эмулируемой ЛВС».

Логическая модель VPLS представлена на рисунке 3.

Ниже приведена функциональная декомпозиция эмулируемой ЛВС сервиса VPLS. Устройствами AC эмулируемой ЛВС являются «интерфейсы эмулируемой ЛВС», соединяющие модуль моста в PE с модулем пересылки (VPLS Forwarder), как показано на рисунке 3. Данными (payload) AC являются кадры Ethernet с тегами VLAN или без них.

Данный модуль VPLS Forwarder с данном PE будет иметь множество AC лишь в том случае, когда в PE имеется множество модулей мостов, подключенных к модулю пересылки. Этот вариант рассматривается в данной схеме, хотя рассмотрение его реальной применимости выходит за рамки документа.

Множество модулей VPLS Forwarder в одном экземпляре VPLS соединяется через PW. Два VPLS Forwarder будут соединены PW лишь в том случае, когда эти модули относятся к одному экземпляру VPLS (могут быть и другие ограничения, например, наличие PW между парой VPLS Forwarder может быть обусловлено их принадлежностью к одной VLAN внутри одной сети VPN). Набор соединенных между собой модулей VPLS Forwarder образует эмулируемую ЛВС (VPLS Emulated LAN).

В реальной ЛСВ любой кадр, переданный одним элементом, получают все остальные. Однако в VPLS Emulated LAN ситуация иная. Когда модуль VPLS Forwarder принимает индивидуальный кадр через один из своих интерфейсов Emulated LAN, он не обызан пересылать этот кадр всем другим модулям Forwarder в данной эмулируемой ЛВС. Индивидуальный кадр нужно переслать лишь одному модулю Forwarder, чтобы тот мог доставить его по MAC-адресу получателя. Если передающий модуль Forwarder знает какому модулю пересылки нужно отправить конкретный индивидуальный кадр, он будет пересылать кадр лишь этому модулю Forwarder. Такая оптимизация пересылки является важной частью любой попытки обеспечить сервис VPLS через распределенную или городскую сеть.

По сути, каждый модуль пересылки ведет себя как экземпляр виртуального коммутатора (VSI20), поддерживающий таблицу пересылки с отображением MAC-адресов на PW. Таблица пересылки VSI заполняется почти так же, как обычный мост заполняет таблицу пересылки. VPLS Forwarder изучает MAC-адреса отправителей (SA21) в кадрах, полученных на PW от модулей пересылки, а также должен выполнять набор процедур, таких как контроль старения адресных записей. Кадры с неизвестными или групповыми DA22, должны широковещательно рассылаться одним модулем пересылки всем другим модулям Forwarder той же эмулируемой ЛВС. Однако имеется ряд существенных различий между VPLS Forwarder VSI и функцией пересылки стандартного моста, отмеченных ниже.

  • VPLS Forwarder никогда не изучает MAC SA в кадрах, полученных на его AC, изучая лишь MAC SA а кадрах, полученных на PW от других модулей VPLS.

  • Модули VPLS Forwarder конкретной эмулируемой ЛВС не участвуют в протоколе STP23 с другими модулями пересылки. Для предотвращения петель при пересылке применяется метод «расщепления горизонта.

Эти различия более подробно рассматриваются ниже.

Отметим, что модули моста PE в одной эмулируемой ЛВС могут (но не обязаны) участвовать в протоколе STP эмулируемой ЛВС (вопрос участи в протоколе выходит за рамки спецификации VPLS). Модули моста PE будут изучать MAC-адреса на AC, а также на интерфейсах Emulated LAN, но не будут изучать MAC-адреса на PW, поскольку PW «спрятаны» за интерфейсом Emulated LAN. Поэтому таблицы пересылки модуля моста PE и VSI модуля VPLS Forwarder будут разными (конкретная реализация может объединять эти таблицы, но этот вопрос выходит за рамки документа).

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

Следует отметить, что в результате изменения связующего дерева в сети абонента (если оно есть) или на мостах PE (если оно есть), некоторые MAC-адреса могут менять свое местоположение, переходя с одного PE на другой. Эти изменения могут быть не видимы для модулей VPLS Forwarder, что может привести к недоступности таких MAC-адресов, пока они не устареют в VSI прежнего PE. Если такое поведение не приемлемо, потребуется тот или иной механизм оповещения модулей VPLS Forwarder о произошедших изменениях.

3.4.1. Топология и пересылка наложенного сервиса VPLS

Внутри одной сети VPLS модули VPLS Forwarder соединяются псевдопроводами PW, формирующими «наложенную топологию».

Таблицы VSI в модулях VPLS Forwarder заполняются при изучении MAC-адресов, т. е. VSI хранит адреса MAC SA с привязкой к PW, через который адрес был получен. Если определенный MAC-адрес присутствовал в качестве SA в кадре, принятом через определенный PW, кадры с таким MAC в поле DA, следует передавать в таблицу VSI, расположенную на удаленном конце этого PW. Для выполнения этого на удаленной стороне PW требуется наличие уникального VSI, что означает невозможность соединения VSI с помощью многоточечных (multipoint-to-point) PW. PW должны быть типа «точка-точка» или, возможно, — point-to-multipoint.

Изучение MAC от PW «точка-точка» выполняется стандартными методами IEEE, где PW трактуется модулем VPLS Forwarder как «порт моста». Естественно, при изучении MAC-адресов из point-to-multipoint PW, экземпляр VSI должен указывать, что пакеты для этого адреса будут передаваться в PW «точка-точка» к корню point-to-multipoint PW.

Решения VSI о пересылке должны координироваться для обеспечения беспетлевой пересылки в наложенной топологии.

Иммется несколько возможных типов наложенной топологии.

  • Полносвязные соединения (Full mesh).

    При полносвязных соединениях каждый экземпляр VSI в данной сети VPLS имеет в точности один PW «точка-точка» к каждому другому VSI в той же VPLS.

    В такой топологии пересылка без петель обеспечивается простыми правилами.

    Если VSI получает через PW кадр от другого VSI, недопустимо пересылать этот кадр любому другому PW для любого другого VSI. Это гарантирует пересылку кадра за пределы эмулируемой ЛВС после прохождения через нее.

    Если VSI получает на одном из интерфейсов Emulated LAN индивидуальный кадр с известным DA, кадр передается в точности одному PW.

    Если VSI получает на одном из интерфейсов Emulated LAN групповой кадр с неизвестным DA, копия этого кадра передается каждому VSI в той же эмулируемой ЛВС. Это может быть реализовано путем репликации кадра и передачи копии через каждый PW «точка-точка». Псевдопровода «точка-точка» могут быть дополнены в полносвязной сети псевдопроводами point-to-multipoint PW, где каждый экземпляр VSI в VPLS служит передатчиком в один псевдопровод point-to-multipoint, а получателями на этом PW являются все другие VSI в этой сети VPLS.

  • Структурированное дерево (Tree structured)

    В топологии структурированного дерева каждый виртуальный коммутатор VSI в конкретной сети VPLS предоставляется на определенном уровне дерева и имеет не более одного псевдопровода на вышележащий уровень. Верхним уровнем является корень дерева.

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

  • Дерево с полной связностью на верхнем уровне (Tree with Meshed Highest Level)

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

Возможны и другие наложенные топологии, например частичная полносвязность PW между VSI сети VPLS. Для предотвращения петель может применяться, например, протокол STP для наложенной топологии. Эти варианты топологии далее не рассматриваются в модели.

Отметим, что отсутствие петель в наложенной топологии не гарантирует их отсутствия в ЛВС, содержащей VPLS. Не гарантируется даже отсутствие петель между модулями мостов PE. Обеспечивается лишь гаратния того, что кадр, переданный в эмулируемую ЛВС не окажется в петле пересылки до того, как он покинет Emulated LAN.

Некорректная конфигурация абонентской ЛВС или модулей мостов PE может создавать петли и попавшие в такую петлю кадры могут многократно проходить через наложенную топологию. Можно рекомендовать процедуры идля обнаружения и/или предотвращения таких петель.

3.4.2. Предоставление и автоматическое обнаружение сервиса

Каждой сети VPLS должен быть назначен уникальный в глобальном масштабе идентификатор VPN-id.

Устройства AC, соединяющие CE с PE, должны предоставляться как на PE, так и на CE. VSI для сети VPLS должны предоставляться на PE и локальные AC этой сети VPLS должны связываться с соответствующими VSI. Для VSI должны предоставляться идентификаторы VPLS, к которым относятся виртуальные коммутаторы.

Схема автоматического обнаружения может применяться устройствами PE для отображения идентификатора VPLS на множество удаленных PE, имеющих виртуальные коммутаторы VSI в данной сети VPLS. После этого PE может использовать сигнализацию псевдопроводов для организации PW к каждому из этих коммутаторов VSI. Идентификатор VPLS будет служить в качестве Forwarder Selector для протокола сигнализации. Это приведет к организации полной связности PW между VSI в отдельной сети VPLS.

Если одна сеть VPLS содержит множество VLAN, может оказаться желательным связывание между собой лишь VSI, относящихся к одной виртуальной сети VLAN.

В этом случае для каждого виртуального коммутатора VSI будет требоваться один или несколько идентификаторов VLAN и схема автоматического обнаружения должна будет отобразить идентификатор VPLS на пары <PE, VLAN id>.

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

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

3.4.3. Распределенное устройство PE

При организации сервиса VPLS устройства CE зачастую подключаются к управляемым провайдером устройствам CPE. Одно устройство CPE может применяться для подключения CE нескольких абонентов, особенно в случаях размещения множества абонентов в одном здании. Однако эти устройства реально являются частью сети SP, поэтому они могут рассматриваться как устройства PE.

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

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

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

  • Выполнение функций PE, относящихся к VPLS. В этом случае устройство называется VPLS-PE [RFC4026]. Такие устройства соединяются с маршрутизаторами ядра (P).

Функциональность PE для VPLS может быть распределена между двумя устройствами, одно из которых (low-end) размещается ближе к абонентам и выполняет, например, функции изучения MAC-адресов и принимает решение о пересылке, а другое (high-end) выполняет функции управления, например, организацию туннелей, PW и VC. Первый тип устройств называют U-PE, а второй — N-PE.

Возможно, что U-PE может быть размещено очень близко к клиенту, например в здании с несколькими абонентами. Предполагается, что N-PE будет размещаться на площадке SP.

Распределенный вариант PE интересен по нескольким причинам, рассмотренным ниже.

  • N-PE может быть устройством, на котором сложено реализовать функции VSI, описанные выше. Например, N-PE может быть маршрутизатором, не способным к быстрому изучению MAC-адресов, которое требуется для реализации модуля пересылки VSI. В то же время, U-PE может быть недорогим устройством, которое не может реализовать все функции VPLS.

    Это стимулирует дополнительные исследования эффективного распределения функциональности VPLS PE между U-PE и N-PE.

  • Обычно в архитектуре L2VPN предполагается, что устройства PE выступают партнерами в протоколе маршрутизации магистральной сети. Поскольку число устройств U-PE может быть очень велико, по сравнению с числом N-PE, разделение функций может быть оправдано с точки зрения расширяемости маршрутизации.

  • U-PE может быть сравнительно недорогим устройством, которое не способно выполнить все процедуры сигнализации и автоматического обнаружения, которые требуются для сервиса VPLS.

Функциональность VPLS можно распределить между U-PE и N-PE разными способами и для этого предложено множество решений. Все они предполагают, что U-PE будет поддерживать модуль пересылки (VSI forwarder), подключенный с помощью PW к удаленным VSI и N-PE не потребуется выполнять функции пересылки VSI. Предложения обычно различаются по перечисленным ниже вопросам.

  • Поддерживать в U-PE все сигнальные функции для организации PW к удаленным VSI или отдать это N-PE?

    Поскольку U-PE требуется передавать пакеты в PW для удаленных VSI и получать пакеты из PW от удаленных VSI, при поддержке сигнализации PW на устройствах N-PE потребуется тот или иной (облегченный) вариант сигнализации между N-PE и U-PE, позволяющий «продлить» PW от N-PE до U-PE.

  • Поддерживать в U-PE функции автоматического обнаружения или отдать это N-PE?

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

    Выбор точки реализации автоматического обнаружения может зависеть от конкретного протокола обнаружения. Например, не следует ожидать участия U-PE в автоматическом обнаружении на основе BGP, но вполне возможно их участие в автоматическом обнаружении на основе RADIUS.

  • Если устройство U-PE не участвует в резервировании маршрутизации, но подключено к двум разным N-PE, может ли U-PE выполнять интеллектуальный выбор лучшего N-PE в качестве next hop для трафика, адресованного определенному VSI? Если нет, можно ли сделать этот выбор на основе того или иного взаимодействия между N-PE и U-PE или этот выбор должен быть предоставлен?

  • Если U-PE не участвует в маршрутизации, но полностью участвует в сигнализации PW и применяется MPLS, как N-PE может передать U-PE метки, которые нужны U-PE для передачи трафика своим партнерам по сигнализации (если U-PE участвует в маршрутизации, это происходит автоматически)?

  • Выполнять репликацию групповых кадров в N-PE или U-PE?

Эти вопросы взаимосвязаны и ответ на один из них может влиять на другие.

3.4.4. Проблемы расширяемости VPLS

В общем случае PSN поддерживает решение VPLS с туннелями между каждой парой устройств, участвующих в одном экземпляре VPLS. Строго говоря, устройствам VPLS-PE, участвующим в нескольких экземплярах VPLS, в общем случае нужен лишь один туннель, но в целях выделения ресурсов может потребоваться организация нескольких туннелей. Для каждого экземпляра VPLS на данном VPLS-PE требуется организовать псевдопровод к каждому другому VPLS-PE этого экземпляра VPLS. В результате между n маршрутизаторами VPLS-PE необходимо организовать n*(n-1) псевдопроводов. В больших системах это обычно ограничивает возможности расширения. Одним из способов решения проблемы является использование иерархии.

3.5. IPLS

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

В такой среде все кадры Ethernet, переданные от данного CE конкретному устройству PE через данный канал AC, будут иметь один MAC-адрес отправителя. Поэтому вместо изучения MAC-адресов на уровне данных PE может использовать для изучения MAC-адресов уровень управления. Это позволяет реализовать PE на устройствах, не способных выполнять изучение MAC-адресов на уровне данных.

Для избавления от необходимости изучать MAC-адреса на PW и AC сигнальный протокол псевдопроводов будет переносить MAC-адреса от одного PW к другому. В случае IPv4 каждое устройство PE будет служить proxy ARP для подключенных напрямую устройств CE. В случае IPv6 каждое устройство PE будет передавать proxy Neighbor и/или анонсы маршрутизаторов (Router Advertisement).

Отказ от изучения MAC-адресов на PW избавляет от необходимости использовать PW типа «точка-точка» и позволяет применять вместо них многоточечные (multipoint-to-point) PW.

В отличие от VPLS все AC в IPLS не обязаны передавать кадры Ethernet и требуется лишь передача через сеть пакетов IP, а не их инкапсуляции в L2. Однако при наличии связанных с L2 протоколов, которые предоставляют услуги для L3 (например, преобразование адресов), может потребоваться «трансляция» или иное преобразование одних протоколов L2 в другие. Например, если экземпляр IPLS имеет AC типов Ethernet и Frame Relay, на которых работает IPv4, может потребоваться взаимодействие между ARP и Inverse ARP.

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

Экземпляр IPLS должен иметь свое значение MTU и при наличии разных AC с разными MTU для всех должно применяться одно значение. Если AC не может менять MTU, ему не будет разрешено входить в экземпляр IPLS.

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

Раздел вопросов безопасности в документе с требованиями к L2VPN [RFC4665] рассматривает множество потенциально небезопасных аспектов L2VPN. Это связано с вопросами безопасности на уровнях данных и управления, которые могут возникать в разных местах:

  • сеть провайдера;

  • сеть абонента;

  • интерфейс между сетями провайдера и абонента.

Эти три области рассматриваются ниже.

4.1. Вопросы безопасности сети провайдера

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

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

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

Если применяется динамическое обнаружение партнеров (с помощью той или иной процедуры), процедура обнаружения должна обеспечивать достаточный уровень доверия.

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

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

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

Для снижения влияния DoS-атак24 на PE могут применяться меры ограничения скорости обработки трафика управления.

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

Если PE не может обслуживать большие объемы группового трафика в установившемся состоянии, это открывает возможность для атак на отказ служб VPLS путем передачи PE большого числа кадров с групповыми адресами получателей в поле MAC DA. Похожие атаки можно организовать путем передачи PE большого числа кадров с обманными адресами MAC SA. Обманные адреса могут заполнить таблицы MAC в PE и в результате кадры для реальных MAC-адресов будут рассылаться в лавинном режиме (т. е. по групповым адресам). Отметим, что такая лавинная рассылка может нарушать конфиденциальной этой или иной сети на базе мостов.

4.2. Вопросы безопасности на границе сетей

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

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

  • корректность настройки абонентского интерфейса;

  • предотвращение несанкционированного доступа к PE;

  • предотвращение несанкционированного доступа к конкретному порту PE;

  • корректность полей разграничения сервиса (VLAN, DLCI и т. п.).

Поскольку сетями доступа для сервиса L2VPN являются сети L2, предположительно использование механизмов проверки подлинности, не предполагающих возможностей IP на устройствах CE.

Имеются протоколы L2 и позитивный опы их применения для защиты сетей. Например, протокол IEEE 802.1x определяет аутентификацию на уровне канала доступа к мосту Ethernet, расширение Frame Relay Forum (FRF.17) определяет расширения LMI для проверки подлинности.

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

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

В VPWS на устройствах CE можно применять IPsec для взаимной аутентификации. Другие протоколы L3 или L4 могут иметь свои методы проверки подлинности.

В VPLS применение IPsec между устройствами CE более проблематично, поскольку IPsec не поддерживает многоточечных конфигураций, обеспечиваемых сервисом VPLS.

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

Процедуры L2VPN не обеспечивают аутентификации, защиты целостности и конфиденциальности абонентского трафика. Если такая защита нужна, ответственность за нее ложится на абонента. Для абонентов, которым реально требуются такие услуги или у которых нет доверия к сервис-провайдеру в части обеспечения защиты рассмотренная здесь схема L2VPN может не подойти. Такие абоненты могут рассмотреть другие схемы L2VPN, основанные не на наложенных псевдопроводах, а на наложенных туннелях IPsec, конечные точки которых размещаются на сайтах абонента. Однако эти вопросы выходят за рамки документа.

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

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

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

Этот документ является результатом дискуссий в команде по организации L2 VPN, все члены которой могут считаться соавторами документа. Особенно следует отметить Loa Andersson, Waldemar Augustyn, Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti Kompella, Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile Radoaca, Eric Rosen и Tissa Senevirathne.

Авторы благодарны Marco Carugi за поддержку в организации контекста, направлений работы и время, потраченное на обсуждения, Tove Madsen и Pekka Savola за ценный вклад и отзывы, а также Norm Finn, Matt Squires и Ali Sajassi за полезное обсуждение вопросов VPLS.

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

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

[RFC3985] Bryant, S. and P. Pate, «Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture», RFC 3985, March 2005.

[RFC4026] Andersson, L. and T. Madsen, «Provider Provisioned Virtual Private Network (VPN) Terminology», RFC 4026, March 2005.

[RFC4665] Augustyn, W., Ed. and Y. Serbest, Ed., «Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs)», RFC 4665, September 2006.

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

[IEEE8021D] IEEE 802.1D-2003, «IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges»

[IEEE8021Q] IEEE 802.1Q-1998, «IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks»

[RFC1771] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 199525.

[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, «Layer Two Tunneling Protocol «L2TP»», RFC 2661, August 1999.

[RFC2796] Bates, T., Chandra, R., and E. Chen, «BGP Route Reflection — An Alternative to Full Mesh IBGP», RFC 2796, April 200026.

[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, «LDP Specification», RFC 303627, January 2001.

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

Loa Andersson

Acreo AB

EMail: loa@pi.se

Eric C. Rosen

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

EMail: erosen@cisco.com

Waldemar Augustyn

EMail: waldemar@wdmsys.com

Marty Borden

EMail: mborden@acm.org

Juha Heinanen

Song Networks, Inc.

Hallituskatu 16

33200 Tampere, Finland

EMail: jh@song.fi

Kireeti Kompella

Juniper Networks, Inc.

1194 N. Mathilda Ave

Sunnyvale, CA 94089

EMail: kireeti@juniper.net

Vach Kompella

TiMetra Networks

274 Ferguson Dr.

Mountain View, CA 94043

EMail: vach.kompella@alcatel.com

Marc Lasserre

Riverstone Networks

5200 Great America Pkwy

Santa Clara, CA 95054

EMail: mlasserre@lucent.com

Pascal Menezies

EMail: pascalm1@yahoo.com

Hamid Ould-Brahim

Nortel Networks

P O Box 3511 Station C

Ottawa, ON K1Y 4H7, Canada

EMail: hbrahim@nortelnetworks.com

Vasile Radoaca

Nortel Networks

600 Technology Park

Billerica, MA 01821

EMail: radoaca@hotmail.com

Tissa Senevirathne

1567 Belleville Way

Sunnyvale CA 94087

EMail: tsenevir@hotmail.com


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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

1Layer 2 Provider Provisioned Virtual Private Network.

2Virtual Private Network.

3Service Provider.

4Virtual Private Wire Service — услуги виртуального частного провода (соединения).

5Virtual Private LAN Service — услуги виртуальной частной ЛВС.

6IP-only LAN-like Service — подобный ЛВС сервис, поддерживающий только протокол IP.

7Wide Area Network.

8Pseudowire.

9User-Facing PE — обращенное к абоненту устройство PE.

10Network-Facing PE — обращенное к сети устройство PE.

11Virtual Switching Instance.

12Attachment Circuit.

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

14Service level Specification — спецификация уровня обслуживания.

15Quality of Service — качество обслуживания.

16Service Level Agreement — соглашение об уровне обслуживания.

17Class of Service — класс обслуживания. Прим. перев.

18Permanent Virtual Circuit — постоянное виртуальное устройство (канал). Прим. перев.

19Switched Virtual Circuit — коммутируемое виртуальное устройство (канал). Прим. перев.

20Virtual Switch Instance.

21Source Address — адрес отправителя.

22Destination Address — адрес получателя.

23Spanning tree protocol — протокол связующего дерева.

24Denial of Service — отказ в обслуживании.

25Ссылка ошибочна, поскольку RFC 1771 был отменен RFC 4271, см. https://www.rfc-editor.org/errata/eid902. Прим. перев.

26Ссылка ошибочна, поскольку RFC 2796 был отменен RFC 4456, см. https://www.rfc-editor.org/errata/eid902. Прим. перев.

27Документ заменен RFC 5036. Прим. перев.




RFC 4675 RADIUS Attributes for Virtual LAN and Priority Support

Network Working Group                                     P. Congdon
Request for Comments: 4675                                M. Sanchez
Category: Standards Track                    Hewlett-Packard Company
                                                            B. Aboba
                                               Microsoft Corporation
                                                      September 2006

 

 

Атрибуты RADIUS для поддержки VLAN и приоритета

RADIUS Attributes for Virtual LAN and Priority Support

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

В этом документе предложены дополнительные атрибуты RADIUS1 для выделения VLAN2 и приоритизации, используемые в целях контроля доступа к локальным сетям IEEE 802. Эти атрибуты могут использоваться с протоколами RADIUS и Diameter.

Оглавление

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

1. Введение

Этот документ описывает атрибуты VLAN и изменения приоритизации, которые могут быть полезны для управления доступом в локальные сети IEEE 802 [IEEE-802] с использованием протокола RADIUS или Diameter.

Хотя [RFC3580] разрешает присваивание VLAN на основе атрибутов туннеля, определенных в [RFC2868], в этом случае не обеспечивается поддержка более полного набора функций VLAN, определенного в стандарте [IEEE-802.1Q]. Атрибуты, определенные в данном документе, обеспечивают для протоколов RADIUS и Diameter аналоги переменных управления, поддерживаемых в [IEEE-802.1Q] и объектах MIB, которые определены в [RFC4363]. Кроме того, этот документ разрешает поддержку более широкого диапазона конфигураций [IEEE-802.1X].

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

В этом документе используются следующие термины:

Network Access Server (NAS) – сервер доступа в сеть

Устройство, которое обеспечивает для пользователей услуги по предоставлению доступа в сеть. Для таких устройств также используется обозначение RADIUS client.

RADIUS server – сервер RADIUS

Сервер аутентификации RADIUS представляет собой объект, обеспечивающий сервис аутентификации для NAS.

RADIUS proxy

RADIUS-прокси действует как сервер аутентификации для NAS и клиент RADIUS для RADIUS-сервера.

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

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

1.3. Интерпретация атрибутов

Описанные в этом документе атрибуты применяются к одному экземпляру порта NAS (точнее говоря, к одному порту моста IEEE 802.1Q). Стандарты [IEEE-802.1Q], [IEEE-802.1D] и [IEEE-802.1X] не распознают более тонкое разделение, нежели уровень порта. В некоторых случаях (например, в беспроводных ЛВС IEEE 802.11) вместо физических портов используется понятие виртуального порта. Такие виртуальные порты обычно связаны с защищенными соедиениями3 и представляются как станция или MAC4-адрес.

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

Если соответствующий данной спецификации сервер NAS получает пакет Access-Accept, содержащий определенный в этом документе атрибут, который сервер не может применить, сервер должен действовать как при получении пакета Access-Reject. [RFC3576] требует, чтобы сервер NAS, получивший запрос CoA-Request5, отвечал на него пакетом CoA-NAK, если запрос включает неподдерживаемый атрибут. Рекомендуется включать в такой пакет CoA-NAK атрибут Error-Cause со значением Unsupported Attribute (401). Как указано в [RFC3576], смена авторизации является атомарной операцией, поэтому в такой ситуации не происходит разрыва сеанса и существующая конфигурация остается неизменной. В результате генерировать пакет учета (accounting) не следует.

2. Атрибуты

2.1. Egress-VLANID

Атрибут Egress-VLANID представляет разрешенное значение IEEE 802 Egress VLANID для этого порта, показывающее какие значения VLANID разрешены для кадров с тегами и без тегов.

Как определено в [RFC3580], VLAN, выделенные с помощью туннельных атрибутов, применимы как к входящим VLANID для пакетов без тегов (PVID), так и к исходящим VLANID для пакетов без тегов. В противоположность этому атрибут Egress-VLANID задает лишь значение исходящего идентификатора VLANID для пакетов с тегами и без тегов. Атрибут Egress-VLANID можно включать в пакет RADIUS с туннельными атрибутами [RFC3580]; однако атрибут Egress-VLANID не является обязательным, если он используется для пакетов без тегов с тем же значением VLANID, которое включено в атрибуты туннеля. Для настройки VLAN без тегов в обоих направлениях должны использоваться атрибуты [RFC3580].

В пакеты Access-Request, Access-Accept, CoA-Request или Accounting-Request можно включать множество атрибутов Egress-VLANID; этот атрибут недопустимо передавать в пакетах Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK и CoA-NAK. Каждый атрибут добавляет указанную сеть VLAN к списку виртуальных ЛВС, разрешенных на выходе из данного порта.

Формат атрибута Egress-VLANID показан на рисунке. Поля передаются в порядке слева направо.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |            Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Value (продолж.)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 56

Length 6

Value

Поле Value состоит из 4 октетов. Формат поля показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Tag Indic.   |        Pad            |       VLANID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле Tag Indication имеет размер 1 октет и показывает, содержат (0x31) или не содержат (0x32) теги кадры VLAN. Поле заполнения (Pad) имеет размер 12 битов и должно иметь значение 0. 12-битовое поле VLANID содержит идентификатор VLAN VID [IEEE-802.1Q].

2.2. Ingress-Filters

Атрибут Ingress-Filters соответствует переменной Ingress Filter определенной для порта в стандарте [IEEE-802.1Q] (п. 8.4.5). Когда этот атрибут имеет значение Enabled, набор VLAN, разрешенных на входе в порт, должен соответствовать набору VLAN, разрешенных на выходе из порта. Можно включать лишь один атрибут Ingress-Filters в пакеты Access-Request, Access-Accept, CoA-Request, Accounting-Request и недопустимо включение этого атрибута в пакеты Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK или CoA-NAK.

Формат атрибута Ingress-Filters показан на рисунке. Поля передаются в порядке слева направо.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |         Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Value (продолж.)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 57

Length 6

Value

Поле Value имеет размер 4 октета и может включать значения:

1 – Enabled (разрешено);

2 – Disabled (запрещено).

2.3. Egress-VLAN-Name

Пункт 12.10.2.1.3 (a) стандарта [IEEE-802.1Q] описывает административно присваиваемые имена VLAN, связанные VLAN-ID, определенными для моста IEEE 802.1Q. Атрибут Egress-VLAN-Name представляет разрешенную VLAN для данного порта. Этот атрибут похож на Egress-VLANID, но отличается тем, что само значение VLAN-ID не задается и его не нужно знать; вместо идентификатора используется имя VLAN, позволяющее идентифицировать VLAN внутри данной системы.

Туннельные атрибуты, описанные в [RFC3580] могут вместе с Egress-VLAN-Name использоваться для настройки выходных VLAN в случае пакетов без тегов. Эти атрибуты могут использоваться одновременно и их можно включать в один пакет RADIUS. Когда атрибуты используются одновременно, список разрешенных VLAN представляет собой конкатенацию атрибутов Egress-VLAN-Name и Tunnel-Private-Group-ID (81). Атрибут Egress-VLAN-Name не меняет входную VLAN (называется также PVID) для пакетов без тегов на данном порту. Следует использовать туннельные атрибуты [RFC3580] вместо установки PVID.

Атрибут Egress-VLAN-Name содержит две части – первая показывает формат кадров VLAN (с тегами или без них), а вторая содержит имя VLAN.

Можно включать множество атрибутов Egress-VLAN-Name в пакеты Access-Request, Access-Accept, CoA-Request и Accounting-Request, но не допускается включение этого атрибута в пакеты Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK или CoA-NAK. Каждый атрибут добавляет именованную сеть VLAN в список разрешенных на выходе из порта VLAN. Формат атрибута Egress-VLAN-Name показан на рисунке. Поля передаются в порядке слева направо.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |   Tag Indic.  |   String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Type 58

Length >=4

Tag Indication

Поле Tag Indication имеет размер 1 октет и показывает наличие (0x31, ASCII ‘1’) или отсутствие (0x32, ASCII ‘2’) тегов в кадрах VLAN. Значения были выбраны для упрощения пользователям ввода нужного варианта.

String

Поле String имеет размер не менее 1 октета и содержит значение VLAN Name, как определено в стандарте [IEEE-802.1Q] п. 12.10.2.1.3 (a). [RFC3629] рекомендует использовать символы ISO6 10646 в кодировке UTF-8, но реализациям следует поддерживать трактовку этого поля без связи с кодировкой символов.

2.4. User-Priority-Table

В стандарте [IEEE-802.1D] п. 7.5.1 обсуждается вопрос регенерации (или повторного отображения) установленного для пользователя приоритета в кадрах, получаемых портом. Независимая для каждого порта конфигурация позволяет мосту устанавливать для полученных через порт кадров определенный уровень приоритета. В п. 6.3.9 [IEEE-802.1D] описано использование такой приоритизации:

Возможность указать приоритет пользователя в ЛВС IEEE 802 позволяет организовать сквозную значимость уровня приоритета в масштабе ЛВС на базе мостов (Bridged Local Area Network). В комбинации с отображением приоритета на классы трафика и приоритет доступа это позволяет обеспечить согласованное использование данных о приоритете в соответствии с возможностями мостов и MAC на пути передачи…

При нормальных условиях приоритет не изменяется в процессе передачи через функцию трансляции моста; однако система управления сетью может контролировать распространение уровня приоритета пользователя. Таблица 7-1 обеспечивает возможность отобразить входящие значения приоритета независимо для каждого порта. По умолчанию регенерированное значение приоритета совпадает с полученным значением.

Этот атрибут представляет приоритизацию IEEE 802, которая будет использоваться для всех кадров, приходящих в порт. Стандарт [IEEE-802] определяет 8 значений приоритета. Пункт 14.6.2.3.3 стандарта [IEEE-802.1D] задает таблицу регенерации как 8 целочисленных значений в диапазоне 0-7. Переменные управления определены в п. 14.6.2.2.

Один атрибут User-Priority-Table можно включать в пакеты Access-Accept и CoA-Request; не допускается включение этого атрибута в пакеты Access-Request, Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, CoA-NAK и Accounting-Request. Поскольку таблица регенерации поддерживается только мостами, соответствующими стандарту [IEEE-802.1D], этот атрибут следует передавать только тем клиентам RADIUS, которые поддерживают этот стандарт.

Формат атрибута User-Priority-Table показан на рисунке. Поля передаются в порядке справа налево.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |  Length       |          String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              String            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 59

Length 10

String

Поле String имеет размер 8 октетов и включает таблицу, которая отображает входящий уровень приоритета (если он установлен; по умолчанию 0) на один из 8 регенерируемых уровней. Первый октет отображает уровень 0 для входящего приоритета, второй – уровень 1 и т. д. Значение каждого октета представляет регенерируемый уровень приоритета для кадра.

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

В спецификации [IEEE-802.1D] (Annex G) содержится полезное описание отображений типа трафика в классы трафика.

3. Таблица атрибутов

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

Access-Request Access-Accept Access-Reject Access-Challenge CoA-Req Acct-Req Аттрибут

0+

0+

0

0

0+

0+

56

Egress-VLANID

0-1

0-1

0

0

0-1

0-1

57

Ingress-Filters

0+

0+

0

0

0+

0+

58

Egress-VLAN-Name

0

0-1

0

0

0-1

0

59

User-Priority-Table

Значения ячеек таблицы имеют следющий смысл:

0 этот атрибут недопустимо включать в пакеты данного типа;

0+ в пакете может присутствовать 0 и более экземпляров данного атрибута;

0-1 в пакете может присутствовать не более 1 экземпляра данного атрибута.

4. Протокол Diameter

При использовании с протоколом Diameter атрибуты, определенные в этой спецификации, могут применяться как пары атрибут-значение (AVP7) из пространства кодов 1-255 (пространство совместимости с атрибутами RADIUS). Следовательно, дополнительных значений Diameter Code не выделяется. Типы данных и правила флагов для атрибутов приведены в таблице.

Имя Тип Правила AVP Flag
MUST MAY SHOULD NOT MUST NOT Encr
Egress-VLANID OctetString

M

P

V

Y

Ingress-Filters Enumerated

M

P

V

Y

Egress-VLAN-Name UTF8String

M

P

V

Y

User-Priority-Table OctetString

M

P

V

Y

Для атрибутов из данной спецификации не устанавливается специальных требований перобразования из Diameter в RADIUS и обратно; атрибуты копируются в исходном виде за исключением изменений, относящихся к заголовкам, выравниванию и заполнению. Дополнительную информацию можно найти в [RFC3588] (параграф 4.1) и [RFC4005] (глава 9).

Все, что в данной спецификации сказано о применимости атрибутов к пакетам RADIUS Access-Request, относится и к Diameter AA-Request [RFC4005] или Diameter-EAP-Request [RFC4072]. Все, что применимо к пакетам Access-Challenge, относится также к Diameter AA-Answer [RFC4005] и Diameter-EAP-Answer [RFC4072] с Result-Code AVP = DIAMETER_MULTI_ROUND_AUTH.

Все, что сказано о Access-Accept, применимо и к сообщениям Diameter AA-Answer или Diameter-EAP-Answer, показывающим успешное завершение. Аналогично, все, что сказано о пакетах RADIUS Access-Reject, относится также к сообщениям Diameter AA-Answer и Diameter-EAP-Answer, показывающим отказ.

Все сказанное о пакетах COA-Request применимо к Diameter Re-Auth-Request [RFC4005].

Все сказанное о пакетах Accounting-Request применимо также к Diameter Accounting-Request [RFC4005].

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

Эта спецификация не создаете каких-либо новых реестров.

Данный документ использует пространство имен RADIUS [RFC2865]; см. http://www.iana.org/assignments/radius-types. Добавление 4 значений в раздел «RADIUS Attribute Types» выполнено IANA. Добавленными атрибутами RADIUS являются:

56 — Egress-VLANID

57 — Ingress-Filters

58 — Egress-VLAN-Name

59 — User-Priority-Table

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

Эта спецификация описывает использование протоколов RADIUS и Diameter для идентификации, проверки полномочий и учета в локальных сетях IEEE 802. Вопросы безопасности, связанные с протоколом RADIUS для таких приложений, описаны в [RFC3579] и [RFC3580]; проблемы безопасности, связанные с роумингом, рассмотрены в [RFC2607]. Для протокола Diameter вопросы безопасности, связанные с такими приложениями, рассмотрены в [RFC4005] и [RFC4072].

Данный документ определяет новые атрибуты, которые могут включаться в существующие пакеты RADIUS, и защищаются, как описано в [RFC3579] и [RFC3576]. Для протокола Diameter атрибуты защищаются в соответствии с документом [RFC3588], содержащим детальное описание этой задачи.

Механизмы защиты, поддерживаемые в RADIUS и Diameter, фокусируются на предотвращении подмены пакетов атакующим или изменения пакетов в процессе доставки. Эти механизмы не защищают уполномоченные серверы или посредников (proxy) RADIUS/Diameter от вставки атрибутов с деструктивными целями.

Атрибуты VLAN, передаваемые сервером или посредником RADIUS/Diameter, могут разрешить доступ к сетям VLAN, для которых отсутствуют полномочия. Значение этой уязвимости может быть ограничено путем проверки на уровне NAS. Например, сервер NAS можно настроить на восприятие только некоторого подмножества значений VLANID от данного сервера или посредника RADIUS/Diameter.

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

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

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

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

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, June 2000.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, «Diameter Base Protocol», RFC 3588, September 2003.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC4363] Levi, D. and D. Harrington, «Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions», RFC 4363, January 2006.

[IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 199010.

[IEEE-802.1D] IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges, IEEE Std 802.1D-200411, June 2004.

[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 200312.

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

[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-200413, December 2004.

[RFC2607] Aboba, B. and J. Vollbrecht, «Proxy Chaining and Policy Implementation in Roaming», RFC 2607, June 1999.

[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, «RADIUS Attributes for Tunnel Protocol Support», RFC 2868, June 2000.

[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, «Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)», RFC 3576, July 2003.

[RFC3579] Aboba, B. and P. Calhoun, «RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)», RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, «IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines», RFC 3580, September 2003.

[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, «Diameter Network Access Server Application», RFC 4005, August 2005.

RFC4072] Eronen, P., Hiller, T., and G. Zorn, «Diameter Extensible Authentication Protocol (EAP) Application», RFC 4072, August 2005.

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

Авторы рады отметить Joseph Salowey из Cisco, David Nelson из Enterasys, Chuck Black из Hewlett-Packard и Ashwin Palekar из Microsoft.

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

Paul Congdon

Hewlett-Packard Company

HP ProCurve Networking

8000 Foothills Blvd, M/S 5662

Roseville, CA 95747

Phone: +1 916 785 5753

Fax: +1 916 785 8478

EMail: paul.congdon@hp.com

Mauricio Sanchez

Hewlett-Packard Company

HP ProCurve Networking

8000 Foothills Blvd, M/S 5559

Roseville, CA 95747

Phone: +1 916 785 1910

Fax: +1 916 785 1815

EMail: mauricio.sanchez@hp.com

Bernard Aboba

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

Phone: +1 425 706 6605

Fax: +1 425 936 7329

EMail: bernarda@microsoft.com


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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


1Remote Authentication Dial-In User Service – служба аутентификации удаленных пользователей при коммутируемом доступе.

2Virtual LAN – виртуальная ЛВС

3В оригинале — security association – защищенная связь. Прим. перев.

4Media Access Control – контроль доступа к среде.

5Change of Authorization Request – смена авторизации.

6В оригинале слово ISO при указании набора символов по ошибке было пропущено. Прим. перев.

7Attribute-value pair — пара «атрибут-значение».

9Документ был частично обновлен в RFC 2868, RFC 3575, RFC 5080. Прим. перев.

10Современная версия этого стандарта доступна по ссылке http://standards.ieee.org/getieee802/download/802-2001.pdf. Прим. перев.

11Этот стандарт доступен по ссылке http://standards.ieee.org/getieee802/download/802.1D-2004.pdf. Прим. перев.

12Современная версия этого стандарта доступна по ссылке http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf. Прим. перев.

13Этот стандарт доступен по ссылке http://standards.ieee.org/getieee802/download/802.1X-2004.pdf. Прим. перев.




RFC 4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)

Network Working Group                                      P. Arberg
Request for Comments: 4638                           D. Kourkouzelis
Category: Informational                             Redback Networks
                                                          M. Duckett
                                                         T. Anschutz
                                                           BellSouth
                                                          J. Moisand
                                                    Juniper Networks
                                                      September 2006

 

Согласование для протокола PPPoE значений MTU/MRU более 1492

Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU)

Greater Than 1492 in the

Point-to-Point Protocol over Ethernet (PPPoE)

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Замечание IESG

На момент создания этого документа не была стандарта IEEE, поддерживающего использование jumbo-кадров (MTU более 1500). Хотя в этом документе описан рекомендуемый механизм обнаружения проблем, связанных с использованием таких кадров, интероперабельность и надежность нестандартных расширений не может быть гарантирована. Разработчикам и пользователям описанного здесь протокола следует с осторожностью подходить к его применению.

Тезисы

Протокол PPPoE (Point-to-Point Protocol over Ethernet), описанный в RFC 2516, диктует ограничение на максимальное значение согласованного размера максимального принимаемого блока данных (MRU1) — 1492 октета. В этом документе предложено решение, позволяющее смягчить данное ограничение и позволить согласование значений MRU более 1492 для снижения уровня фрагментации в широкополосных сетях нового поколения.

Оглавление

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

1. Введение

Широкополосные сети переходят от инициируемых ПК сессий PPPoE [1] и инфраструктуры Ethernet/ATM (см. рисунок 1) к более интеллектуальным системам PPPoE со шлюзами RG2 и инфраструктурой Gigabit Ethernet/ATM (рис. 2 и 3), требуя при этом повышения максимального размера передаваемых и принимаемых блоков информации PPPoE для снижения уровня фрагментации пакетов в сети.

  <------------------ сессия PPPoE -------------------->

                                  +-----+           +----+
+--+              +---+           |     |           |    |
|PC|--------------|CPE|-----------|DSLAM|-----------|BRAS|
+--+  <Ethernet>  +---+   <ATM>   |     |   <ATM>   |    |
                                  +-----+           +----+

 Рисунок 1: Традиционная структура широкополосной сети PPPoE.

В схеме, показанной на рисунке 1, фрагментация обычно не вызывает проблем, поскольку абонентские сеансы PPPoE организуются между ПК и BRAS3. Следовательно, согласование для PPP значения MRU в 1492 октета приемлемо, поскольку оно обеспечивает возможность включения кадра PPPoE с максимальным размером в стандартный блок Ethernet MTU (1500 октетов).

  <----- IPoE -----> <--------- сессия PPPoE --------->

                                 +-----+            +----+
+--+              +--+           |     |            |    |
|PC|--------------|RG|-----------|DSLAM|------------|BRAS|
+--+  <Ethernet>  +--+   <ATM>   |     |   <GigE>   |    |
                                 +-----+            +----+

Рисунок 2: Структура сети PPPoE нового поколения.

В сети, показанной на рисунке 2, фрагментация становится основной проблемой, поскольку абонентская сессия объединяет в себе IPoE и PPPoE. Протокол IPoE обычно использует значение MTU в 1500 октетов. Однако, когда шлюз RG и концентратор BRAS являются конечными точками сессий PPPoE и, следовательно, не могут согласовать между собой значения MTU/MRU более 1492 октетов, в результате в сети существенно повышается уровень фрагментации пакетов.

  <----- IPoE -----> <---- PPPoA ----> <- сессия PPPoE ->

                                  +-----+            +----+
+--+              +--+            |     |            |    |
|PC|--------------|RG|------------|DSLAM|------------|BRAS|
+--+  <Ethernet>  +--+    <ATM>   |     |   <GigE>   |    |
                                  +-----+            +----+


  <-------------- PPPoA -------------> <- сессия PPPoE ->

                                   +-----+           +----+
+--+              +---+            |     |           |    |
|PC|--------------|CPE|------------|DSLAM|-----------|BRAS|
+--+    <ATM>     +---+    <ATM>   |     |   <GigE>  |    |
                                   +-----+           +----+

Рисунок 3: Широкополосная сеть с преобразованием PPPoA-PPPoE

В показанной на рисунке 3 схеме сети, которая исследовалась в DSL-Forum в контексте перехода к Ethernet для широкополосных объединенных сетей4, фрагментация не является единственной проблемой, когда существует различие между MRU для сеансов PPPoA (Point-to-Point Protocol over AAL5) и PPPoE.

Пользовательская сессия представляет собой сеанс PPP, работающий через комбинацию PPPoA и PPPoE. Хост PPP/PPPoA обычно согласует значение 1500 октетов для MRU. Широко распространенные хосты PPP/PPPoA в оборудовании CPE (Customer Premises Equipment) не поддерживают MRU в 1492 октета, что создает проблему для BRAS (сервер PPPoE) при строгом выполнении требований RFC 2516 [1]. Если хосты PPP/PPPoA способны согласовать MRU=1492, мы возвращаемся к проблеме фрагментации.

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

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

ATM — асинхронный режим передачи (Asynchronous Transfer Mode)

PPP — протокола связи “точка-точка” (Point-to-Point Protocol)

PPPoA — протокол PPP через AAL5 (PPP over AAL5)

PPPoE — протокол PPP через Ethernet (PPP over Ethernet)

MTU — максимальный размер передаваемого блока (Maximum Transmit Unit)

MRU — максимальный размер принимаемого блока (Maximum Receive Unit)

PC — персональный компьютер (Personal Computer)

CPE — оборудование, размещенное у абонента (Customer Premises Equipment)

RG — шлюз, расположенный в жилом районе (Residential Gateway)

BRAS — широкополосный сервер удаленного доступа (Broadband Remote Access Server)

DSLAM — мультиплексор цифровых абонентских линий доступа (Digital Subscriber Line Access Multiplexer)

PPPoE client — клиентский ПК, RG или CPE, инициирующие сеанс PPPoE

PPPoE server — сервер BRAS, завершающий инициированную клиентом сессию PPPoE

PADI — пакет обнаружения сервера (PPPoE Active Discovery Initiation)

PADO — пакет с предложением услуг от сервера (PPPoE Active Discovery Offer)

PADR — запрос на обслуживание клиента (PPPoE Active Discovery Request)

PADS — подтверждение сеанса PPPoE (PPPoE Active Discovery Session-confirmation)

3. Предлагаемое решение

Процедура, описанная в этом документе, не соответствует в точности требованиям стандартов IEEE для размера пакетов Ethernet, но она основана на широко распространенных кадрах с форматом Ethernet, хотя их размер превышает максимально допустимое значение, заданное в [4].

Поскольку широкополосные сети нового поколения строятся на базе систем Ethernet, поддерживающих кадры baby-giants и jumbo с размером поля данных, превышающим обычное значение Ethernet MTU в 1500 октетов, устройства BRAS, действующие как серверы PPPoE, должны поддерживать для PPPoE MRU согласование значений более 1492 октетов, чтобы ограничить уровень фрагментации пакетов в сети, как было сказано в главе 1.

По умолчанию опция MRU должна соответствовать требованиям RFC 1661 [2], но недопустимо согласовывать значения более 1492 для обеспечения совместимости с сегментами сетей Ethernet, в которых размер кадра ограничен 1500 октетами. Заголовок PPPoE занимает 6 октетов, а идентификатор PPP Protocol ID — 2 октета, что в результате и делает недопустимым для PPP MRU использование значений более 1492.

Необязательный тег PPPoE PPP-Max-Payload позволяет клиенту PPPoE изменить принятое по умолчанию поведение, задавая для информационного поля PPP максимальное значение, поддерживаемое в обоих направлениях. Когда сервер PPPoE получает такой тег, он может разрешить согласование значения MRU > 1492 и использовать значения MTU > 1492, в зависимости от заданных локальной конфигурацией параметров и в соответствии с правилами, установленными RFC 1661 [2], а также учитывая максимальный размер информационного поля, заданный клиентом PPPoE.

4. Этап PPPoE Discovery

Если клиент PPPoE желает использовать значение MTU/MRU более 1492 октетов, он должен включить тег PPP-Max-Payload в пакеты PADI и PADR. Если сервер PPPoE может поддерживать MTU/MRU более 1492 октетов, он должен скопировать полученный от клиента тег PPP-Max-Payload в передаваемые клиенту пакеты PADO и PADS.

Tag-name: PPP-Max-Payload

Tag-value: 0x0120

Tag-length: 2 октета

Tag-value: бинарное значение (максимальный размер поля данных PPP в октетах)

Описание тега

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

5. Вопросы LCP

5.1. Согласование MRU

Поскольку для Ethernet (без кадров jumbo) максимальный размер данных ограничен 1500 октетами, заголовок PPPoE занимает 6 октетов, а поле PPP Protocol ID – 2 октета, для опции MRU (Maximum-Receive-Unit) недопустимо согласовывать значение более 1492 октетов, если клиент и сервер PPPoE не указали свою возможность использования больших значений MRU на этапе PPPoE Discovery.

Начальное согласование MRU для сервера PPP/PPPoE должно следовать приведенной ниже процедуре:

If PPPoE {
   PPP_MRU_Max = 1492
   If (PPP-Max-Payload-Tag) AND (PPP-Max-Payload-Tag > 1492)
      Then PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)
}
нормальная процедура PPP_MRU_Negotiation (PPP_MRU_Max)

Если присутствует тег PPP-Max-Payload со значением более 1492, это значение должно рассматриваться наряду с установками MTU для интерфейсов сервера при нормальном согласовании в соответствии RFC 1661 [2] используемого протоколом значения MRU.

Если тег PPP-Max-Payload не задан или указывает значение меньше 1492, существующее для MRU ограничение 1492 должно сохранять свою применимость в целях обеспечения совместимости с более ранними версиями.

Таким образом, в результате имеет место следующее поведение:

  1. При получении тега PPP-Max-Payload
  1. Значение этого тега показывает значение MRU, допущенное или предложенное при согласовании MRU.
  2. Если значение MRU не согласовано, RFC 1661 [2] будет задавать принятое по умолчанию значение MRU = 1500.
    Это говорит о том, что тег PPP-Max-Payload может указывать значение более 1500, но в этом случае RFC 1661 [2] установит принятое по умолчанию значение 1500, а заданное тегом PPP-Max-Payload большее значение может быть использовано только в тех случаях, когда согласовано достаточно большое значение MRU (вплоть до максимального размера поля данных).
  1. Если тег PPP-Max-Payload не получен ни одной из сторон, используется правило, заданное в RFC 2516 [1].

5.2. Тестирование MRU и поиск неполадок

Если для MRU согласовано значение более 1492 октетов, передающей стороне следует иметь опцию для передачи одного или более пакета Echo-Request размером MRU в начале сеанса. Это позволит убедиться в том, что принимающая сторона, все промежуточные сегменты Ethernet и оборудование могут работать с пакетами такого размера.

Если в ответ не было получено откликов Echo-Reply, передающая сторона может повторить проверку с помощью пакетов Echo-Request размером 1492 октета. Если на эти пакеты будут получены отклики, передающая сторона должна отправлять в этой сессии пакеты размером не более 1492 октетов.

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

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

Этот документ не создает новых проблем, связанных с безопасностью. Вопросы безопасности, относящиеся к исходному протоколу PPPoE [1], сохраняют свою актуальность.

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

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

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

Авторы выражают свою признательность Prakash Jayaraman, Amit Cohen, Jim Ellis, David Thorne, John Reid, Oliver Thorp, Wojciech Dec, Jim Wilks, Mark Townsley, Bart Salaets, Tom Mistretta, Paul Howard, Dave Bernard и Darren Nobel за их вклад и комментарии к документу.

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

[1] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, «A Method for Transmitting PPP Over Ethernet (PPPoE)», RFC 2516, February 1999.

[2] Simpson, W., «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

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

[4] Institute of Electrical and Electronic Engineers, IEEE Std 802.3-20056, «IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications — Draft amendment to – Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks – Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Media Access Control Parameters, Physical Layers and Management Parameters», December 2005.

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

[5] Arberg, P. and V. Mammoliti, «IANA Considerations for PPP over Ethernet (PPPoE), Work in Progress7, June 2006.

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

Peter Arberg

Redback Networks, Inc.

300 Holger Way

San Jose, CA 95134

EMail: parberg@redback.com

Diamantis Kourkouzelis

Redback Networks, Inc.

300 Holger Way

San Jose, CA 95134

EMail: diamondk@redback.com

Mike Duckett

BellSouth Telecommunications, Inc.

575 Morosgo Drive

Atlanta, GA 30324

EMail: mike.duckett@bellsouth.com

Tom Anschutz

BellSouth Science and Technology

725 W. Peachtree St.

Atlanta, GA 30308

EMail: tom.anschutz@bellsouth.com

Jerome Moisand

Juniper Networks, Inc.

10 Technology Park Drive

Westford, MA 01886

EMail: jmoisand@juniper.net


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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


1Maximum Receive Unit

2Residential Gateway – шлюз в жилом районе.

3Broadband Remote Access Server – широкополосный концентратор удаленного доступа.

4В оригинале aggregation networks.

6Современная редакция этого стандарта доступна на сайте http://standards.ieee.org/getieee802/802.3.html. Прим. перев.

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