RFC 2246 The TLS Protocol Version 1.0

Network Working Group                                      T. Dierks
Request for Comments: 2246                                  Certicom
Category: Standards Track                                   C. Allen
                                                            Certicom
                                                        January 1999

Протокол TLS v.1.0

The TLS Protocol
Version 1.0

PDF

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

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

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

Тезисы

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

Оглавление

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

1. Введение

Основной задачей протокола TLS является обеспечение конфиденциальности и целостности данных, передаваемых между двумя коммуникационными приложениями. Протокол включает два уровня: TLS Record Protocol и TLS Handshake Protocol. Нижний уровень, расположенный поверх того или иного транспортного протокола с гарантией доставки (например, TCP [TCP]), называется протоколом TLS Record. Этот протокол обеспечивает безопасность соединений и обладает двумя основными свойствами.

  • Конфиденциальность соединения. Для шифрования данных используется симметричная схема (например, DES [DES], RC4 [RC4] и т. п.). Уникальные ключи для симметричного шифрования генерируются для каждого соединения на основе секретного ключа, согласованного с помощью другого протокола (например, TLS Handshake). Протокол Record может использоваться и без шифрования.

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

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

  • Идентификация и аутентификация партнера может проводиться с использованием асимметричных или открытых ключей (например, RSA [RSA], DSS [DSS] и т. п). Такая аутентификация не является обязательной, но в общем случае требуется по крайней мере на одной стороне.

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

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

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

2. Назначение протокола

Основными целями протокола TLS (в порядке важности) являются:

  1. Криптографическая защита – протокол TLS следует использовать для организации защищенных соединений между парами точек.

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

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

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

3. Назначение документа

Протокол TLS и описанная в данном документе спецификация этого протокола основаны на спецификации протокола SSL 3.0, опубликованной компанией Netscape. Различия между SSL 3.0 и TLS не критичны, но достаточно существенны — протоколы TLS 1.0 и SSL 3.0 не могут взаимодействовать, хотя TLS 1.0 и включает механизм совместимости с SSL 3.0. Данный документ адресован прежде всего читателям, планирующим реализовать протокол или выполняющим его криптографический анализ. Спецификация протокола написана с учетом требований этих двух групп. По этой причине многие зависящие от алгоритма структуры данных и правила включены в текст документа (а не в приложения), чтобы упростить доступ к информации об этих структурах и правилах.

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

 4. Язык представления

Этот документ имеет дело с форматированием данных для внешнего представления. В документе используется очень простой синтаксис похожий на синтаксис языка программирования C и синтаксис XDR [XDR]. Используемый в документе язык представления предназначен только для TLS и не имеет применения за пределами этого стандарта.

4.1. Размер базового блока

Представление всех элементов данных описано в явной форме. Базовый блок данных имеет размер 1 байт (8 битов). Многобайтовые элементы данных объединяются (конкатенация) слева направо и сверху вниз. Из байтового потока многобайтовый элемент (например, число) формируется следующим образом (используется нотация языка C):

значение = (байт[0] << 8*(n-1)) | (байт[1] << 8*(n-2)) | ... | байт[n-1];

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

4.2. Различные элементы

Текст комментария начинается с символов /* и заканчивается символами */.

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

Однобайтовые элементы, содержащие неинтерпретируемые данные, имеют тип opaque3.

4.3. Векторы

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

T T'[n];

Вектор T’ занимает n байтов в потоке данных, где значение n кратно размеру T. Размер вектора не включается в кодированный поток данных.

В приведенном ниже примере Datum определяется как три последовательных байта, которые протокол не интерпретирует, а Data – три последовательных элемента Datum, занимающих в общей сложности 9 байтов.

opaque Datum[3]; /* три неинтерпретируемых байта */
Datum Data[9]; /* 3 последовательных 3-байтовых вектора */

Векторы переменной длины определяются с указанием допустимого диапазона размеров (включая крайние значения) в форме <floor..ceiling>. При кодировании в поток данных перед самим вектором помещается реальный размер вектора. Размер задается в форме числа, занимающего столько байтов, сколько требуется для хранения максимального (ceiling) размера вектора. Вектор переменной длины, имеющий нулевой размер, указывается как пустой вектор.

T T'<floor..ceiling>;

В приведенном ниже примере mandatory представляет собой вектор типа opaque размером от 300 до 400 байтов. Такой вектор никогда не может быть пустым. Поле размера занимает два байта (uint16), что достаточно для записи максимальной длины вектора 400 (см. параграф 4.4). Вектор longer может представлять до 800 байтов данных или до 400 элементов uint16 и может быть пустым. Кодирование вектора включает двухбайтовое поле размера, предшествующее вектору. Размер кодированного вектора должен быть кратным размеру одного элемента (например, значение 17 для вектора uint16 будет некорректным).

opaque mandatory<300..400>; /* поле размера занимает 2 байта, вектор не может быть пустым */
uint16 longer<0..800>; /* от 0 до 400 16-битовых беззнаковых целых чисел */

4.4. Числа

Базовым числовым элементов является беззнаковый байт uint8. Все остальные типы чисел формируются из базового типа путем описанной в параграфе 4.1 конкатенации фиксированного числа байтов. Ниже перечислены предопределенные типы чисел.

uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];

Все числовые значения, используемые в данной спецификации, сохраняются в так называемом сетевом порядке байтов; число uint32, представленное в шестнадцатеричном формате 01 02 03 04, эквивалентно десятичному значению 16909060.

4.5. Перечисляемые значения

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

enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

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

enum { red(3), blue(5), white(7) } Color;

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

enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

Имена элементов перечисляемого типа доступны только в контексте данного типа. В первом примере полная ссылка на второй элемент типа Color будет иметь вид Color.blue. Полная форма представления не требуется, если целью присваивания является полностью определенный элемент.

Color color = Color.blue; /* полная спецификация – корректно всегда */
Color color = blue; /* корректно при заданном неявно типе */

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

enum { low, medium, high } Amount;

4.6. Конструируемые типы

Из примитивов могут создаваться структурированные типы. Каждая спецификация структурированного типа задает новый уникальный тип. Синтаксис описания идентичен синтаксису структур языка C.

struct {
    T1 f1;
    T2 f2;
    ...
    Tn fn;
} [[T]];

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

4.6.1. Варианты

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

struct {
    T1 f1;
    T2 f2;
    ....
    Tn fn;
    select (E) {
        case e1: Te1;
        case e2: Te2;
        ....
        case en: Ten;
    } [[fv]];
} [[Tv]];
Например,
enum { apple, orange } VariantTag;

struct {
    uint16 number;
    opaque string<0..10>; /* переменная длина */
} V1;

struct {
    uint32 number;
    opaque string[10];    /* фиксированный размер */
} V2;

struct {
    select (VariantTag) { /* значение селектора задано неявно */
        case apple: V1;   /* VariantBody, tag = apple */
        case orange: V2;  /* VariantBody, tag = orange */
    } variant_body;       /* необязательная метка варианта */
} VariantRecord;

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

orange VariantRecord

является суженным типом VariantRecord, содержащим вариант типа V2.

4.7. Атрибуты шифрования

Четыре варианта криптографических операций – цифровая подпись (digital signing), потоковое шифрование (stream cipher encryption), блочное шифрование (block cipher encryption) и шифрование с открытым ключом (public key encryption) обозначаются ключевыми словами digitally-signed, stream-ciphered, block-ciphered и public-key-encrypted, соответственно. Поля с криптографической обработкой указываются с предшествующим типу поля ключевым словом, задающим криптографическую операцию. Ключи шифрования определяются текущим состоянием сессии (см. параграф 6.1).

В режиме цифровой подписи для создания сигнатуры используется необратимая хэш-функция. Элемент с цифровой подписью кодируется как opaque-вектор <0..2^16-1>, длина которого определяется алгоритмом цифровой подписи и ключом.

При использовании RSA-подписей 36-байтовая структура включает два хэш-значения (SHA и MD5). Сигнатура кодируется с использованием PKCS #1 (блок типа 0 или 1, как описано в [PKCS1]).

В DSS 20-байтовое хэш-значение SHA создается напрямую с использованием алгоритма DSA без дополнительного хэширования (в результате создаются два значения — r и s). Сигнатура DSS представляет собой opaque-вектор, содержимое которого является DER-представлением структуры

Dss-Sig-Value  ::=  SEQUENCE  {
     r       INTEGER,
     s       INTEGER
}

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

В блочном режиме каждый блок текста преобразуется в шифрованный блок, который создается в режиме CBC (Cipher Block Chaining). Все элементы шифрованного потока имеют размер, кратный размеру шифрованного блока.

При шифровании с открытым ключом используется алгоритм, шифрующий данные таким образом, что их можно расшифровать только с использованием соответствующего секретного ключа. Шифрованные элементы представляет собой opaque-векторы <0..216-1>, размер которых определяется алгоритмом шифрования и ключом.

Зашифрованные с помощью алгоритма RSA значения кодируются с помощью PKCS #1 (блок типа 2) как описано в [PKCS1].

В приведенном примере

stream-ciphered struct {
    uint8 field1;
    uint8 field2;
    digitally-signed opaque hash[20];
} UserType;

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

4.8. Константы

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

Например,

stream-ciphered struct {
    uint8 field1;
    uint8 field2;
    digitally-signed opaque hash[20];
} UserType;

5. HMAC и псевдослучайная функция

Для многих операций уровня TLS Record и TLS Handshake требуется код MAC – цифровая подпись, защищенная ключом. Подмена кода MAC невозможна без использования секретного ключа MAC. Операция создания кода называется HMAC и описана в документе [HMAC].

Процедура HMAC может использоваться с различными алгоритмами хэширования. TLS использует эту процедуру в процессе согласования параметров с двумя различными алгоритмами — MD5 и SHA-1. Соответствующие процедуры обозначаются как HMAC_MD5(secret, data) и HMAC_SHA(secret, data). Возможно использование и других алгоритмов шифрования для защиты данных, но алгоритмы MD5 и SHA-1 жестко включены в описание согласования параметров для данной версии протокола.

Кроме того требуется конструкция для расширения секретов в блоки данных с целями генерации или проверки (validation) ключей. Такая псевдослучайная функция (pseudo-random function — PRF) принимает на входе секрет, затравку (seed) и идентифицирующую метку, выдает результат любого размера (arbitrary length).

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

Определим сначала функцию расширения данных P_hash(secret, data), которая использует одну хэш-функцию для создания на базе секрета и затравки блока данных любого размера:

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
                       HMAC_hash(secret, A(2) + seed) +
                       HMAC_hash(secret, A(3) + seed) + ...

где знак + означает конкатенацию.

Значения A() определяются следующим образом:

A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))

Функция P_hash может итеративно применяться столько раз, сколько потребуется для генерации требуемого объема данных. Например, если будет применяться функция P_SHA-1, для создания 64 байтов данных ее можно вызвать 4 раза (до A(4)), что даст 80 байтов на выходе и последние 16 байтов финальной итерации отбросить для создания выходного блока размером 64 байта.

Для TLS функция PRF создается путем разделения секрета на две половины, из которых одна служит для генерации данных с помощью P_MD5, а другая — для генерации данных с помощью P_SHA-1, после чего к результатам этих функций применяется операция «исключающее ИЛИ» (XOR) для их объединения.

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

L_S = размер секрета в байтах;
L_S1 = L_S2 = ceil(L_S/2);

Секрет делится на две половины (возможно с двухкратным использованием одного байта), как описано выше — S1 принимает первые L_S1 байтов, S2 — последние L_S2 байтов.

PRF определяется, как результат смешивания двух псевдо-случайных потоков и помощью операции «исключающее ИЛИ» (XOR).

PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);

Метка представляет собой строку символов ASCII. Ее следует включать в неизменном виде без байта размера или завершающего null-символа. Например, метка «slithy toves» будет при хэшировании использоваться, как последовательность байтов:

73 6C 69 74 68 79 20 74 6F 76 65 73

Отметим, что по причине того, что выход функции MD5имеет размер 16 байтов, а выход SHA-1 — 20 байтов, границы их внутренних итераций не будут совпадать и для создания на выходе 80 байтов P_MD5 будет использоваться 5 раз (да A(5)), а P_SHA-1 — только четыре (до A(4)).

6. Протокол TLS Record

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

В этом документе описаны 4 клиента данного протокола: протокол согласования (handshake), протокол сигнализации (alert), протокол смены шифра (change cipher spec) и прикладной протокол (application data). Для поддержки расширения протокола TLS могут применяться дополнительные типы записей, поддерживаемые протоколом Record. Для любого нового типа записи следует выделять значение типа непосредственно после значений ContentType для описанных здесь четырех типов записей (см. Приложение A.2). Если реализация TLS получает запись неизвестного типа, такую запись следует просто игнорировать. Любой протокол, предназначенный для использования на основе TLS, должен разрабатываться с учетом возможных атак на него. Отметим, что по причине отсутствия защиты полей типа и размера записи, следует принимать меры против возможности анализа трафика с использованием этих значений.

6.1. Состояния соединений

Состояние соединения TLS представляет собой рабочую среду протокола TLS Record. Оно задает алгоритмы сжатия, шифрования и MAC. Кроме того, известны параметры этих алгоритмов — секрет MAC, ключи шифрования больших объемов данных и векторы инициализации (IV) для соединения в направлениях чтения и записи. Логически всегда присутствуют 4 состояния — текущие состояния для чтения и записи, а также состояния для ожидаемых чтения и записи. Все записи (record) обрабатываются в текущих состояниях чтения и записи. Параметры безопасности для ожидающих состояний могут устанавливаться протоколом TLS Handshake и этот же протокол может избирательно переводить ожидающее состояние в текущее (в этом случае текущее состояние удаляется и заменяется ожидающим, а новое ожидающее состояние инициализируется пустым). Некорректно делать текущим ожидающее состояние, которое не было инициализировано с параметрами защиты. Изначальное текущее состояние всегда задает отсутствие шифрования, компрессии и MAC.

Параметры защиты для состояний чтения и записи TLS Connection задаются следующими значениями:

connection end — конечная точка

Показывает, является ли данная точка «клиентом» или «сервером» в этом соединении.

bulk encryption algorithm — алгоритм шифрования больших объемов данных

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

MAC algorithm — алгоритм MAC

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

compression algorithm — алгоритм сжатия

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

master secret — первичный секрет

48-байтовое секретное значение, известное обеим сторонам соединения.

client random — случайное значение клиента

32-битовое случайное число, предоставляемое клиентом.

server random — случайное значение сервера

32-битовое случайное число, предоставляемое сервером.

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

enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { true, false } IsExportable;
enum { null, md5, sha } MACAlgorithm;
enum { null(0), (255) } CompressionMethod;
/* Может добавляться алгоритм, указанный в CompressionMethod, BulkCipherAlgorithm или  MACAlgorithm*/
struct {
    ConnectionEnd          entity;
    BulkCipherAlgorithm    bulk_cipher_algorithm;
    CipherType             cipher_type;
    uint8                  key_size;
    uint8                  key_material_length;
    IsExportable           is_exportable;
    MACAlgorithm           mac_algorithm;
    uint8                  hash_size;
    CompressionMethod      compression_algorithm;
    opaque                 master_secret[48];
    opaque                 client_random[32];
    opaque                 server_random[32];
} SecurityParameters;

Уровень записей будет использовать параметры безопасности для генерации следующих 6 элементов:

client write MAC secret
server write MAC secret
client write key
server write key
client write IV (только для блочных шифров)
server write IV (только для блочных шифров)

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

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

compression state — состояние компрессии

Текущее состояние алгоритма сжатия.

cipher state — состояние шифра

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

MAC secret — секрет MAC

Секретное значение MAC для данного соединения (см. выше).

sequence number — порядковый номер

Для каждого соединения поддерживается порядковый номер (раздельно для состояний чтения и записи). Порядковый номер устанавливается в 0 при переходе соединения в активное состояние. Номер представляет собой значение типа uint64 и не может быть больше 2^64-1. Порядковые номера увеличиваются после каждой записи (первая запись для конкретного соединения должна использовать порядковый номер 0).

6.2. Уровень Record

Уровень TLS Record принимает неинтерпретированные данные от вышележащих уровней в непустых блоках произвольного размера.

6.2.1. Фрагментация

Уровень записей фрагментирует информационные блоки в записи TLSPlaintext, передающие данные размером до 2^14 байтов. Границы клиентских сообщений не сохраняются на уровне записей (т. е., множество клиентских сообщений с одним ContentType может содержаться в одной записи TLSPlaintext или одно сообщение может быть фрагментировано в несколько записей).

struct {
    uint8 major, minor;
} ProtocolVersion;

enum {
    change_cipher_spec(20), alert(21), handshake(22),
    application_data(23), (255)
} ContentType;

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

type — тип

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

version — версия

Версия протокола, который будет использоваться. Данный документ описывает протокол TLS версии 1.0, для которого номер версии имеет значение { 3, 1 }. Номер версии 3.1 сложился по историческим причинам — TLS v1.0 представляет собой незначительную модификацию протокола SSL 3.0, для которого номер версии был 3.0. (см. Приложение A.1).

length размер

Размер (в байтах следующего TLSPlaintext.fragment. Значение поля не должно превышать 2^14.

fragment фрагмент

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

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

6.2.2. Сжатие и декомпрессия записей

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

Компрессия не должна приводить к потерям и увеличивать размер сжимаемых данных более, чем на 1024 байта. Если функция декомпрессии встречает фрагмент TLSCompressed.fragment, который она будет декомпрессировать в размер, превышающий 2^14 байта, она должна выдавать сообщение о критической ошибке при декомпрессии.

       struct {
           ContentType type;       /* то же, что TLSPlaintext.type */
           ProtocolVersion version;/* то же, что TLSPlaintext.version */
           uint16 length;
           opaque fragment[TLSCompressed.length];
       } TLSCompressed;

length

Размер (в байтах) следующего фрагмента TLSCompressed.fragment. Размер фрагмента не может превышать 2^14 + 1024.

fragment

Сжатое представление TLSPlaintext.fragment.

Примечание. Операция CompressionMethod.null не меняет каких-либо полей.

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

6.2.3. Защита данных записи

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

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    select (CipherSpec.cipher_type) {
        case stream: GenericStreamCipher;
        case block: GenericBlockCipher;
    } fragment;
} TLSCiphertext;

type — тип

Поле типа, идентичное TLSCompressed.type.

version — версия

Поле номера версии, идентичное TLSCompressed.version.

length размер

Размер (в байтах) следующего фрагмента TLSCiphertext.fragment. Размер не может превышать 2^14 + 2048.

fragment фрагмент

Зашифрованная форма TLSCompressed.fragment с кодом MAC.

6.2.3.1. Пустой или стандартный потоковый шифр

Потоковые шифры (включая BulkCipherAlgorithm.null — см. Приложение A.6) преобразуют структуры TLSCompressed.fragment в структуры TLSCiphertext.fragment и обратно.

stream-ciphered struct {
    opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;

Значение MAC генерируется, как:

HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version +
	   TLSCompressed.length + TLSCompressed.fragment));

где «+» означает конкатенацию.

seq_num

Порядковый номер записи.

hash

Алгоритм хэширования, заданный полем SecurityParameters.mac_algorithm.

Отметим, что значение MAC рассчитывается до шифрования. Потоковый шифр кодирует блок целиком, включая MAC. Для потоковых шифров, не использующих вектор инициализации (таких, как RC4), состояние шифра из конца записи просто используется для следующего пакета. При использовании шифра (CipherSuite) TLS_NULL_WITH_NULL_NULL шифрование не применяется (т. е., данные не шифруются и размер MAC равен 0, что эквивалентно отказу от использования MAC). TLSCiphertext.length = TLSCompressed.length + CipherSpec.hash_size.

6.2.3.2. Блочный шифр CBC

Для блочных шифров (таких, как RC2 и DES) функции шифрования и MAC преобразуют структуры TLSCompressed.fragment в другие структуры TLSCiphertext.fragment и обратно.

block-ciphered struct {
    opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size];
    uint8 padding[GenericBlockCipher.padding_length];
    uint8 padding_length;
} GenericBlockCipher;

Значение MAC генерируется в соответствии с описанием параграфа 6.2.3.1.

padding — заполнение

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

padding_length — размер заполнения

Размер заполнения должен быть таким, чтобы общий размер структуры GenericBlockCipher был кратным размеру блока шифрования. Поле размера может принимать любые значения в диапазоне от 0 до 255, включительно. Это значение определяет размер поля заполнения без учета самого поля padding_length.

Размер зашифрованных данных (TLSCiphertext.length) на 1 больше суммы значений TLSCompressed.length, CipherSpec.hash_size и padding_length.

Пример. Если размер блока составляет 8 байтов, размер содержимого (TLSCompressed.length) — 61 байт, а размер MAC — 20 байтов, общий размер до заполнения составит 82 байта. Таким образом, размер заполнения для модуля 8 должен составить 6 байтов, чтобы сделать общий размер кратным 8 (размер блока). Реальный размер заполнения может составлять 6, 14, 22 и т. д., до 254. Если будет использоваться минимальное заполнение (6 байтов), каждое поле заполнения будет содержать значение 6. Таким образом последние 8 октетов GenericBlockCipher до шифрования блока будут иметь вид xx 06 06 06 06 06 06 06, где xx — последний октет MAC.

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

6.3. Расчет ключей

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

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

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

Для генерации ключевого материала выполняется расчет

key_block = PRF(SecurityParameters.master_secret, "key expansion",
                SecurityParameters.server_random + SecurityParameters.client_random);

пока не будет получен достаточный объем данных. После этого полученный блок делится, как показано ниже:

client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

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

Примечание для разработчиков. Спецификацией шифра, которая определена в данном документе и которой требуется значительный объем материала, является 3DES_EDE_CBC_SHA — ей нужно 2 x 24 байта для ключей, 2 x 20 байтов для секретов MAC и 2 x 8 байтов для IV (всего 104 байта ключевого материала).

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

final_client_write_key =
PRF(SecurityParameters.client_write_key, "client write key",
    SecurityParameters.client_random + SecurityParameters.server_random);
final_server_write_key =
PRF(SecurityParameters.server_write_key, "server write key",
    SecurityParameters.client_random + SecurityParameters.server_random);

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

iv_block = PRF("", "IV block", SecurityParameters.client_random +
                      SecurityParameters.server_random);

Значение iv_block делится на два вектора инициализации (как описанный выше key_block):

client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

Отметим, что PRF в этом случае применяется без секрета — это означает, что секрет имеет нулевой размер и не вносит вклада в хеширование PRF.

6.3.1. Пример генерации экспортируемого ключа

Для TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 требуется по 5 случайных байтов для каждого из 2 ключей шифрования и по 16 байтов для каждого ключа MAC, что в сумме требует 42 байта ключевого материала. Вывод PRF записывается в key_block. Затем key_block делится на части и для ключей записи выполняется дополнительная обработка, поскольку алгоритм является экспортируемым.

key_block               = PRF(master_secret, "key expansion", 
                          server_random + client_random)[0..41]
client_write_MAC_secret = key_block[0..15]
server_write_MAC_secret = key_block[16..31]
client_write_key        = key_block[32..36]
server_write_key        = key_block[37..41]

final_client_write_key  = PRF(client_write_key, "client write key",
                              client_random + server_random)[0..15]
final_server_write_key  = PRF(server_write_key, "server write key",
                              client_random + server_random)[0..15]

iv_block                = PRF("", "IV block", client_random + server_random)[0..15]
client_write_IV = iv_block[0..7]
server_write_IV = iv_block[8..15]

7. Протокол TLS Handshake

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

Протокол Handshake отвечает за согласование сессии, включающей перечисленные ниже элементы:

session identifier — идентификатор сессии

Произвольная последовательность байтов, выбранная сервером для идентификации активного или возобновляемого (resumable) состояния сессии.

peer certificate — сертификат партнера

Сертификат X509v3 [X509] для партнера. Этот элемент состояния может быть пустым.

compression method — метод сжатия

Алгоритм, используемый для сжатия данных перед шифрованием.

cipher spec — спецификация шифра

Задает алгоритм шифрования больших объемов данных (null, DES и т. п.) и MAC (MD5 или SHA). Этот параметр также определяет криптографические атрибуты типа hash_size (см. формальное определение в Приложении A.6).

master secret — первичный секрет

48-байтовое секретное значение, известное клиенту и серверу.

is resumable

Флаг возможности использования сессии для инициирования новых соединений.

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

7.1. Протокол смены шифра

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

struct {
    enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;

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

7.2. Протокол Alert

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

enum { warning(1), fatal(2), (255) } AlertLevel;

enum {
    close_notify(0),
    unexpected_message(10),
    bad_record_mac(20),
    decryption_failed(21),
    record_overflow(22),
    decompression_failure(30),
    handshake_failure(40),
    bad_certificate(42),
    unsupported_certificate(43),
    certificate_revoked(44),
    certificate_expired(45),
    certificate_unknown(46),
    illegal_parameter(47),
    unknown_ca(48),
    access_denied(49),
    decode_error(50),
    decrypt_error(51),
    export_restriction(60),
    protocol_version(70),
    insufficient_security(71),
    internal_error(80),
    user_canceled(90),
    no_renegotiation(100),
    (255)
} AlertDescription;

struct {
    AlertLevel level;
    AlertDescription description;
} Alert;

7.2.1. Сигналы закрытия

Клиент и сервер должны иметь общую информацию о завершении соединения во избежание атак «на отсечение» (truncation attack). Любая из сторон может инициировать обмен сообщениями о закрытии.

close_notify

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

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

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

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

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

7.2.2. Сигнализация ошибок

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

unexpected_message — неожиданное сообщение

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

bad_record_mac — некорректное значение MAC

Этот сигнал возвращается при получении записи с некорректным значением MAC. Ошибка является критической.

decryption_failed — отказ при расшифровке

Значение TLSCiphertext расшифровано некорректным способом — проверка показала, что размер не был кратен размеру блока или размер заполнения был неверным. Сигнал является критическим.

record_overflow — переполнение записи

Полученная запись TLSCiphertext имеет размер, превышающий 214+2048 байт, или запись была расшифрована в запись TLSCompressed, размер которой превысил 214+2048 байт. Сигнал является критическим.

decompression_failure — отказ при декомпресси

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

handshake_failure — отказ при согласовании

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

bad_certificate — некорректный сертификат

Сертификат поврежден, содержит подписи, которые не удалось проверить, и т. п.

unsupported_certificate — неподдерживаемый сертификат

Тип сертификата не поддерживается.

certificate_revoked — отозванный сертификат

Сертификат был отозван подписавшей его стороной.

certificate_expired

Срок действия сертификата истек.

certificate_unknown — неизвестный сертификат

Некая (не указанная) проблема, возникшая при обработке сертификата и делающая сертификат непригодным.

illegal_parameter — недопустимый параметр

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

unknown_ca — неизвестный удостоверяющий центр

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

access_denied — доступ отвергнут

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

decode_error — ошибка декодирования

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

decrypt_error — ошибка дешифровки

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

export_restriction — экспортные ограничения

Согласование не совместимо с обнаруженными экспортными ограничениями; например, предпринята попытка переноса эфемерного 1024-битового ключа RSA для согласования RSA_EXPORT. Ошибка является критической.

protocol_version — версия протокола

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

insufficient_security — недостаточная защита

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

internal_error — внутренняя ошибка

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

user_canceled — отказ пользователя

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

no_renegotiation — отказ от повторного согласования

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

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

7.3. Обзор протокола Handshake

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

Протокол TLS Handshake включает следующие этапы:

  • обмен сообщениями hello для согласования алгоритмов, обмена случайными значениями и проверки возобновления сессии;

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

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

  • генерация первичного секрета (master secret) из предварительного (premaster secret) и переданных друг другу случайных значений;

  • предоставление параметров безопасности уровню записи;

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

Отметим, что вышележащим протоколам не следует чересчур доверять TLS в плане согласования сторонами наиболее строго из возможных вариантов — существует множество способов, когда перехват с участием человека (MITM6) может использоваться для снижения уровня защиты вплоть до минимально возможного. Протокол рассчитан на минимизацию риска, но атаки все равно возможны — например, атакующий может блокировать доступ к порту, через который работает служба защиты и попытаться вынудить партнеров организовать неаутентифицированное соединение. Фундаментальным правилом является необходимость понимать на верхних уровнях реальные потребности в защите и никогда не передавать данные через канал, не обеспечивающий требуемого уровня защиты. Протокол TLS является защищенным, поскольку любой из шифров обеспечивает заявленный уровень защиты — если вы согласовали использование алгоритма 3DES с обменом RSA для 1024-битовых ключей с хостом, чей сертификат был подтвержден, вы может быть уверенными в защите.

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

Эти цели могут быть достигнуты с помощью протокола согласования (handshake), работу которого кратко можно описать следующим образом — клиент отправляет приветственное сообщение (hello), на которое сервер отвечает своим приветствием hello или, при возникновении критической ошибки, соединение будет разорвано. Сообщения hello от клиента и сервера служат для организации защищенного соединения между сторонами. При обмене этими сообщениями организуются следующие атрибуты: Protocol Version, Session ID, Cipher Suite, Compression Method. В дополнение к ним происходит генерация случайных значений ClientHello.random и ServerHello.random с обменом ими.

Для реального обмена ключами используется до 4 сообщений — сертификат сервера, серверный обмен ключами, сертификат клиента, клиентский обмен ключами. Может быть создан новый метод обмена ключами путем задания формата для этих сообщений и определения способа использования, который позволит согласовать между клиентом и сервером общий (shared) секрет. Этот секрет должен быть достаточно длинным; определенные к настоящему моменту методы обмена ключами поддерживают секреты размером от 48 до 128 байтов.

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

После этого клиент передает сообщение о смене шифра (change cipher spec) и копирует ожидающее значение Cipher Spec в текущее значение Cipher Spec. Клиент может сразу после этого передавать финальное сообщение с использованием новых алгоритмов, ключей и секретов. В ответ сервер будет передавать свое сообщение о смене шифра (change cipher spec), переносить ожидающее значение Cipher Spec в текущее и передавать сообщение о завершении с использованием нового Cipher Spec. На этом согласование завершается — клиент и сервер могут начать обмен данными приложений (см. Рисунок 1).

Клиент                                               Сервер

ClientHello                  -------->
                                                ServerHello
                                               Certificate*
                                         ServerKeyExchange*
                                        CertificateRequest*
                             <--------      ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                     -------->
                                         [ChangeCipherSpec]
                             <--------             Finished
Данные приложений            <------->    Данные приложений

* необязательное сообщение

Рисунок 1: Поток сообщений при полном согласовании

Примечание. Во избежание зацикливания сообщений ChangeCipherSpec считается отдельным типом содержимого TLS и не является приветственным сообщением TLS.

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

Клиент передает сообщение ClientHello, используя Session ID возобновляемой сессии. Сервер проверяет соответствие этой сессии своему кэшу. Если в кэше найден соответствующий идентификатор сессии и сервер согласен на ее возобновление в указанном состоянии, он передает сообщение ServerHello с таким же значением Session ID. Далее клиент и сервер должны передать сообщения и сразу же обработать о смене шифра, а затем обменяться сообщениями о завершении. На этом восстановление сессии завершается, клиент и сервер могут обмениваться данными прикладных уровней (см. Рисунок 2). Если значение Session ID не соответствует, сервер генерирует новый идентификатор, после чего клиент и сервер TLS выполняют полную процедуру согласования.

Клиент                                                Сервер

ClientHello                   -------->
                                                 ServerHello
                                          [ChangeCipherSpec]
                              <--------             Finished
[ChangeCipherSpec]
Finished                      -------->
Данные приложений             <------->    Данные приложений

Рисунок 2: Поток сообщений для сокращенного согласования

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

7.4. Протокол согласования параметров

Протокол согласования TLS Handshake является одним из определенных клиентов вышележащего уровня для протокола TLS Record. Этот протокол служит для согласования параметров защиты сессии. Сообщения Handshake передаются уровню TLS Record, где они инкапсулируются в одну или несколько структур TLSPlaintext, обрабатываемых и передаваемых в соответствии с текущим активным состоянием сессии.

enum {
    hello_request(0), client_hello(1), server_hello(2), certificate(11), 
    server_key_exchange (12), certificate_request(13), server_hello_done(14),
    certificate_verify(15), client_key_exchange(16), finished(20), (255)
} HandshakeType;

struct {
    HandshakeType msg_type;    /* тип handshake */
    uint24 length;             /* размер сообщения в байтах */
    select (HandshakeType) {
        case hello_request:       HelloRequest;
        case client_hello:        ClientHello;
        case server_hello:        ServerHello;
        case certificate:         Certificate;
        case server_key_exchange: ServerKeyExchange;
        case certificate_request: CertificateRequest;
        case server_hello_done:   ServerHelloDone;
        case certificate_verify:  CertificateVerify;
        case client_key_exchange: ClientKeyExchange;
        case finished:            Finished;
    } body;
} Handshake;

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

7.4.1. Сообщения Hello

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

7.4.1.1. Запрос Hello Request

Когда передается сообщение:

Сообщение с запросом приветствия (hello request) может быть передано сервером в любой момент.

Назначение сообщения:

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

После передачи запроса hello серверу не следует его повторять, пока согласование не будет завершено.

Структура сообщения:

struct { } HelloRequest;

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

7.4.1.2. Hello от клиента

Когда передается сообщение:

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

Структура сообщения:

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

struct {
    uint32 gmt_unix_time;
    opaque random_bytes[28];
} Random;

gmt_unix_time

Текущее время и дата в 32-битовом формате UNIX (число секунд с полуночи 1 января 1970 по GMT) по внутренним часам отправителя. Для базового протокола TLS корректность хода часов не имеет значения, однако протоколы вышележащих уровней могут вносить дополнительные требования.

random_bytes

28 байтов, создаваемых защищенным генератором случайных чисел.

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

opaque SessionID<0..32>;

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

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

uint8 CipherSuite[2]; /* селектор шифронабора */

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

enum { null(0), (255) } CompressionMethod;
struct {
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..2^16-1>;
    CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;

client_version

Версия протокола TLS, которую клиент желает использовать для взаимодействия с сервером. Следует использовать последнюю (с максимальным номером) из поддерживаемых клиентом версий. Для данной версии спецификации следует указывать номер версии протокола 3.1 (см. приложение E в части совместимости).

random

Генерируемая клиентом случайная структура.

session_id

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

cipher_suites

Список криптографических опций, поддерживаемых клиентом с указанием предпочитаемого клиентом варианта первым. Если поле session_id field не пусто (запрос на восстановление сессии), этот вектор должен включать по крайней мере cipher_suite для данной сессии. Значения определены в Приложении A.5.

compression_methods

Список методов сжатия, поддерживаемых клиентом и отсортированных в порядке снижения предпочтений клиента. Если поле session_id не пусто (запрос на восстановление сессии), список должен включать по крайней мере compression_method для данной сессии. Этот вектор должен включать, а все реализации должны поддерживать компрессию CompressionMethod.null. Это позволяет клиенту и серверу согласовать сжатие во всех случаях.

После передачи клиентом сообщения hello он ждет от сервера ответного сообщения hello. До этого все прочие согласующие сообщения от сервера трактуются, как критические ошибки.

Примечание по совместимости с новыми версиями:

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

7.4.1.3. Серверное сообщение Hello

Когда передается сообщение:

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

Структура сообщения:

struct {
    ProtocolVersion server_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suite;
    CompressionMethod compression_method;
} ServerHello;

server_version

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

random

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

session_id

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

cipher_suite

Один шифронабор, выбранный сервером из списка в ClientHello.cipher_suites. Для восстанавливаемых сессий это поле включает значение из состояния восстанавливаемой сессии.

compression_method

Один алгоритм сжатия, выбранный сервером из списка в ClientHello.compression_methods. Для восстанавливаемых сессий это поле включает значение из состояния восстанавливаемой сессии.

7.4.2. Сертификат сервера

Когда передается сообщение:

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

Назначение сообщения:

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

Алгоритм обмена ключами

Тип сертификата ключа

RSA

Открытый ключ RSA; сертификат должен разрешать использование ключа для шифрования.

RSA_EXPORT

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

DHE_DSS

Открытый ключ DSS.

DHE_DSS_EXPORT

Открытый ключ DSS.

DHE_RSA

Открытый ключ RSA, который может применяться для подписи.

DHE_RSA_EXPORT

Открытый ключ RSA, который может применяться для подписи.

DH_DSS

Ключ Diffie-Hellman. В качестве алгоритма для подписания сертификата следует использовать DSS.

DH_RSA

Ключ Diffie-Hellman. В качестве алгоритма для подписания сертификата следует использовать RSA.

Все профили сертификатов, ключей и криптографических форматов определены рабочей группой IETF PKIX [PKIX]. При наличии расширенного использования ключей должен устанавливаться бит digitalSignature для ключа, выбранного для подписи, как опсано выше, а бит keyEncipherment должен использоваться для разрешения шифрования, как описано выше. Бит keyAgreement должен устанавливаться для сертификатов Diffie-Hellman.

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

Структура сообщения:

opaque ASN.1Cert<1..2^24-1>;
       struct {
           ASN.1Cert certificate_list<0..2^24-1>;
       } Certificate;

certificate_list

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

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

Примечание: PKCS #7 [PKCS7] не используется в качестве формата векторов сертификата, поскольку расширенные сертификаты PKCS #6 [PKCS6] не используются. Кроме того, PKCS #7 определяет SET вместо SEQUENCE, что осложняет задачу разбора.

7.4.3. Серверное сообщение при обмене ключами

Когда передается сообщение:

Это сообщение передается сразу же вслед за сообщением с сертификатом сервера (или серверным сообщением hello при анонимном согласовании).

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

RSA_EXPORT (если открытый ключ в сертификате сервера имеет размер более 512 битов)
DHE_DSS
DHE_DSS_EXPORT
DHE_RSA
DHE_RSA_EXPORT
DH_anon

Не допускается передача сервером сообщения обмена ключами для следующих методов обмена:

RSA
RSA_EXPORT (если размер открытого ключа в сертификате сервера не превышает 512 битов)
DH_DSS
DH_RSA

Назначение сообщения:

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

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

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

Структура сообщения:

enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
       struct {
           opaque rsa_modulus<1..2^16-1>;
           opaque rsa_exponent<1..2^16-1>;
       } ServerRSAParams;

rsa_modulus

Модули временного серверного ключа RSA.

rsa_exponent

Открытый показатель (exponent) временного серверного ключа RSA.

       struct {
           opaque dh_p<1..2^16-1>;
           opaque dh_g<1..2^16-1>;
           opaque dh_Ys<1..2^16-1>;
       } ServerDHParams;     /* Эфемерные параметры DH */

dh_p

Основной модуль для операций Diffie-Hellman.

dh_g

Генератор, используемый для операций Diffie-Hellman.

dh_Ys

Открытое значение Diffie-Hellman для сервера (g^X mod p).

       struct {
           select (KeyExchangeAlgorithm) {
               case diffie_hellman:
                   ServerDHParams params;
                   Signature signed_params;
               case rsa:
                   ServerRSAParams params;
                   Signature signed_params;
           };
       } ServerKeyExchange;

params

Серверные параметры обмена ключами.

signed_params

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

md5_hash

MD5(ClientHello.random + ServerHello.random + ServerParams);

sha_hash

SHA(ClientHello.random + ServerHello.random + ServerParams);

       enum { anonymous, rsa, dsa } SignatureAlgorithm;
       select (SignatureAlgorithm)
       {   case anonymous: struct { };
           case rsa:
               digitally-signed struct {
                   opaque md5_hash[16];
                   opaque sha_hash[20];
               };
           case dsa:
               digitally-signed struct {
                   opaque sha_hash[20];
               };
       } Signature;

7.4.4. Запрос сертификата

Когда передается сообщение:

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

Структура сообщения:

enum {
    rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
    (255)
} ClientCertificateType;

opaque DistinguishedName<1..2^16-1>;

struct { ClientCertificateType certificate_types<1..2^8-1>; 
    DistinguishedName certificate_authorities<3..2^16-1>; 
} CertificateRequest;

certificate_types

Это поле содержит список типов запрошенных сертификатов, отсортированный в порядке предпочтений сервера.

certificate_authorities

Список различаемых имен подходящих удостоверяющих центров (certificate authority). Эти имена могут задавать желаемое имя корневого CA или подчиненного CA; таким образом, сообщение может использоваться для желаемого корневого УЦ или желаемой области проверки (authorization space).

Примечание: DistinguishedName является производным от [X509].

Примечание: Анонимному серверу, запрашивающему идентификацию клиента, возвращается сигнал handshake_failure.

7.4.5. Серверное сообщение hello done

Когда передается сообщение:

Сервер передает сообщение hello done для индикации завершения обмена приветственными сообщениями. После отправки данного сообщения сервер будет ждать отклика от клиента.

Назначение сообщения:

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

При получении от сервера сообщения hello done клиенту следует убедиться в предоставлении сервером корректного сертификата (если это требуется) и проверить приемлемость серверных параметров hello.

Структура сообщения:

       struct { } ServerHelloDone;

7.4.6. Сертификат клиента

Когда передается сообщение:

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

Примечание: При использовании статического обмена ключами на основе метода Diffie-Hellman (DH_DSS или DH_RSA) и запросе аутентификации клиента, группа и генератор Diffie-Hellman, представленные в сертификате клиента, должны соответствовать заданным сервером параметрам Diffie-Hellman, если клиентские параметры используются для обмена ключами.

7.4.7. Клиентское сообщение при обмене ключами

Когда передается сообщение:

Это сообщение всегда передается клиентом и следует сразу же за сообщением с сертификатом клиента. Если клиент не передает сертификата, данное сообщение будет первым сообщением клиента после получения от сервера сообщения hello done.

Назначение сообщения:

С помощью этого сообщения задается предварительный секрет (premaster secret) путем прямой передачи с шифрованием RSA или передачи параметров Diffie-Hellman, позволяющих каждой стороне организовать общий секрет. При использовании метода обмена ключами DH_RSA или DH_DSS запрашивается клиентский сертификат и клиент способен ответить сертификатом, содержащим открытый ключ Diffie-Hellman, параметры которого (группа и генератор) соответствуют заданным в сертификате сервера — это сообщение не содержит данных.

Структура сообщения:

Выбор сообщение зависит от используемого метода обмена ключами. Определение KeyExchangeAlgorithm дано в параграфе 7.4.3.

struct {
    select (KeyExchangeAlgorithm) {
        case rsa: EncryptedPreMasterSecret;
        case diffie_hellman: ClientDiffieHellmanPublic;
    } exchange_keys;
} ClientKeyExchange;
7.4.7.1. Сообщение к зашифрованным (RSA) секретом

Назначение сообщения:

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

Структура сообщения:

struct {
    ProtocolVersion client_version;
    opaque random[46];
} PreMasterSecret;

client_version

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

random

46 случайных байтов с защищенной генерацией.

       struct {
           public-key-encrypted PreMasterSecret pre_master_secret;
       } EncryptedPreMasterSecret;

Примечание: Атака, обнаруженная Daniel Bleichenbacher [BLEI], может быть использована против сервера TLS, использующего RSA с кодированием PKCS#1. Атака основана на том, что разными способами можно вынудить сервер TLS проверять после расшифровки конкретного сообщения имеет ли оно корректный формат PKCS#1.

Лучшим способом предотвращения таких атак состоит в том, чтобы сделать некорректно отформатированные сообщения неотличимыми от блоков RSA с корректным форматом. В результате при получении некорректно форматированного блока RSA сервер будет генерировать 48-байтовое значение и использовать его в качестве предварительного секрета. Таким образом, сервер будет вести себя независимо от корректности представления блока RSA.

pre_master_secret

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

7.4.7.2. Открытое значение Diffie-Hellman для клиента

Назначение сообщения:

Эта структура передает клиентское открытое значение Diffie-Hellman (Yc), если оно уже не было включено в сертификат клиента. Используемое для Yc кодирование определяется перечисляемым значением PublicValueEncoding. Эта структура является вариантом клиентского сообщения обмена ключами, а не сообщением, как таковым.

Структура сообщения:

enum { implicit, explicit } PublicValueEncoding;

implicit

Если сертификат клиента уже содержит подходящий ключ Diffie-Hellman, Yc неявно уже задано и нет необходимости передавать его снова. В этом случае передается пустое сообщение Client Key Exchange.

explicit

Yc требуется передать.

struct {
    select (PublicValueEncoding) {
        case implicit: struct { };
        case explicit: opaque dh_Yc<1..2^16-1>;
    } dh_public;
} ClientDiffieHellmanPublic;

dh_Yc

Открытое значение Diffie-Hellman для клиента (Yc).

7.4.8. Проверка сертификата

Когда передается сообщение:

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

Структура сообщения:

       struct {
            Signature signature;
       } CertificateVerify;

Тип Signature определен в параграфе 7.4.3.

       CertificateVerify.signature.md5_hash
           MD5(handshake_messages);
       Certificate.signature.sha_hash
           SHA(handshake_messages);

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

7.4.9. Finished — завершено

Когда передается сообщение:

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

Назначение сообщения:

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

struct {
    opaque verify_data[12];
} Finished;

verify_data

PRF(master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11];

finished_label

Для сообщений Finished, переданных клиентом это строка client finished, а для серверных сообщений Finished — server finished.

handshake_messages

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

Это конкатенация всех структур Handshake, определенных в параграфе 7.4 и использованных при обмене.

Если сообщение Finished не защищено сообщением о смене спецификации шифра на соответствующем этапе согласования, возникает критическая ошибка.

Хэш-значение в сообщении Finished от сервера включает Sender.server, а сообщение от клиента — Sender.client. Значение handshake_messages включает все согласующие сообщения с клиентского hello до (но не включая) данного сообщения Finished. Оно может отличаться от handshake_messages в параграфе 7.4.8, поскольку будет включать сообщение о проверке сертификата (если оно передавалось). Кроме того, handshake_messages для сообщений Finished от клиента будет отличаться от аналогичного параметра для серверного сообщения, поскольку одно из них передается раньше другого и не будет учитывать более позднее.

Примечание: Сообщения о смене спецификации шифра, сигналы и другие типы записей не относятся к согласующим сообщениям и не включаются в расчет хэш-значения. Не учитываются и сообщения Hello Request.

8. Криптографические расчеты

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

8.1. Расчет первичного секрета

Для всех методов обмена ключами используется один алгоритм преобразования pre_master_secret в master_secret. После расчета первичного секрета предварительный (pre_master_secret) следует удалить из памяти.

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + 
                ServerHello.random) [0..47];

Первичный секрет всегда имеет размер 48 байтов. Размер предварительного секрета зависит от метода обмена ключами.

8.1.1. RSA

При использовании RSA для аутентификации сервера и обмена ключами клиент генерирует 48-байтовое значение pre_master_secret, шифрует его с помощью открытого ключа сервера и передает серверу. Сервер использует секретный ключ для расшифровки pre_master_secret. Обе стороны могут преобразовать pre_master_secret в master_secret, как указано выше.

Цифровые подписи RSA вычисляются с использованием блоков PKCS #1 [PKCS1] типа 1. Шифрование RSA с открытым ключом выполняется с использованием блоков PKCS #1 типа 2.

8.1.2. Diffie-Hellman

Выполняется обычный расчет по методу Diffie-Hellman. Согласованный ключ (Z) используется в качестве pre_master_secret и преобразуется в master_secret, как указано выше.

Примечание: Параметры Diffie-Hellman задаются сервером и могут быть эфемерными или содержащимися в сертификате сервера.

9. Обязательные шифронаборы

В отсутствие профиля приложения, задающего иное, соответствующее TLS приложение должно реализовать шифронабор TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

10. Прикладной протокол

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

Приложение A. Значения протокольных констант

В этом разделе описаны протокольные типы и константы.

A.1. Уровень Record

struct {
    uint8 major, minor;
} ProtocolVersion;

ProtocolVersion = { 3, 1 };     /* TLS v1.0 */

enum {
    change_cipher_spec(20), alert(21), handshake(22),
    application_data(23), (255)
} ContentType;
struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    select (CipherSpec.cipher_type) {
        case stream: GenericStreamCipher;
        case block:  GenericBlockCipher;
    } fragment;
} TLSCiphertext;
stream-ciphered struct {
    opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
block-ciphered struct {
    opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size];
    uint8 padding[GenericBlockCipher.padding_length];
    uint8 padding_length;
} GenericBlockCipher;

A.2. Сообщение о смене спецификации шифра

struct {
    enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;

A.3. Сигналы

enum { warning(1), fatal(2), (255) } AlertLevel;

enum {
    close_notify(0),
    unexpected_message(10),
    bad_record_mac(20),
    decryption_failed(21),
    record_overflow(22),
    decompression_failure(30),
    handshake_failure(40),
    bad_certificate(42),
    unsupported_certificate(43),
    certificate_revoked(44),
    certificate_expired(45),
    certificate_unknown(46),
    illegal_parameter(47),
    unknown_ca(48),
    access_denied(49),
    decode_error(50),
    decrypt_error(51),
    export_restriction(60),
    protocol_version(70),
    insufficient_security(71),
    internal_error(80),
    user_canceled(90),
    no_renegotiation(100),
    (255)
} AlertDescription;

struct {
    AlertLevel level;
    AlertDescription description;
} Alert;

A.4. Протокол согласования параметров

enum {
    hello_request(0), client_hello(1), server_hello(2),
    certificate(11), server_key_exchange (12),
    certificate_request(13), server_hello_done(14),
    certificate_verify(15), client_key_exchange(16),
    finished(20), (255)
} HandshakeType;

struct {
    HandshakeType msg_type;
    uint24 length;
    select (HandshakeType) {
        case hello_request:       HelloRequest;
        case client_hello:        ClientHello;
        case server_hello:        ServerHello;
        case certificate:         Certificate;
        case server_key_exchange: ServerKeyExchange;
        case certificate_request: CertificateRequest;
        case server_hello_done:   ServerHelloDone;
        case certificate_verify:  CertificateVerify;
        case client_key_exchange: ClientKeyExchange;
        case finished:            Finished;
    } body;
} Handshake;

A.4.1. Сообщения Hello

struct { } HelloRequest;

struct {
    uint32 gmt_unix_time;
    opaque random_bytes[28];
} Random;

opaque SessionID<0..32>;

uint8 CipherSuite[2];

enum { null(0), (255) } CompressionMethod;

struct {
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..2^16-1>;
    CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;

struct {
    ProtocolVersion server_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suite;
    CompressionMethod compression_method;
} ServerHello;

A.4.2. Сообщения при аутентификации сервера и обмене ключами

opaque ASN.1Cert<2^24-1>;

struct {
    ASN.1Cert certificate_list<1..2^24-1>;
} Certificate;

enum { rsa, diffie_hellman } KeyExchangeAlgorithm;

struct {
    opaque RSA_modulus<1..2^16-1>;
    opaque RSA_exponent<1..2^16-1>;
} ServerRSAParams;

struct {
    opaque DH_p<1..2^16-1>;
    opaque DH_g<1..2^16-1>;
    opaque DH_Ys<1..2^16-1>;
} ServerDHParams;

struct {
    select (KeyExchangeAlgorithm) {
        case diffie_hellman:
            ServerDHParams params;
            Signature signed_params;
        case rsa:
            ServerRSAParams params;
            Signature signed_params;
    };
} ServerKeyExchange;

enum { anonymous, rsa, dsa } SignatureAlgorithm;

select (SignatureAlgorithm)
{   case anonymous: struct { };
    case rsa:
        digitally-signed struct {
            opaque md5_hash[16];
            opaque sha_hash[20];
        };
    case dsa:
        digitally-signed struct {
            opaque sha_hash[20];
        };
} Signature;

enum {
    rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
    (255)
} ClientCertificateType;

opaque DistinguishedName<1..2^16-1>;

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;

struct { } ServerHelloDone;

A.4.3. Сообщения при аутентификации клиента и обмене ключами

    struct {
        select (KeyExchangeAlgorithm) {
            case rsa: EncryptedPreMasterSecret;
            case diffie_hellman: DiffieHellmanClientPublicValue;
        } exchange_keys;
    } ClientKeyExchange;
    struct {
        ProtocolVersion client_version;
        opaque random[46];

    } PreMasterSecret;
    struct {
        public-key-encrypted PreMasterSecret pre_master_secret;
    } EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
    struct {
        select (PublicValueEncoding) {
            case implicit: struct {};
            case explicit: opaque DH_Yc<1..2^16-1>;
        } dh_public;
    } ClientDiffieHellmanPublic;
    struct {
        Signature signature;
    } CertificateVerify;

A.4.4. Сообщение о завершении согласования

    struct {
        opaque verify_data[12];
    } Finished;

A.5. CipherSuite

Ниже определены коды шифронаборов CipherSuite, используемых в клиентских и серверных сообщениях hello.

Значение CipherSuite определяет спецификацию шифра, поддерживаемого протоколом TLS версии 1.0.

Код TLS_NULL_WITH_NULL_NULL определяет начальное состояние соединения TLS в процессе первого согласования для данного канала, но этот код недопустимо согласовывать, поскольку он не обеспечивает какой-либо защиты.

    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };

Приведенные ниже коды CipherSuite требуют от сервера обеспечения сертификата RSA, который может использоваться при обмене ключами. Сервер может запросить поддерживающий подписи сертификат RSA или DSS в сообщении certificate request.

    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };

Приведенные ниже значения CipherSuite используются для аутентифицируемого сервером (опционально, и клиентом) механизма Diffie-Hellman. DH обозначает шифронаборы, в которых сертификат сервера включает параметры Diffie-Hellman, подписанные удостоверяющим центром (CA — УЦ). DHE обозначает эфемерные Diffie-Hellman, где параметры Diffie-Hellman подписаны сертификатом DSS или RSA, который, в свою очередь, подписан УЦ. Используемый алгоритм подписи задается после параметра DH или DHE. Сервер может запросить у клиента сертификат RSA или DSS с возможностью подписи для его аутентификации или запросить сертификат Diffie-Hellman. Любые сертификаты Diffie-Hellman, предоставляемые клиентом, должны использовать описанные сервером параметры (группа и генератор).

    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };

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

    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };

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

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

Примечание: Значения кодов { 0x00, 0x1C } и { 0x00, 0x1D } зарезервированы для предотвращения конфликтов с шифронаборами на базе Fortezza в SSL3.

A.6. Параметры защиты

Параметры защиты определяются протоколом TLS Handshake и предоставляются протоколу уровню TLS Record для инициализации состояния соединения. Параметры защиты (SecurityParameters) включают:

enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, idea }
BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { true, false } IsExportable;
enum { null, md5, sha } MACAlgorithm;
/* Могут быть добавлены алгоритмы, заданные в CompressionMethod, BulkCipherAlgorithm и  MACAlgorithm. */
struct {
    ConnectionEnd entity;
    BulkCipherAlgorithm bulk_cipher_algorithm;
    CipherType cipher_type;
    uint8 key_size;
    uint8 key_material_length;
    IsExportable is_exportable;
    MACAlgorithm mac_algorithm;
    uint8 hash_size;
    CompressionMethod compression_algorithm;
    opaque master_secret[48];
    opaque client_random[32];
    opaque server_random[32];
} SecurityParameters;

Приложение B. Глоссарий

application protocol – прикладной протокол

Протокол, который обычно располагается непосредственно над транспортным уровнем (например, TCP/IP). Примерами прикладных протоколов могут служит HTTP, TELNET, FTP, SMTP.

asymmetric cipher – асимметричное шифрование

См. public key cryptography на стр. 29.

authentication — аутентификация

Способность одного объекта проверить подлинность (идентифицировать) другого объекта.

block cipher – блочное шифрование

Блочным шифрованием называются алгоритмы шифрования, работающие с текстом, как с группами битов, называемыми блоками. Типичный размер блока составляет 64 бита.

bulk cipher – объемое шифрование

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

cipher block chaining (CBC)

В режиме CBC для каждого шифруемого блока сначала применяется логическая операция «Исключающее-ИЛИ» XOR) с предыдущим зашифрованным блоком (или, при шифровании первого блока, с вектором инициализации). При дешифровании блок сначала расшифровывается, затем применяется операция XOR с предыдущим шифрованным блоком (или IV).

certificate — сертификат

Будучи частью протокола X.509 (модель аутентификации ISO), сертификат выделяется удостоверяющим центром (Certificate Authority) и обеспечивает строгую связь между его владельцем или некими иными атрибутами и открытым ключом.

client — клиент

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

client write key — клиентский ключ записи

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

client write MAC secret — клиентский MAC-секрет для записи

Секретное значение, служащее для аутентификации данных, записанных клиентом.

connection — соединение

Соединением называется транспорт (в терминологии модели OSI), обеспечивающий приемлемый тип обслуживания. Для TLS используются соединения «точка-точка». Соединения являются временными, каждое соединение связано с одной сессией.

Data Encryption Standard — стандарт шифрования данных

DES является широко распространенным симметричным алгоритмом шифрования. DES представляет собой блочный шифр с 56-битовым ключом и 8-байтовыми блоками. Отметим, что в TLS при генерации ключей размер ключей DES трактуется, как 8 байтов (64 бита), но реально для защиты обеспечивается лишь 56 битов (младший бит каждого байта ключа предполагается установленным для обеспечения нечетности данного байта). DES также может работать в режиме, где для каждого блока данных используется три независимых ключа и 3-кратное шифрование. В этом случае получается размер ключа 168 битов (24 байта при генерации ключей в TLS) и обеспечивается эквивалент защиты с использованием ключей размером 112 битов. [DES], [3DES]

Digital Signature Standard (DSS) – стандарт цифровой подписи

Стандарт для цифровой подписи, включающий алгоритм цифровой подписи (Digital Signing Algorithm), одобренный NIST8 и опубликованный в мае 1994 Департаментом торговли США (U.S. Dept. of Commerce) в документе NIST FIPS PUB 186, Digital Signature Standard. [DSS]

digital signatures – цифровые подписи

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

Handshake — согласование

Начальное согласование параметров транзакций между клиентом и сервером.

Initialization Vector (IV) – вектор инициализации

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

IDEA

64-битовый блочный шифр, разработанный Xuejia Lai и James Massey. [IDEA]

Message Authentication Code (MAC) – код аутентификации сообщения

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

master secret — первичный секрет

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

MD5

Защищенная функция хеширования MD5 позволяет преобразовать поток данных произвольной длины в сигнатуру фиксированного размера (16 байтов). [MD5]

public key cryptography – шифрование с открытым ключом

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

one-way hash function – необратимая хэш-функция

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

RC2

Блочный шифр, разработанный Ron Rivest в компании RSA Data Security, Inc. [RSADSI]. Описан в работе [RC2].

RC4

Потоковый шифр, разработанный в RSA Data Security [RSADSI]. Совместимый шифр описан в [RC4].

RSA

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

salt — затравка

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

server — сервер

Прикладной объект, принимающий запросы на соединения от клиентов. См. также client.

session – сессия, сеанс

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

session identifier – идентификатор сессии

Генерируемое сервером значение, которое служит для идентификации конкретной сессии.

server write key — серверный ключ записи

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

server write MAC secret — серверный секрет MAC для записи

Секретный данные, служащие для идентификации записываемых сервером данных.

SHA

Алгоритм защищенного хэширования SHA10, определенный в FIPS PUB 180-1. Выходное значение имеет размер 20 байтов. Отметим, что все ссылки на SHA в реальности относятся к модификации алгоритма SHA-1 [SHA].

SSL

Протокол защищенного сокета SSL11 [SSL3] компании Netscape. Протокол TLS основан на SSL версии 3.0.

stream cipher – потоковое шифрование

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

symmetric cipher – симметричное шифрование

См. bulk cipher на стр. 28.

Transport Layer Security (TLS) — защита транспортного уровня

Данный протокол, а также рабочая группа Transport Layer Security в IETF. См. Комментарии в конце документа.

Приложение C. Определения CipherSuite

CipherSuite

Экспорт

Обмен ключами

Шифр

Хэш

TLS_NULL_WITH_NULL_NULL

+

NULL

NULL

NULL

TLS_RSA_WITH_NULL_MD5

+

RSA

NULL

MD5

TLS_RSA_WITH_NULL_SHA

+

RSA

NULL

SHA

TLS_RSA_EXPORT_WITH_RC4_40_MD5

+

RSA_EXPORT

RC4_40

MD5

TLS_RSA_WITH_RC4_128_MD5

RSA

RC4_128

MD5

TLS_RSA_WITH_RC4_128_SHA

RSA

RC4_128

SHA

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

+

RSA_EXPORT

RC2_CBC_4

MD5

TLS_RSA_WITH_IDEA_CBC_SHA

RSA

IDEA_CBC

SHA

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

+

RSA_EXPORT

DES40_CBC

SHA

TLS_RSA_WITH_DES_CBC_SHA

RSA

DES_CBC

SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

RSA

3DES_EDE_CBC

SHA

TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA

+

DH_DSS_EXPORT

DES40_CBC

SHA

TLS_DH_DSS_WITH_DES_CBC_SHA

DH_DSS

DES_CBC

SHA

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

DH_DSS

3DES_EDE_CBC

SHA

TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA

+

DH_RSA_EXPORT

DES40_CBC

SHA

TLS_DH_RSA_WITH_DES_CBC_SHA

DH_RSA

DES_CBC

SHA

TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

DH_RSA

3DES_EDE_CBC

SHA

TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

+

DHE_DSS_EXPORT

DES40_CBC

SHA

TLS_DHE_DSS_WITH_DES_CBC_SHA

DHE_DSS

DES_CBC

SHA

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

DHE_DSS

3DES_EDE_CBC

SHA

TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

+

DHE_RSA_EXPORT

DES40_CBC

SHA

TLS_DHE_RSA_WITH_DES_CBC_SHA

DHE_RSA

DES_CBC

SHA

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

DHE_RSA

3DES_EDE_CBC

SHA

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

+

DH_anon_EXPORT

RC4_40

MD5

TLS_DH_anon_WITH_RC4_128_MD5

DH_anon

RC4_128

MD5

TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

DH_anon

DES40_CBC

SHA

TLS_DH_anon_WITH_DES_CBC_SHA

DH_anon

DES_CBC

SHA

TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

DH_anon

3DES_EDE_CBC

SHA

Алгоритм обмена ключами

Описание

Предельные размеры ключей (бит)

DHE_DSS

Эфемерный DH с подписями DSS

нет

DHE_DSS_EXPORT

Эфемерный DH с подписями DSS

DH = 512

DHE_RSA

Эфемерный DH с подписями RSA

нет

DHE_RSA_EXPORT

Эфемерный DH с подписями RSA

DH = 512, RSA — нет

DH_anon

Анонимный DH без подписи

нет

DH_anon_EXPORT

Анонимный DH без подписи

DH = 512

DH_DSS

DH с сертификатами на базе DSS

нет

DH_DSS_EXPORT

DH с сертификатами на базе DSS

DH = 512

DH_RSA

DH с сертификатами на базе RSA

нет

DH_RSA_EXPORT

DH с сертификатами на базе RSA

DH = 512, RSA — нет

NULL

Без обмена ключами

Не применимо

RSA

Обмен ключами RSA

нет

RSA_EXPORT

Обмен ключами RSA

RSA = 512

Key size limit — максимальный размер ключа

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

Шифр

Экспорт

Тип

Ключевой материал

Расширенный ключевой материал

Эффективный ключ (бит)

IV (бит)

Размер блока

NULL

+

Поток

0

0

0

0

IDEA_CBC

Блок

16

16

128

8

8

RC2_CBC_40

+

Блок

5

16

40

8

8

RC4_40

+

Поток

5

16

40

0

RC4_128

Поток

16

16

128

0

DES40_CBC

+

Блок

5

8

40

8

8

DES_CBC

Блок

8

8

56

8

8

3DES_EDE_CBC

Блок

24

24

168

8

8

Type — тип шифра

Показывает, является данных шифр потоковым или блочным в режиме CBC.

Key Material — размер ключевого материала

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

Expanded Key Material — расширенный размер ключевого материала

Число байтов, реально поступающих в алгоритм шифрования.

Effective Key Bits — число эффективных битов ключа

Уровень энтропии в ключевом материале, который будет передан в программы шифрования.

IV Size — размер веторов инициализации

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

Block Size — размер блока

Размер данных, шифруемых блочным шифром в один прием (chunk), блочные шифры в режиме CBC могут шифровать только четное количество блоков.

Хэш-функция

Размер хэша

Размер заполнения

NULL

0

0

MD5

16

48

SHA

20

40

Приложение D. Рекомендации для разработчиков

Протокол TLS не может предотвратить многие общие ошибки защиты. В этом приложении приведены некоторые рекомендации для разработчиков.

D.1. Временные ключи RSA

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

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

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

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

D.2. Генерация случайных чисел и «затравки»

TLS требует наличия криптографически защищенного генератора псевдослучайных чисел (PRNG12). Следует обращать пристальное внимание на реализацию и начальное состояние (seeding) PRNG. Генераторы на основе защищенных хэш-операций (типа MD5 или SHA) являются подходящими, но не могут обеспечить более надежную защиту, чем размер состояния генератора случайных чисел (например, PRNG на базе MD5 обычно имеют 128-битовые состояния).

Для оценки объема создаваемого «затравочного» материала (seed) следует добавить число битов непредсказуемой информации в каждом «затравочном» байте. Например, моменты нажатия клавиш, взятые от PC-совместимого таймера с частотой 18,2 Гц обеспечивают 1 или 2 защищенных бита каждый даже если суммарное значение счетчика составляет 16 или более битов. Для «затравки» 128-битового PRNG будет требоваться около 100 таких значений.

Предупреждение. Функции «затравки» в RSAREF и BSAFE до версии 3.0 не зависят от порядка. Например, если представлено 1000 битов затравки по одному, при 1000 раздельных вызовах seed-функции PRNG будет находиться в состоянии, которое будет зависеть лишь не более, чем от 1 бита в данных затравки (т. е., возможно 1001 состояние). Приложения, использующие BSAFE или RSAREF, должны обращать особое внимание на корректность затравок. Это можно обеспечить аккумулированием битов затравки в буфере и обработки их разом или за счет обработки инкрементируемого счетчика для каждого бита затравки. Любой из этих методов вносит зависимость от порядка в процесс создания затравки.

D.3. Сертификаты и аутентификация

Реализации отвечают за проверку целостности сертификатов и в общем случае им следует поддерживать сообщения отзыва сертификатов. Сертификаты всегда следует проверять на предмет наличия подписи доверенного УЦ (CA). Выбор и добавление доверенных удостоверяющих центров следует выполнять с осторожностью. Пользователи должны иметь возможность просмотра информации о сертификате и корневом УЦ (CA).

D.4. Шифронаборы

TLS поддерживает широкий диапазон размеров ключей и уровней защиты, включая некоторые варианты с минимальной защитой или совсем без таковой. Корректная реализация может не поддерживать многие из шифронаборов. Например, 40-битовое шифрование легко расрывается, поэтому требующие строго защиты реализации не позволят применять 40-битовые ключи. Точно так же, анонимный механизм Diffie-Hellman настоятельно не рекомендуется использовать, поскольку он не устойчив к MITM-атакам. Приложениям следует также задавать верхнюю и нижнюю границу размера ключей. Например, цепочки сертификатов, содержащие 512-битовые ключи или подписи RSA, не подходят для приложений с требованиями надежной защиты.

Приложение E. Совместимость с протоколом SSL

В силу исторических причин, а также в целях экономии зарезервированных номеров портов прикладные протоколы, защищаемые TLS 1.0, SSL 3.0 и SSL 2.0, зачастую используют общий для всего соединения номер порта, например, протокол https (HTTP, защищенный SSL или TLS) использует порт 443, независимо от применяемого протокола защиты. Таким образом, требуется некий механизм для различения и согласования протокола защиты.

Протоколы TLS 1.0 и SSL 3.0 очень похоже и поддержка обоих сразу не представляет сложности. Клиентам TLS, желающим получить согласование с сервером SSL 3.0, следует направлять серверу сообщение hello, использующее формат записи SSL 3.0 и структуру клиентского сообщение hello, указывая {3, 1} в поле версии для индикации поддержки TLS 1.0. Если сервер поддерживает только SSL 3.0, он будет отвечать серверным сообщением SSL 3.0 hello, при поддержке TLS — серверным сообщением TLS hello. Дальнейшее согласование выполняется, как обычно.

Точно также серверу TLS, желающему взаимодействовать с клиентами SSL 3.0, следует воспринимать клиентские сообщения SSL 3.0 и отвечать на них серверным сообщением SSL 3.0, если клиент SSL 3.0 в своем сообщении hello указал в поле версии значение {3, 0}, говорящее об отсутствии поддержки TLS.

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

Клиенты TLS 1.0, поддерживающие работу с серверами SSL 2.0, должны передавать клиентское сообщение SSL 2.0 hello [SSL2]. Серверам TLS следует воспринимать любой формат клиентских сообщений hello, если они хотят поддерживать клиентов SSL 2.0 через тот же порт. Единственным отклонением от спецификации версии 2.0 является возможность задать версию с номером 3 и поддержка дополнительных типов шифрования в CipherSpec.

Предупреждение. Возможность передачи клиентами сообщений hello версии 2.0 будет прекращена в максимально короткие сроки. Разработчикам следует приложить все усилия для скорейшего перехода к новой версии. Версия 3.0 обеспечивает более эффективные механизмы перехода к новым версиям.

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

V2CipherSpec TLS_RC4_128_WITH_MD5                  = { 0x01,0x00,0x80 };
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5         = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5          = { 0x03,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5             = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5               = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5         = { 0x07,0x00,0xC0 };

Естественные для TLS спецификации шифров могут быть включены в клиентские сообщения hello версии 2.0 с использованием показанного ниже синтаксиса. Любой элемент V2CipherSpec с нулевым значением первого байта будет игнорироваться серверами версии 2.0. Клиентам, передающим любое из приведенных выше значений V2CipherSpec, следует также включать эквивалент TLS (см. Приложение A.5):

       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };

E.1. Сообщение hello клиента версии 2

В представленном ниже клиентском сообщении hello версии 2.0 используется принятый в этом документе формат. Настоящее определение приведено в спецификации SSL Version 2.0.

       uint8 V2CipherSpec[3];

       struct {
           uint8 msg_type;
           Version version;
           uint16 cipher_spec_length;
           uint16 session_id_length;
           uint16 challenge_length;
           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
           opaque session_id[V2ClientHello.session_id_length];
           Random challenge;
       } V2ClientHello;

msg_type

Это поле вместе с полем номера версии идентифицирует клиентское сообщение hello версии 2. Поле должно иметь значение 1.

version

Максимальный номер версии протокола, поддерживаемой клиентом (=ProtocolVersion.version, см. Приложение A.1).

cipher_spec_length

Это поле указывает общий размер поля cipher_specs. Значение поля не может быть нулевым и должно быть кратно размеру V2CipherSpec (3).

session_id_length

Это поле должно иметь значение 0 или 16. Нулевое значение говорит о создании клиентом новой сессии, а при 16 поле session_id будет содержать 16 байтов идентификатора сессии.

challenge_length

Размер (в байтах) клиентского запроса к серверу для аутентификации тем самого себя. Поле должно иметь значение 32.

cipher_specs

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

session_id

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

challenge

Клиентский запрос к серверу для идентификации тем самого себя представляет собой (почти) произвольное количество случайных данных. Сервер TLS имеет право выровнять данные запроса для преобразования в ClientHello.random (дополнить нулями в начале, при необходимости) в соответствии со спецификацией протокола. Если размер challenge превышает 32 байта, будут использоваться лишь последние 32 байта. Для серверов V3 допустимо (но не требуется) отбрасывать V2 ClientHello, содержащие меньше 16 байтов в поле challenge.

Примечание. В запросах на восстановление сессии TLS следует использовать клиентское сообщение TLS hello.

E.2. Предотвращение MITM-атак на снижение версии

При снижении клиентом TLS требований до режима совместимости с 2.0 следует использовать специальное форматирование блоков PKCS #1. В этом случае серверы TLS будут отвергать сессии 2.0 для поддерживающих TLS клиентов.

Когда клиенты TLS работают в режиме совместимости с версией 2.0, он устанавливает в правых (наименее значимых) 8 случайных байтах заполнения PKCS (не включая завершающий null-символ заполнения) для шифрования RSA в поле ENCRYPTED-KEY-DATA ключа CLIENT-MASTER-KEY значение 0x03 (остальная часть заполнения остается случайной). После расшифровки поля ENCRYPTED-KEY-DATA серверу, поддерживающему TLS, следует ввести состояние ошибки, если байты заполнения имеют значение 0x03. Серверы версии 2.0 будут обрабатывать такое заполнение нормально.

Приложение F. Анализ безопасности

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

F.1. Протокол согласования

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

F.1.1. Аутентификация и обмен ключами

TLS поддерживает три режима аутентификации — аутентификация обеих сторон, аутентификация только сервера и общая анонимность. При работе с аутентифицированным сервером канал будет защищен от MITM-атак, но анонимные сессии могут быть подвержены таким атакам. Анонимные серверы не могут аутентифицировать клиентов. Если сервер аутентифицирован, его сообщение с сертификатом должно содержать корректную цепочку сертификатов, ведущую к доверенному УЦ. Аналогично, аутентифицированные клиенты должны предоставлять сертификат, приемлемый для сервера. Каждая сторона отвечает за проверку того, что сертификат другой стороны не отозван и срок его действия не завершился.

Общей целью процесса обмена ключами является создание предварительного секрета pre_master_secret, известного сторонам и не доступного для атакующих. Значение pre_master_secret будет использоваться для генерации первичного секрета master_secret (см. параграф 8.1). Значение master_secret требуется для генерации сообщений certificate verify и finished, ключей шифрования и секретов MAC (см. параграфы 7.4.8, 7.4.9 и 6.3). Передачей корректного сообщения finished стороны подтверждают наличие корректного предварительного секрета pre_master_secret.

F.1.1.1. Анонимный обмен ключами

Полностью анонимные сессии можно организовать с использованием обмена ключами RSA или Diffie-Hellman. При анонимном согласовании RSA клиент шифрует pre_master_secret с помощью несертифицированного открытого ключа сервера полученного из серверного сообщения обмена ключами. Результат шифрования передается в клиентском сообщении обмена ключами. Поскольку перехватчикам данных секретный ключ сервера не известен, они не смогут расшифровать pre_master_secret (отметим, что анонимные шифронаборы RSA Cipher Suite не определены в данном документе).

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

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

F.1.1.2. Обмен ключами и аутентификация RSA

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

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

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

При использовании RSA для обмена ключами клиенты аутентифицируются с использованием сообщения certificate verify (см. параграф 7.4.8). Клиент подписывает значение, полученное из master_secret и предшествующих согласующих сообщений. Согласующие сообщения включают сертификат сервера, который привязан к подписи сервера, и случайное значение ServerHello.random, которое привязывает подпись к текущему процессу согласования.

F.1.1.3. Обмен ключами и аутентификация Diffie-Hellman

При использовании для обмена ключами алгоритма Diffie-Hellman сервер может предоставить сертификат с фиксированными параметрами Diffie-Hellman или использовать сообщение обмена ключами для установки временных параметров Diffie-Hellman, подписанных сертификатом DSS или RSA. Временные параметры хэшируются со значениями hello.random перед созданием подписи для предотвращения возможности использования атакующими старых параметров. В любом случае клиент может проверить сертификат или подпись для обеспечения гарантии того, что параметры принадлежат серверу.

Если у клиента имеется сертификат с параметрами Diffie-Hellman, этого сертификата будет достаточно для завершения обмена ключами. Отметим, что в этом случае клиент и сервер будут генерировать одинаковый результат Diffie-Hellman (т. е., pre_master_secret) при каждом взаимодействии. Чтобы предотвратить сохранение в памяти значения pre_master_secret после завершения работы с ним это значение следует как можно скорее преобразовать в master_secret. Клинетские параметры Diffie-Hellman должны быть совместимы с такими же параметрами, представленными сервером для того, чтобы обмен ключами работал нормально.

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

F.1.2. Атаки со снижением версии

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

Хотя решение на основе использования неслучайного заполнения в блоках PKCS #1 типа 2 не является элегантным, оно обеспечивает для серверов версии 3.0 безопасный способ детектирования атак. Это решение не обеспечивает защиты от атакующих, которые могут подобрать (brute force) ключ и подменить сообщение ENCRYPTED-KEY-DATA, используя тот же ключ, но обычно заполнение, до того, как заданное приложением время ожидания истечет. Сторонам, озабоченным такими атаками, не следует использовать 40-битовые ключи шифрования. Изменение 8 младших байтов заполнения PKCS не влияет на защиту при размере подписанных хэшей и ключей RSA, используемых в протоколе, поскольку это эквивалентно увеличению размера входного блока на 8 байтов.

F.1.3. Детектирование атак на протокол согласования

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

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

F.1.4. Возобновление сессий

Когда соединение организуется путем возобновления сессии, новые значения ClientHello.random и ServerHello.random хешируются с используем master_secret восстанавливаемой сессии. При условии того, что master_secret не был скомпрометирован, а для создания ключей шифрования и секретов MAC используются защищенные операции хэширования, соединение будет защищено и не зависимо от предыдущих соединений. Атакующий не сможет использовать известные ему ключи шифрования и секреты MAC для компрометации master_secret без нарушения защищенных хэш-операций (которые используют SHA и MD5).

Сессия не может быть возобновлена без согласия обеих сторон — клиента и сервера.

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

F.1.5. MD5 и SHA

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

F.2. Защита данных приложений

Значение master_secret хэшируется с ClientHello.random и ServerHello.random для генерации ключей шифрования и секретов MAC в каждом соединении.

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

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

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

F.3. Заключительные замечания

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

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

Приложение G. Патенты

Некоторые из предложенных в данном протоколе криптографических алгоритмов защищены патентами. Кроме того, компания Netscape Communications Corporation владеет патентом на технологию SSL, являющуюся основой для данного стандарта. Процесс стандартизации Internet, определенный в RFC 2026, требует получить от владельца патента заявление, подтверждающее предоставление приложениям лицензий на разумных условиях.

Массачусетский технологический институт предоставил компании RSA Data Security, Inc. Исключительные права сублицензирования для следующих патентов США:

Cryptographic Communications System and Method («RSA»), No. 4,405,829

Netscape Communications Corporation has been issued the following patent in the United States:

Secure Socket Layer Application Program Apparatus And Method («SSL»), No. 5,657,390

Компания Netscape Communications выпустила следующие заявления:

Intellectual Property Rights (права интеллектуальной собственности)

Secure Sockets Layer (уровень защищенных сокетов)

Патентное бюро США (PTO13) недавно выдало компании Netscape патент U.S. Patent No. 5,657,390 (SSL Patent) на изобретение, описанное как SSL. IETF рассматривает возможность адаптации SSL в качестве транспортного протокола с функциями защиты. Компания Netscape разрешила бесплатную адаптацию и использование протокола SSL на следующих условиях:

    • если у имеется действующая лицензия SSL Ref, включающая исходные коды от Netscape, дополнительной лицензии в связи с патентом SSL не требуется;

    • при отсутствии лицензии SSL Ref можно получить бесплатную лицензию для реализаций, покрываемых патентом SSL или спецификацией IETF TLS при условии отсутствия каких-либо патентных претензий к Netscape или иным компаниям в части реализации SSL или рекомендаций IETF TLS.

Что такое «патентные претензии» (Patent Claims):

патентные претензии или претензии, связанные с иностранными или внутренними патентами, которые:

  1. будут нарушены в случае реализации методов или создания продукции в соответствии со спецификацией IETF TLS;

  2. будут нарушать патент SSL.

Internet Society, Internet Architecture Board, Internet Engineering Steering Group и Corporation for National Research Initiatives не имеют каких-либо позиций относительно корректности и сферы действия патентов, а также условиях их использования. Internet Society и другие группы, упомянутые выше, не принимали каких-либо решений в части других прав интеллектуальной собственности, которые могут быть применены в связи с этим стандартом. Все решения этих вопросов пользователь принимает на свою ответственность.

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

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

Литература

[3DES] W. Tuchman, «Hellman Presents No Shortcut Solutions To DES,»IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.

[BLEI] Bleichenbacher D., «Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1» in Advances in Cryptology — CRYPTO’98, LNCS vol. 1462, pages: 1—12, 1998.

[DES] ANSI X3.106, «American National Standard for Information Systems-Data Link Encryption,» American National Standards Institute, 1983.

[DH1] W. Diffie and M. E. Hellman, «New Directions in Cryptography,» IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, pp. 74-84.

[DSS] NIST FIPS PUB 186, «Digital Signature Standard,» National Institute of Standards and Technology, U.S. Department of Commerce, May 18, 1994.

[FTP] Postel J., and J. Reynolds, «File Transfer Protocol», STD 9, RFC 959, October 1985.

[HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, «Hypertext Transfer Protocol — HTTP/1.0», RFC 1945, May 1996.

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

[IDEA] X. Lai, «On the Design and Security of Block Ciphers,» ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

[MD2] Kaliski, B., «The MD2 Message Digest Algorithm», RFC 131914, April 1992.

[MD5] Rivest, R., «The MD5 Message Digest Algorithm», RFC 1321, April 1992. (перевод)

[PKCS1] RSA Laboratories, «PKCS #1: RSA Encryption Standard,» version 1.5, November 1993.

[PKCS6] RSA Laboratories, «PKCS #6: RSA Extended Certificate Syntax Standard,» version 1.5, November 1993.

[PKCS7] RSA Laboratories, «PKCS #7: RSA Cryptographic Message Syntax Standard,» version 1.5, November 1993.

[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, «Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile», RFC 2459, January 1999.

[RC2] Rivest, R., «A Description of the RC2(r) Encryption Algorithm», RFC 2268, January 1998.

[RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption Algorithm, Work in Progress.

[RSA] R. Rivest, A. Shamir, and L. M. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems,» Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.

[RSADSI] Контакт в RSA Data Security, Inc., Тел.: 415-595-8782

[SCH] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C, Published by John Wiley & Sons, Inc. 1994.

[SHA] NIST FIPS PUB 180-1, «Secure Hash Standard,» National Institute of Standards and Technology, U.S. Department of Commerce, Work in Progress, May 31, 1994.

[SSL2] Hickman, Kipp, «The SSL Protocol», Netscape Communications Corp., Feb 9, 1995.

[SSL3] A. Frier, P. Karlton, and P. Kocher, «The SSL 3.0 Protocol», Netscape Communications Corp., Nov 18, 1996.

[TCP] Postel, J., «Transmission Control Protocol,» STD 7, RFC 793, September 1981. (перевод)

[TEL] Postel J., and J. Reynolds, «Telnet Protocol Specifications», STD 8, RFC 854, May 1993.

[TEL] Postel J., and J. Reynolds, «Telnet Option Specifications», STD 8, RFC 855, May 1993.

[X509] CCITT. Recommendation X.509: «The Directory – Authentication Framework». 1988.

[XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data Representation Standard, August 1995.

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

Win Treese

Open Market

EMail: treese@openmarket.com

Редакторы

Christopher Allen Tim Dierks

Certicom Certicom

EMail: callen@certicom.com EMail: tdierks@certicom.com

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

Tim Dierks Philip L. Karlton

Certicom Netscape Communications

EMail: tdierks@certicom.com

Alan O. Freier Paul C. Kocher

Netscape Communications Independent Consultant

EMail: freier@netscape.com EMail: pck@netcom.com

Остальные участники

Martin Abadi Robert Relyea

Digital Equipment Corporation Netscape Communications

EMail: ma@pa.dec.com EMail: relyea@netscape.com

Ran Canetti Jim Roskind

IBM Watson Research Center Netscape Communications

EMail: canetti@watson.ibm.com EMail: jar@netscape.com

Taher Elgamal Micheal J. Sabin, Ph. D.

Securify Consulting Engineer

EMail: elgamal@securify.com EMail: msabin@netcom.com

Anil R. Gangolli Dan Simon

Structured Arts Computing Corp. Microsoft

EMail: gangolli@structuredarts.com EMail: dansimon@microsoft.com

Kipp E.B. Hickman Tom Weinstein

Netscape Communications Netscape Communications

EMail: kipp@netscape.com EMail: tomw@netscape.com

Hugo Krawczyk

IBM Watson Research Center

EMail: hugo@watson.ibm.com

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

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

nmalykh@protocols.ru

Комментарии

The discussion list for the IETF TLS working group is located at the e-mail address <ietf-tls@lists.consensus.com>. Information on the group and information on how to subscribe to the list is at http://lists.consensus.com/.

Archives of the list can be found at: http://www.imc.org/ietf-tls/mail-archive/

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

1Transport Layer Security – безопасность на транспортном уровне.

2Network или big endian.

3Неинтерпретируемые данные – Прим. перев.

4С помощью MAC. Прим. перев.

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

6A man in the middle.

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

8National Institute of Standards and Technology — Национальный институт стандартов и технологии США.

9Совпадение хэш-значений для разных входных данных. Прим. перев.

10Secure Hash Algorithm.

11Secure Socket Layer.

12Pseudorandom number generator.

13The United States Patent and Trademark Office.

14Документ признан устаревшим и отменен RFC 6149. Прим. перев.




RFC 2486 The Network Access Identifier

Network Working Group                                       B. Aboba
Request for Comments: 2486                                 Microsoft
Category: Standards Track                                 M. Beadles
                                          WorldCom Advanced Networks
                                                        January 1999

Идентификатор доступа в сеть

The Network Access Identifier

PDF

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

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

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

Copyright (C) The Internet Society (1999).

1. Тезисы

Для повышения уровня интероперабельности служб роуминга и туннелирования желательно иметь стандартизованный метод идентификации пользователей. В этом документе предлагается синтаксис идентификатора доступа в сеть (NAI1) — идентификатора пользователя (userID), представляемого клиентом в процессе аутентификации PPP. Предполагается, что такие идентификаторы представляют интерес для поддержки роуминга и туннелирования. «Возможность роуминга2» можно определить, как возможность использования любого из множества доступных поставщиков услуг доступа в Internet (ISP3) при наличии соглашения на обслуживание лишь с одним из провайдеров. Примерами ситуаций, когда может потребоваться роуминг, являются «конфедерации ISP» и обеспечиваемый через ISP доступ в корпоративную сеть.

2. Введение

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

  • Региональные ISP, работающие на определенных территориях, могут объединяться для обслуживания пользователей на большей территории.
  • Национальные ISP могут объединяться с другими национальными ISP-компаниями для предоставления доступа по коммутируемым линиям в нескольких странах.
  • Предприятия, которые хотят предложить своим сотрудникам полнофункциональный пакет услуг доступа по коммутируемым линиям в глобальном масштабе. Такой пакет услуг может включать доступ в Internet, а также защищенный доступ в корпоративные сети с использованием технологии виртуальных частных сетей (VPN4), с помощью протоколов туннелирования PPTP, L2F, L2TP, IPSEC.

Для расширения интероперабельности служб роуминга и туннелирования желательно иметь стандартизованный метод идентификации пользователей. В данном документе предлагается синтаксис идентификаторов доступа в сеть (NAI). Примеры реализации систем с использованием NAI и описание семантики идентификаторов можно найти в документе [1].

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

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

Network Access Identifier

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

Network Access Server

Сервер доступа в сеть (NAS) представляет собой устройство, к которому клиенты обращаются по коммутируемым телефонным линиям для получения доступа в сеть. В контексте PPTP серверы доступа обычно называют концентраторами доступа PPTP (PAC5), а в контексте L2TP – концентраторами доступа L2TP (LAC6).

Roaming Capability

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

Tunneling Service

Туннельный сервис – это любой тип сетевых услуг, обеспечиваемых с использованием протоколов туннелирования типа PPTP, L2F, L2TP, IPSEC. Примером туннельного сервиса является защищенный доступ в корпоративные сети с использованием технологии виртуальных частных сетей (VPN).

2.2. Спецификация требований

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

2.3. Цель

Как отмечено в [1], существует множество служб, поддерживающих роуминг для доступа по коммутируемым линиям, и число ISP, вовлеченных в роуминговые соглашения, быстро растет.

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

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

В этом документе предлагаются идентификаторы NAI в форме user@realm7. Отметим, что пользовательская часть NAI полностью соответствует требованиям BNF, указанным в [5], а BNF для области (realm) допускает использование цифр, что противоречит требованиям BNF, описанным в [4]. Это изменение отражает реальную ситуацию, поскольку доменные имена, начинающиеся с цифр, которые не допускаются требованиями BNF документа [4], реально используются в FQDN (например, 3com.com) и корректно обрабатываются современными программами.

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

3. Определение формата NAI

Описанный ниже синтаксис NAI приводится в формате ABNF, соответствующем требованиям [7]. Синтаксис имен пользователей соответствует требованиям [5], а синтаксис идентификаторов областей – обновленной версии [4].

   nai         = username / ( username "@" realm )
   username    = dot-string
   realm       = realm "." label
   label       = let-dig * (ldh-str)
   ldh-str     = *( Alpha / Digit / "-" ) let-dig
   dot-string  = string / ( dot-string "." string )
   string      = char / ( string char )
   char        = c / ( "\" x )
   let-dig     = Alpha / Digit
   Alpha       = %x41-5A / %x61-7A   ; A-Z / a-z
   Digit       = %x30-39  ;0-9
   c           = < любые из 128 символов ASCII, кроме символов special и SP >
   x           = %x00-7F  ; все 128 символов ASCII без исключений
   SP          = %x20 ; символ пробела
   special     = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
                  / "," / ";" / ":" / "@" / %x22  / Ctl
   Ctl         = %x00-1F / %x7F
                 ; управляющие символы (с кодом ASCII от 0 до 31 включительно и 127)

Примеры корректных идентификаторов доступа в сеть включают:

        fred@3com.com
        fred@foo-9.com
        fred_smith@big-co.com
        fred=?#$&*+-/^smith@bigco.com
        fred@bigco.com
        nancy@eng.bigu.edu
        eng!nancy@bigu.edu
        eng%nancy@bigu.edu

Ниже показаны примеры некорректных NAI:

        fred@foo
        fred@foo_9.com
        @howard.edu
        fred@bigco.com@smallco.com
        eng:nancy@bigu.edu
        eng;nancy@bigu.edu
        <nancy>@bigu.edu

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

[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, «Review of Roaming Implementations», RFC 2194, September 1997.

[2] Rigney C., Rubens A., Simpson W. and S. Willens, «Remote Authentication Dial In User Service (RADIUS)», RFC 21388, April 1997.

[3] Rigney C., «RADIUS Accounting», RFC 21391, April 1997.

[4] Mockapetris, P., «Domain Names — Implementation and Specification», STD 13, RFC 1035, November 1987.

[5] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 8219, August 1982.

[6] Gulbrandsen A. and P. Vixie, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2052, October 1996.

[7] Crocker, D. and P. Overrell, «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

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

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

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

Поскольку идентификаторы NAI показывают принадлежность пользователя к сети, они могут помочь атакующим в исследовании пространства пользовательских имен. Обычно такая проблема возникает при использовании протоколов, в которых пользовательские имена передаются открытым текстом через сеть Internet (таких, как протокол RADIUS, описанный в документах [2] и [3]). Для предотвращения утечки сведений об именах пользователей, можно применять конфиденциальные службы, обеспечиваемые IPSEC [8].

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

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

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

Отметим, что использование FQDN в качестве имени области не подразумевает использования DNS для поиска сервера аутентификации или маршрутизации используемых при аутентификации данных. Поскольку роуминг данных обеспечивается в сравнительно небольших областях, существующие реализации обычно поддерживают сведения о серверах аутентификации в домене и маршрутизируют данные аутентификации на основе локальных сведений из конфигурационных параметров proxy. Реализации, описанные в документе [1] не требуют использования DNS для поиска сервера аутентификации в домене, хотя такой поиск можно осуществить с использованием записей DNS SRV, описанных в [6]. Существующим реализациям не требуются и динамические протоколы маршрутизации или иные средства глобального распространения маршрутных данных. Отметим также, что идентификатор NAI совсем не обязан представлять собой корректный адрес электронной почты.

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

Спасибо Глену Зорну (Glen Zorn) из Microsoft за полезные дискуссии.

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

Bernard Aboba

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

Phone: 425-936-6605

EMail: bernarda@microsoft.com

 

Mark A. Beadles

WorldCom Advanced Networks

5000 Britton Rd.

Hilliard, OH 43026

Phone: 614-723-1941

EMail: mbeadles@wcom.net


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

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

EMail: nmalykh@gmail.com

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

Copyright (C) The Internet Society (1999). Все права защищены.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

1 Network Access Identifier.

2 Roaming capability.

3 Internet service provider.

4 Virtual Private Network.

5 PPTP Access Concentrator

6 L2TP Access Concentrator

7 Пользователь@область (сеть)

9Этот документ признан устаревшим и заменен RFC 2821, который, в свою очередь, был заменен RFC 5321. Переводы документов доступны на сайте www.protocols.ru. Прим. перев.

10Этот документ в настоящее время заменен RFC 4301, перевод которого доступен на сайте www.protocols.ru. Прим. перев.




RFC 2481 A Proposal to add Explicit Congestion Notification (ECN) to IP

Network Working Group                                K. Ramakrishnan
Request for Comments: 2481                        AT&T Labs Research
Category: Experimental                                      S. Floyd
                                                                LBNL
                                                        January 1999

Явное уведомление о насыщении (ECN)

A Proposal to add Explicit Congestion Notification (ECN) to IP

PDF

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

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

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

Тезисы

В данном документе описывается предлагаемое добавление флага ECN1 в IP. Протокол TCP в настоящее время является доминирующим протоколом транспортного уровня в Internet. Начнем с описания процедуры отбрасывания пакетов протоколом TCP в качестве индикации насыщения (перегрузки). После этого будет показано, что добавление активного управления очередями (например, RED2) в инфраструктуру Internet, в результате которого маршрутизаторы смогут детектировать насыщение до момента переполнения очереди, позволит маршрутизаторам избавиться от необходимости отбрасывания пакетов для индикации перегрузки. Маршрутизаторы смогут вместо отбрасывания устанавливать флаг CE3 в заголовке пакетов поддерживающих ECN транспортных протоколов. Описывается процедура установки флага CE в маршрутизаторах, а также изменения, которые нужно внести в протокол TCP для поддержки ECN. Изменения других протоколов транспортного уровня (например, негарантированная доставка пакетов unicast или multicast, гарантированная доставка multicast-пакетов, другие протоколы гарантированной доставки пакетов unicast) могут рассматриваться при разработке или стандартизации таких протоколов.

1. Соглашение об использовании терминов

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

2. Введение

Алгоритмы контроля насыщения и предотвращения перегрузки протокола TCP основаны на представлении сети, как «черного ящика» [Jacobson88, Jacobson90]. Насыщение или его отсутствие определяется конечными системами путем проверки состояния сети за счет увеличения нагрузки (расширения окна насыщения — числа пакетов, остающихся в сети) до тех пор, пока не возникнет насыщение и связанная с ним потеря пакетов. Трактовка сети, как «черного ящика», и потери пакетов, как индикатора перегрузки, приемлема для случаев передачи по протоколу TCP данных, которые не чувствительны или не критичны к задержкам или потере отдельных пакетов. Алгоритмы контроля насыщения в TCP используют встроенные методы (такие, как Fast Retransmit и Fast Recovery4) для минимизации влияния потерь с точки зрения пропускной способности.

Однако эти алгоритмы не подходят для приложений, которые чувствительны к задержкам или потере одного или нескольких пакетов. Интерактивные системы (например, telnet, просмотр web-страниц, передача аудио/видео-потоков) могут быть чувствительны к потере пакетов (при использовании транспорта без гарантии доставки типа UDP) или увеличению задержки, вызванному повтором передачи в результате потери пакета (при использовании гарантированного транспорта типа TCP).

Поскольку TCP определяет приемлемый размер окна насыщения путем увеличения размера этого окна до тех пор, пока не начнется потеря (отбрасывание) пакетов, это может приводить к переполнению очередей в маршрутизаторах, являющихся узким местом в сети. Большинство алгоритмов отбрасывания пакетов в маршрутизаторах не чувствительно к нагрузке, создаваемой отдельным потоком, что означает возможность отбрасывания пакетов из некоторых потоков, чувствительных к задержкам. Активные механизмы управления очередями детектируют насыщение до того, как переполнится очередь, и обеспечивают индикацию насыщения для конечных узлов. Преимущества активного управления очередями обсуждаются в RFC 2309 [RFC2309]. Такое управление позволяет избавиться от некоторых негативных свойств систем управления очередями, основанных на отбрасывании пакетов при переполнении (в частности, от нежелательной синхронизации потери пакетов во множестве потоков данных). Более важно, что в системах активного управления очередями транспортные протоколы с контролем насыщения (например, TCP) не используют переполнение буферов в качестве индикатора перегрузки. Это может снизить избыточные задержки в очереди для всех типов трафика, использующих эту очередь.

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

3. Допущения и общие принципы

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

  1. Длительность периода насыщения может меняться в широких пределах. Периоды насыщения могут превышать время кругового обхода (RTT).

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

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

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

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

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

  7. Следует признать, что не все конечные системы могут кооперироваться в плане контроля насыщения. Однако новым механизмам не следует упрощать для приложений TCP запрет контроля насыщения. Преимущества от использования новых механизмов типа ECN не должны быть значительными.

4. Упреждающее детектирование перегрузки

Упреждающее детектирование RED представляет собой механизм активного управления очередями, предложенный для детектирования начинающейся перегрузки [FJ93] и развернутый уже в магистральных сетях Internet [RFC2309]. Хотя RED предложен в качестве механизма общего назначения для индикации насыщения, в современной среде Internet использование RED ограничено отбрасыванием пакетов для индикации насыщения. RED отбрасывает пакеты в тех случаях, когда средний размер очереди превышает пороговое значение, не дожидаясь переполнения очереди. Однако, когда RED отбрасывает пакеты до переполнения очереди, это отбрасывание не вызвано нехваткой памяти.

RED может устанавливать бит CE в заголовке пакета вместо того, чтобы отбросить пакет, если такой бит присутствует в заголовке IP и понятен транспортному протоколу. Использование бита CE будет позволять транспортному протоколу получателя избавиться от избыточной задержки, связанной с повтором передачи после отбрасывания пакета. Для обозначения пакетов с установленным битом CE далее будет использоваться термин CE-пакет.

5. Явное уведомление о насыщении в IP

Предлагается обеспечивать в Internet индикацию насыщения для наступающей перегрузки (как в RED и более ранней работе [RJ90]), когда уведомление о возможной перегрузке, выполняемое путем маркировки пакетов, может произойти раньше, нежели начнется отбрасывание пакетов. Для использования этого метода требуется добавить двухбитовое поле ECN в заголовок IP. Бит ECT5 будет устанавливаться отправителем данных для индикации удаленной точке поддержки ECN на уровне транспортного протокола. Бит CE будет устанавливаться маршрутизатором для индикации насыщения конечным узлам. Маршрутизаторы, получающие пакеты при заполненных очередях, будут отбрасывать такие пакеты, как это делалось и раньше.

Для поля ECN предлагается использовать биты 6 и 7 октета TOS в заголовках IPv4. Бит 6 используется для флага ECT, а бит 7 – для CE. Октету TOS в заголовке IPv4 соответствует октет Traffic Class в заголовке IPv6. Определения для октетов IPv4 TOS [RFC791] и IPv6 Traffic Class должны быть заменены полем DS (Differentiated Services) [DIFFSERV]. Биты 6 и 7 указаны в [DIFFSERV], как неиспользуемые (Currently Unused). В параграфе 19 приведена краткая история использования октета TOS.

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

При получении поддерживающим ECN транспортным протоколом одного CE-пакета алгоритм контроля насыщения в конечной системе должен работать в точности так же, как при отбрасывании одного пакета. Например, для поддерживающей ECN реализации протокола TCP требуется, чтобы отправитель уменьшил вдвое размер окна насыщения в ответ на любой факт отбрасывания пакета или получения индикатора ECN. Однако следует отметить, что существуют некоторые существенные различия в реакции отправителя TCP, связанные деталями поведения протокола в ответ на индикацию насыщения. Для реакции TCP на получение индикации ECN не рекомендуется выполнение таких процедур, как замедленный старт (slow-start в Tahoe TCP) в ответ на отбрасывание пакетов или ожидание Reno TCP в течение периода около половины времени кругового обхода при использовании быстрого восстановления (Fast Recovery).

Одной из причин требования идентичной реакции на индикацию насыщения при получении CE-пакета или отбрасывании пакета является необходимость обеспечения постепенного развертывания ECN как в конечных системах, так и в маршрутизаторах. Некоторые маршрутизаторы могут отбрасывать ECN-пакеты6 (например, при использовании некоторых правил детектирования перегрузки в RED), тогда как другие маршрутизаторы будут устанавливать бит CE при таких же условиях насыщения. Подобно этому, маршрутизатор может отбрасывать не поддерживающие ECN пакеты или устанавливать бит CE в ECN-пакетах при одинаковых условиях насыщения. Разная реакция на индикацию насыщения путем установки бита CE и путем отбрасывания пакетов может приводить к различным (неправильным) трактовкам для разных потоков.

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

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

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

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

Предполагается, что маршрутизаторы будут устанавливать бит CE в ответ на начинающуюся перегрузку, указываемую средним размером очереди, с использованием алгоритма RED, предложенного в [FJ93, RFC2309]. По имеющимся у авторов сведениям этот вариант является единственным предложением, обсуждаемым IETF, для упреждающего отбрасывания пакетов маршрутизаторами до переполнения буферов. Однако данный документ не пытается задавать тот или иной механизм активного управления очередями, оставляя решение этого вопроса (если он возникнет) за IETF. Хотя использование ECN связано с вопросом о необходимости иметь подходящий механизм активного управления очередями в маршрутизаторах, авторы не настаивают на использовании именно этого механизма. Методы активного управления очередями были разработаны и развернуты независимо от ECN с отбрасыванием пакетов для индикации насыщения еще до начала использования ECN в архитектуре IP.

6. Поддержка со стороны транспортного протокола

ECN требует поддержки со стороны транспортного протокола в дополнение к функциональности, обеспечиваемой полем ECN в заголовке пакета IP. Транспортный протокол может требовать согласования между конечными точками при организации соединения для проверки поддержки ими ECN, чтобы отправитель мог устанавливать код ECT в передаваемых пакетах. Во-вторых, транспортный протокол должен быть способен соответствующим образом реагировать на получение пакетов CE. Эта реакция может выражаться в форме информирования получателем отправителя данных о полученном пакете CE (например, TCP), отказа получателя от участия в многоуровневой multicast-группе (например, RLM [MJV96]) или в ином виде, обеспечивающем, в конечном итоге, снижение скорости поступления потока данных для этого получателя.

В этом документе рассматривается добавление поддержки ECN7 только для протокола TCP, а рассмотрение вопросов использования ECN в других транспортных протоколах оставлено для будущих исследований. Для TCP добавление ECN требует поддержки трех новых механизмов — согласование между конечными точками в процессе организации соединения для проверки поддержки ECN на обеих сторонах; флаг ECN-Echo (ECE) в заголовке TCP, чтобы получатель мог информировать отправителя о получении пакета CE; флаг CWR8 в заголовке TCP, чтобы отправитель мог информировать получателя о снижении размера окна насыщения. Очевидно, что функциональность, требуемая от других протоколов (в частности, протоколов групповой адресации с гарантиями доставки и без таковых), будет отличаться и определится при стандартизации этих транспортных протоколов в IETF.

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

6.1. TCP

В последующих параграфах детально рассматривается предложенное использование ECN в TCP. Эти предложения представлены в той же форме, что и в работе [Floyd94]. Предполагается, что TCP на стороне отправителя использует стандартные алгоритмы контроля насыщения Slow-start, Fast Retransmit и Fast Recovery [RFC2001].

Это предложение задает два новых флага в резервном поле заголовка TCP. Механизм TCP для согласования поддержки ECN использует флаг ECE9 (ECN-Echo) в заголовке TCP. Бит 9 в поле Reserved заголовка TCP предназначен для использования в качестве флага ECN-Echo. Местоположение шестибитового резервного поля заголовка TCP показано на рисунке 3 в RFC 793 [RFC793].

Чтобы обеспечить получателю TCP возможность определения момента прекращения установки флага ECN-Echo, в заголовок TCP добавлен еще один флаг — CWR. Для флага CWR выделен бит 8 резервного поля в заголовке TCP .

Использование этих флагов описано ниже.

6.1.1. Инициализация TCP

На этапе организации соединения TCP модули TCP на стороне отправителя и получателя обмениваются информацией о своем намерении использовать ECN. После завершения этого согласования отправитель TCP устанавливает код ECT в заголовке IP пакета данных для индикации сетевым устройствам возможности и желания использовать ECN для этого пакета. Этот код показывает маршрутизаторам, что они могут маркировать данный пакет кодом CE, если они хотят использовать такой метод индикации насыщения. Если соединение TCP не хочет использовать ECN-уведомление для отдельного пакета, передающая сторона TCP устанавливает в качестве кода ECN значение 0 (т. е., не устанавливает флаг), а получатель TCP игнорирует код CE в полученном пакете.

Когда узел передает пакет TCP SYN, он может установить в заголовке TCP флаги ECN-Echo и CWR. Для пакетов SYN установка флагов ECN-Echo и CWR определена, как индикация того, что передающая сторона TCP поддерживает ECN, а не для индикации насыщения или отклика на насыщение. Точнее говоря, пакет SYN с установленными флагами ECN-Echo и CWR показывает, что передающая пакет SYN реализация TCP будет участововать в ECN в качестве отправителя и получателя. В качестве получателя она будет отвечать на входящие пакеты с флагом CE в заголовке IP установкой флага ECN-Echo в исходящих пакетах TCP ACK. В качестве отправителя она будет отвечать на входящие пакеты с флагом ECN-Echo снижением размера окна насыщения, когда это приемлемо.

Когда хост узел передает пакет SYN-ACK, он может установить флаг ECN-Echo, но не устанавливать флаг CWR. Для пакетов SYN-ACK с установленным флагом ECN-Echo и сброшенным флагом CWR в заголовке TCP опрпределяется, как индикация того, что узел TCP, передавший пакет SYN-ACK, поддерживает ECN.

Возникает вопрос, почему для пакетов SYN используется два связанных с ECN флага в резервном поле заголовка TCP, тогда как в ответном пакете SYN-ACK устанавливается только один связанный с ECN флаг. Такая асимметрия нужна для отказоустойчивого согласования поддержки ECN с некоторыми имеющимися реализациями TCP. Существует по крайней мере одна некорректно работающая реализация TCP, в которой получатели устанавливают в поле Reserved в заголовке TCP пакетов ACK (и, следовательно, SYN-ACK) просто отражение поля Reserved из заголовка TCP принятого пакета данных. Поскольку в пакете TCP SYN для индикации поддержки ECN устанавливаются флаги ECN-Echo и CWR, а в пакетах SYN-ACK — только флаг ECN-Echo, передающая сторона TCP корректно интерпретирует отражение получателем своих флагов, как индикацию отсутствия поддержки ECN на приемной стороне.

6.1.2. Отправитель TCP

Для соединения TCP, использующего ECN, пакеты данных передаются с установленным (1) флагом ECT в заголовке IP. Если отправитель получает пакет ECN-Echo ACK (т. е., пакет ACK с флагом ECN-Echo в заголовке TCP), это означает, что на пути между отправителем и получателем имеется насыщение. Индикацию насыщения следует трактовать просто, как потерю в результате насыщения для TCP без поддержки ECN. Т. е., отправитель TCP снижает вдвое размер окна насыщения cwnd и уменьшает порог замедленного старта ssthresh. Передающему модулю TCP не следует увеличивать окно насыщения в ответ на получение пакета ECN-Echo ACK.

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

После того, как отправитель TCP уменьшает окно насыщения в ответ на пакет CE, входящие подтверждения, которые продолжают приходить, могут влиять на передачу исходящих пакетов, дозволенных уменьшенным окном насыщения. Если окно насыщения содержит только 1 MSS (максимальный размер сегмента) и передающий модуль TCP получает пакет ECN-Echo ACK, передающему TCP следует, в принципе, продолжать уменьшение окна насыщения вдвое. Однако размер окна насыщения ограничен снизу значением в 1 MSS. Если передающий модуль TCP будет продолжать передачу, используя окно насыщения размером 1 MSS, это приведет к передаче одного пакета за период кругового обхода. Мы полагаем, что желательно дальнейшее снижение скорости передачи TCP в ответ на получение пакета ECN-Echo при окне насыщения размером 1 MSS. Мы используем таймер повтора передачи в качестве меры снижения скорости в таких ситуациях. Поэтому, передающему модулю TCP следует сбрасывать таймер повтора при получении пакета ECN-Echo в случае единичного размера окна насыщения. Передающий модуль TCP в результате сможет передать новый пакет только после завершения отсчета таймера повтора.

В работе [Floyd94] обсуждается реакция TCP на ECN более детально. В работе [Floyd98] рассматривается тест с использованием эмулятора ns, который иллюстрирует множество сценариев ECN, включая ECN, за которым следует другой ECN, Fast Retransmit или Retransmit Timeout, Retransmit Timeout или Fast Retransmit, за которым следует ECN, окно насыщения в один пакет, за которым следует ECN.

TCP следует существующим алгоритмам передачи пакетов данных в ответ на прием пакетов ACK, дубликаты подтверждений или тайм-аут повтора [RFC20081].

6.1.3. Получатель TCP

Когда TCP принимает пакет данных CE на стороне получателя, приемный модуль TCP устанавливает флаг ECN-Echo в заголовке TCP следующего пакета ACK. Если на приемной стороне уже есть ожидающий пакет ACK (как в современных реализациях TCP с задержкой подтверждений, передающих пакет ACK по прибытии каждого второго пакета данных), тогда флаг ECN-Echo устанавливается в пакете ACK, если код CE был установлен для любого из подтверждаемых пакетов данных. Т. е., если в любом из подтверждаемых пакетов имеется маркировка CE, возвращаемый пакет ACK будет иметь флаг ECN-Echo.

Для обеспечения устойчивости к отбрасыванию пакетов ACK с флагом ECN-Echo, получатель TCP устанавливает этот флаг в передаваемых впоследствии пакетах ACK. Прекращение передачи флага ECN-Echo получатель TCP инициирует при получении флага CWR в пакете данных от передающей стороны TCP.

Когда поддерживающий ECN модуль TCP снижает размер окна насыщения по любой причине (в результате тайм-аута, Fast Retransmit или в ответ на уведомление ECN), TCP устанавливает флаг CWR в заголовке TCP первого пакета данных после снижения размера окна. Если такой пакет данных отбрасывается в сети, передающая сторона TCP будет снова снижать размер окна насыщения и заново передавать отброшенный пакет. Таким образом, сообщение о снижении размера окна насыщения (CWR) гарантированно доставляется получатель данных.

После того, как получатель TCP передает пакет ACK с установленным флагом ECN-Echo, он продолжает устанавливать этот флаг во всех передаваемых пакетах ACK (подтверждающих как пакеты данных с маркером CE, так и пакеты данных без маркера), пока не получит пакет с флагом CWR. После получения пакета CWR подтверждения для последующих пакетов без маркера CE передаются без флага ECN-Echo. Если получатель данных принимает другой пакет CE, он снова начинает передавать пакеты ACK с флагом ECN-Echo. Хотя получение пакета CWR не гарантирует получение отправителем пакета с флагом ECN-Echo, это событие говорит о том, что отправитель уменьшил размер окна насыщения в какой-то момент «после» того, как он передал пакет данных, для которого был установлен маркер CE.

Выше уже было отмечено, что отправитель TCP не должен снижать размер окна насыщения более одного раза в окне данных. Требуются некоторые меры по предотвращению многократного снижения размера окна, когда окно данных включает как отброшенные пакеты, так и пакеты с маркером CE. Этот вопрос рассматривается в работе [Floyd98].

6.1.4. Насыщение на пути ACK

В существующих реализациях механизмов контроля насыщения TCP чистые пакеты подтверждения (т. е., пакеты, содержащие только подтверждение без дополнительных данных) должны передаваться с кодом not-ECT. Современные получатели TCP не имеют механизмов снижения трафика на пути пакетов ACK в ответ на индикацию насыщения. Механизмы отклика на перегрузку в пути доставки пакетов ACK являются предметом современных и будущих исследований (одним из возможных вариантов может служить снижение отправителем размера окна насыщения при получении чистого пакета ACK с кодом CE). Для современных реализаций TCP отбрасывание одного пакета ACK в общем случае оказывает пренебрежимо малое влияние на скорость передачи TCP.

7. Изменения, требуемые для IP и TCP

Требуется спецификация двух битов заголовка IP — флага ECT10) и флага CE11. Нулевое значение бита ECT говорит о том, что транспортный протокол будет игнорировать флаг CE. Это значение бита ECT используется по умолчанию. Если флаг ECT установлен (1), это говорит о том, что транспортный протокол способен принимать участие в ECN.

По умолчанию флаг CE имеет значение 0. Маршрутизатор устанавливает CE = 1 для индикации перегрузки конечным узлам. Маршрутизаторам ни в коем случае не следует сбрасывать бит CE в заголовках пакетов из 1 в 0.

В протокол TCP требуется внести три изменения — фаза согласования на этапе организации соединения для определения поддержки ECN обоими узлами и два новых флага в заголовке TCP из резервного пространства в поле флагов TCP. Флаг ECN-Echo используется получателем данных для информирования отправителя полученного пакета CE. Флаг CWR используется отправителем данных для информирования получателя о снижении размера окна насыщения.

8. Отсутствие связи с индикаторами ATM EFCI и Frame Relay FECN

Поскольку механизмы индикации насыщения в ATM и Frame Relay без связи со средним размером очереди, как основой для определения перегрузки промежуточного узла, мы полагаем, что такая индикация будет создавать избыточный шум. Реакция отправителя TCP в соответствии с данной спецификацией для ECN не является подходящим вариантом для такого шумного сигнала о насыщении. Мы надеемся, что механизмы ATM EFCI и Frame Relay FECN будут поэтапно развертываться в сетях ATM. Однако, если маршрутизаторы, имеющие интерфейсы в сети ATM, получат способ определения среднего размера очереди для интерфейса и станут использовать этот размер для надежного детектирования перегрузки в подсети ATM, они могут использовать уведомления ECN, описанные в данной спецификации.

Мы подчеркиваем, что транспортный уровень реагирует в плане контроля насыщения на «один» пакет с флагом CE в заголовке IP так же, как он реагировал бы на отбрасывание пакета. Таким образом, бит CE не обеспечивает достаточно хорошего соответствия сигналам, основанным на мгновенном размере очереди. Однако эксперименты с методами управления на уровне 2 (например, в коммутаторах ATM и Frame Relay) следует поощрять. Например, используя схемы типа RED (когда пакеты маркируются на основе превышения средним размером очереди заданного порога), устройства канального уровня могут обеспечивать достаточно надежную индикацию насыщения. Когда все устройства уровня 2 на пути установят принятый на этом уровне маркер возможного насыщения (например, бит EFCI для ATM или бит FECN для Frame Relay) с использованием надежного детектирования перегрузки, интерфейс маршрутизатора в сеть уровня 2 сможет транслировать такие маркеры в маркеры CE заголовков IP. Мы признаем, что в сегодняшней практике и стандартах такого не наблюдается. Однако продолжение экспериментов в этом направлении может дать информацию, которая позволит найти способ перехода от существующих механизмов канального уровня к более надежной индикации насыщения с использованием для индикации перегрузки одного бита.

9. Неподатливость конечных узлов

В этом разделе рассматривается опасность ECN для неподатливых12 конечных узлов (т. е., узлов, которые устанавливают код ECT в передаваемых пакетах, но не реагируют на получение пакетов с кодом CE). Мы понимаем, что добавление ECN в архитектуру IP не повышает сколь-нибудь существенно общий уровень уязвимости архитектуры со стороны невосприимчивых потоков.

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

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

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

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

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

10. Неподатливость в сети

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

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

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

10.1. Инкапсулированные пакеты

При обработке битов CE и ECT в процессах инкапсуляции и декапсуляции для туннелей следует соблюдать осторожность.

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

При декапсуляции пакета используются приведенные здесь правила для флага CE. Если бит ECT имеет значение 1 как во внешнем, так и во внутреннем заголовке, нужно использовать операцию «логическое ИЛИ» (OR) для полей CE внешнего и внутреннего заголовка (т. е., при установленном во внешнем заголовке флаге CE этот флаг должен копироваться во внутренний заголовок). Если флаг ECT в одном из заголовков сброшен (0), значение бита CE во внешнем заголовке игнорируется. Это требование в настоящее время не применяется при декапсуляции в туннелях IPsec.

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

10.2. Туннели IPsec

Протокол IPsec, как определено в [ESP, AH], не включает поле ECN заголовка IP в криптографические преобразования (в туннельном режиме поле ECN не включается во внутренний заголовок IP). Следовательно, изменение поля ECN узлом сети не оказывает влияния на сквозную защиту IPsec, поскольку изменение этого поля не может быть зафиксировано средствами контроля целостности IPsec. В результате этого IPsec не обеспечивает какой-либо защиты от враждебного изменения поля ECN (т. е., MITM-атак13), поскольку враждебные изменения также не будут оказывать влияния на сквозную защиту IPsec. В некоторых средах способность изменить поле ECN без влияния на проверку целостности IPsec позволяет создавать скрытые каналы — если требуется предотвратить создание такого канала или снизить доступную для него полосу, значение поля ECN во внешнем заголовке можно обнулять на входном и выходном узлах.

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

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

Обсуждение взаимодействия ECN с туннелями IPsec во многом основано на обсуждениях и документах рабочей группы Differentiated Services.

10.3. Отброшенные и поврежденные пакеты

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

Однако транспортные протоколы типа TCP не обязательно детектируют отбрасывание любых пакетов (в частности, пакетов, содержащих лишь подтверждение ACK); например, TCP не снижает скорость доставки последующих пакетов ACK в ответ на ранее отброшенные пакеты ACK. Любые предложения по расширению ECN-Capability на такие пакеты будут приводить к возникновению проблем, таких, как маркировка пакета ACK кодом CE и последующее отбрасывание такого пакета в сети.

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

11. Обзор связанных работ

В работе [Floyd94] рассматриваются преимущества и недостатки, вносимые добавлением ECN в архитектуру TCP/IP. Как показано в основанном на моделировании сравнении, преимущество ECN заключается в предотвращении неоправданного отбрасывания пакетов для краткосрочных и чувствительных к задержкам соединений TCP. Другим преимуществом ECN является предотвращение ненужных тайм-аутов повтора передачи в TCP. В этом документе подробно рассматривается интеграция ECN с механизмами контроля насыщения TCP. Возможными недостатками ECN, отмеченными в работе, является то, что не поддерживающие ECN соединения TCP могут анонсировать себя, как ECN-совместимые, а также то, что пакеты TCP ACK, передающие сообщение ECN-Echo, могут отбрасываться в сети. Решение первого из этих вопросов был рассмотрено в разделе 8 настоящего документа, а второй решается с помощью предложений параграфа 5.1.3 для флага CWR в заголовке TCP.

В работе [CKLTZ97] описана экспериментальная реализация ECN для IPv6. Эксперименты включали реализацию ECN в существующей системе RED для FreeBSD. Было проведено множество экспериментов для демонстрации контроля за средним размером очереди в маршрутизаторе, производительности ECN для одного соединения TCP через перегруженный маршрутизатор и беспристрастности для множества одновременных соединений TCP. Один из результатов этих экспериментов заключается в том, что отбрасывание пакетов при переносе больших объемов данных может снижать производительность значительно сильнее, нежели это происходит при маркировке пакетов.

Поскольку экспериментальная реализация [CKLTZ97] в какой-то мере предшествовала разработке данного документа, она не вполне соответствует требованиям, содержащимся здесь. Например, в экспериментальной реализации не использовался флаг CWR, а вместо этого получатель передавал бит ECN-Echo в пакете ACK.

Работы [K98] и [CKLTZ98], основанные на [CKLTZ97], содержат дальнейший анализ преимуществ внедрения ECN для TCP. Заключение этих работ состоит в том, что TCP с поддержкой ECN обеспечивает некоторое повышение производительности по сравнению с TCP без ECN, потоки ECN TCP не подавляют потоков без поддержки ECN и ECN TCP обеспечивает устойчивость к двухстороннему трафику, перегрузке в обоих направлениях и множеству перегруженных шлюзов. Многочисленные эксперименты с короткими web-транзакциями показывают, что время передачи в большинстве случаев слабо зависит от применения ECN, однако иногда при использовании ECN время передачи существенно сокращалось по сравнению с передачей без использования ECN. При таких коротких передачах отбрасывание первого пакета в случае без поддержки ECN может приводить к значительному замедлению процесса за счет ожидания (до 6 сек.) тайм-аута повторной передачи.

На Web-странице ECN [ECN] приведены ссылки на другие реализации ECN находящиеся в стадии разработки.

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

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

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

В подготовку этого RFC внесло свой вклад множество людей. В частности, мы выражаем свою признательность Kenjiro Cho за предложенный механизм TCP для согласования ECN-Capability, Kevin Fall за предложенный флаг CWR, Steve Blake за материал по пересчету контрольной суммы заголовка IPv4, Jamal Hadi Salim за обсуждение ECN, а также Steve Bellovin, Jim Bound, Brian Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall и Vern Paxson за обсуждение вопросов безопасности. Мы также благодарим исследовательскую группу Internet End-to-End Research Group for

за полезные дмскуссии.

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

[AH] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 240214, November 1998.

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

[CKLT98] Chen, C., Krishnan, H., Leung, S., Tang, N., and Zhang, L., «Implementing ECN for TCP/IPv6», presentation to the ECN BOF at the L.A. IETF, March 1998, URL «http://www.cs.ucla.edu/~hari/ecn-ietf.ps«.

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

[ECN] «The ECN Web Page», URL «http://www-nrg.ee.lbl.gov/floyd/ecn.html«.

[ESP] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload», RFC 240617, November 1998.

[FJ93] Floyd, S., and Jacobson, V., «Random Early Detection gateways for Congestion Avoidance», IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413. URL «ftp://ftp.ee.lbl.gov/papers/early.pdf«.

[Floyd94] Floyd, S., «TCP and Explicit Congestion Notification», ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23. URL «ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z«.

[Floyd97] Floyd, S., and Fall, K., «Router Mechanisms to Support End-to-End Congestion Control», Technical report, February 1997. URL «http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html«.

[Floyd98] Floyd, S., «The ECN Validation Test in the NS Simulator», URL «http://www-mash.cs.berkeley.edu/ns/«, test tcl/test/test-all-ecn.

[K98] Krishnan, H., «Analyzing Explicit Congestion Notification (ECN) benefits for TCP», Master’s thesis, UCLA, 1998, URL «http://www.cs.ucla.edu/~hari/software/ecn/ecn_report.ps.gz«.

[FRED] Lin, D., and Morris, R., «Dynamics of Random Early Detection», SIGCOMM ’97, September 1997. URL «http://www.inria.fr/rodeo/sigcomm97/program.html#ab078«.

[Jacobson88] V. Jacobson, «Congestion Avoidance and Control», Proc. ACM SIGCOMM ’88, pp. 314-329. URL «ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z«.

[Jacobson90] V. Jacobson, «Modified TCP Congestion Avoidance Algorithm», Message to end2end-interest mailing list, April 1990. URL «ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt«.

[MJV96] S. McCanne, V. Jacobson, and M. Vetterli, «Receiver-driven Layered Multicast», SIGCOMM ’96, August 1996, pp. 117-130.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

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

[RFC1141] Mallory, T. and A. Kullberg, «Incremental Updating of the Internet Checksum», RFC 114118, January 1990.

[RFC1349] Almquist, P., «Type of Service in the Internet Protocol Suite», RFC 134919, July 1992.

[RFC1455] Eastlake, D., «Physical Link Security Type of Service», RFC 14556, May 1993.

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

[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, «Recommendations on Queue Management and Congestion Avoidance in the Internet», RFC 2309, April 1998.

[RJ90] K. K. Ramakrishnan and Raj Jain, «A Binary Feedback Scheme for Congestion Avoidance in Computer Networks», ACM Transactions on Computer Systems, Vol.8, No.2, pp. 158-181, May 1990.

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

Вопросы безопасности рассмотрены в разделе 9.

16. Пересчет контрольной суммы заголовка IPv4

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

В RFC 1141 [RFC1141] обсуждается нарастающее обновление контрольной суммы IPv4 после уменьшения значения поля TTL. Нарастающее обновление контрольной суммы IPv4 после установки кода CE описано ниже. Обозначим HC исходную контрольную сумму заголовка для пакета ECT(0), а HC’ будет новой контрольной суммой после установки бита CE (т. е., поле ECN изменит значение с 10 на 11). Тогда контрольная сумма заголовка вычисляется путем вычитания дополнения до 1:

HC' = { HC - 1 HC > 1
      { 0x0000 HC = 1

Для расчета контрольной суммы на машинах с дополнением до двух HC’ после установки флага CE будет:

HC' = { HC - 1 HC > 0
      { 0xFFFE HC = 0

17. Обоснование для флага ECT

Необходимость введения кода ECT обусловлена тем, что развертывание ECN в сети Internet будет осуществляться поэтапно и не все транспортные протоколы и маршрутизаторы будут понимать ECN. При использовании кода ECT маршрутизатор может отбрасывать пакеты, которые не совместимы с ECN, но может «взамен» отбрасывания устанавливать код CE в пакетах, которые «поддерживают» ECN. Поскольку код ECT позволяет конечному узлу получать код CE «вместо» информации об отбрасывании пакета, это дает стимул для внедрения ECN.

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

В этом случае возможны два варианта: (1) поддерживающий ECN поток снижает скорость, не поддерживающий ECN поток забирает освободившуюся полосу и насыщение сохраняется или (2) поддерживающий ECN поток снижает скорость, а не поддерживающий — не снижает и перегрузка возрастает, пока маршрутизатор не переходит от маркировки пакетов кодом CE к отбрасыванию пакетов. Хотя второй вариант не вполне беспристрастен, поддерживающий ECN поток в этом получает некоторые преимущества, поскольку увеличившееся насыщение заставляет маршрутизатор перейти в режим отбрасывания пакетов.

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

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

18. Зачем использовать два бита в заголовке IP?

Необходимость индикации ECT в заголовке IP понятна, но остается вопрос о возможности использования для кодов ECT (транспорт с поддержкой ECN) и CE (обнаружено насыщение) одного бита в заголовке. Такое однобитовое представление предложено в работе [Floyd94]. Одно значение «ECT, но без CE» будет представлять поддерживающий ECN транспорт, а другое — «CE или без ECT» будет представлять факт насыщения или транспорт без поддержки ECN.

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

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

Еще одним преимуществом двухбитового варианта является повышенная отказоустойчивость. Наиболее критический момент, описанный в разделе 8, заключается в том, что по умолчанию следует указывать не поддерживающий ECN транспорт. В двухбитовом варианте для реализации этого требования достаточно просто устанавливать по умолчанию код not-ECT. В однобитовом варианте для выполнения этого требования следует устанавливать код «CE или ECT». Этот вариант менее понятен и, возможно, более открыт для некорректных реализаций на конечных узлах или маршрутизаторах.

Хотя в целом однобитовая реализация вполне допустима, она имеет ряд существенных недостатков по сравнению с двухбитовым вариантом. Во-первых, функциональность однобитового варианта существенно ограничена в плане трактовки пакетов с кодом CE на втором перегруженном маршрутизаторе. Во-вторых, однобитовый вариант требует передачи дополнительной информации в заголовке транспортного уровня пакетов из поддерживающего ECN потока (функциональность двухбитового варианта просто переносится на транспортный уровень) или понимания со стороны отправителей поддерживающих ECN потоков того, что получатели должны быть способны a-priori определить какие пакеты поддерживают ECN, а какие не поддерживают. В-третьих, однобитовая реализация потенциально более открыта для ошибок со стороны некорректных реализаций, которые могут по умолчанию устанавливать неверное значение бита ECN. Мы полагаем, что перечисленные ограничения обеспечивают достаточные основания использования дополнительного бита в заголовке IP для кодов ECT.

19. Ретроспектива использования октета IPv4 TOS

RFC 791 [RFC791] определяет октет ToS20 в заголовке IP. В RFC 791 биты 6 и 7 октета ToS отмечены, как резервные (Reserved for Future Use), и указано, что они имеют нулевое значение. Первые два поля октета ToS определены в документе, как Precedence (предпочтения) и Type of Service (тип обслуживания — TOS).

           0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |   PRECEDENCE    |       TOS       |  0  |  0  |    RFC 791
        +-----+-----+-----+-----+-----+-----+-----+-----+

RFC 1122 включает биты 6 и 7 в поле ToS, не обсуждая конкретного их использования (см рисунок слева).

          0     1     2     3     4     5     6     7
       +-----+-----+-----+-----+-----+-----+-----+-----+
       |   PRECEDENCE    |       TOS                   |    RFC 1122
       +-----+-----+-----+-----+-----+-----+-----+-----+

Октет ToS заголовка IPv4 был заново определен в RFC 1349 [RFC1349], как показано ниже.

          0     1     2     3     4     5     6     7
       +-----+-----+-----+-----+-----+-----+-----+-----+
       |   PRECEDENCE    |       TOS             | MBZ |    RFC 1349
       +-----+-----+-----+-----+-----+-----+-----+-----+

Бит 6 поля TOS был определен в RFC 1349, как «Minimize Monetary Cost21». В дополнение к полям Precedence и TOS было определено поле MBZ22, которое в настоящее время не используется. В RFC 1349 отмечено, что отправитель дейтаграмм устанавливает в поле MBZ нулевое значение, если не используется экспериментальных протоколов с иной трактовкой этого бита.

RFC 1455 [RFC 1455] определяет экспериментальный стандарт, использующий все четыре бита поля TOS для запроса гарантированного уровня защиты канала.

Документы RFC 1349 и RFC 1455 были отменены RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers23» [DIFFSERV], в котором биты 6 и 7 поля DS были указаны, как неиспользуемые (CU24). Первые шесть битов поля DS трактуются, как коды дифференцированного обслуживания (DSCP25). Формат поля показан на рисунке.

            0     1     2     3     4     5     6     7
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |               DSCP                |    CU     |
         +-----+-----+-----+-----+-----+-----+-----+-----+

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

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

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

K. K. Ramakrishnan

AT&T Labs. Research

Phone: +1 (973) 360-8766

EMail: kkrama@research.att.com

URL: http://www.research.att.com/info/kkrama

Sally Floyd

Lawrence Berkeley National Laboratory

Phone: +1 (510) 486-7518

EMail: floyd@ee.lbl.gov

URL: http://www-nrg.ee.lbl.gov/floyd/


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

1Explicit Congestion Notification — явное уведомление о насыщении.

2Random Early Detection — упреждающее детектирование.

3Congestion Experienced — наблюдается насыщение.

4Ускоренный повтор передачи и быстрое восстановление

5ECN-Capable Transport – поддерживающий ECN транспорт.

6В оригинале “ECN-Capable” — пакеты, для которых может поддерживаться ECN. Прим. перев.

7ECN Capability.

8Congestion Window Reduced — окно насыщения уменьшено.

9В более ранних документах этот флаг назывался ECN Notify.

10ECN-Capable Transport — транспорт, поддерживающий ECN.

11Congestion Experienced — наблюдается насыщение.

12Non-compliant.

13Man-in-the-middle attack — атака с перехватом данных на пути и участием человека. Прим. перев.

14Этот документ признан устаревшим и заменен RFC 4302 и RFC 4305, переводы которых имеются на сайте www.protocols.ru. Прим. перев.

15Перевод этого документа имеется на сайте www.protocols.ru. Прим. перев.

16Этот документ частично обновлен в RFC 3168 и RFC 3260

17Этот документ признан устаревшим и заменен RFC 4303 и RFC 4305, переводы которых имеются на сайте www.protocols.ru. Прим. перев.

18Этот документ обновлен в RFC 1624. Прим. перев.

19Этот документ признан устаревшим и заменен RFC 2474, перевод которого имеется на сайте www.protocols.ru. Прим. перев.

20Type of Service — тип обслуживания.

21Минимизация финансовых расходов.

22Must be zero — должно иметь нулевое значение.

23Определение поля дифференцированного обслуживания (DS) в заголовках IPv4 и IPv6.

24Currently Unused — в настоящее время не используются.

25Differentiated Services CodePoint.




RFC 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations

Network Working Group                                          S. Corson
Request for Comments: 2501                        University of Maryland
Category: Informational                                        J. Macker
                                               Naval Research Laboratory
                                                            January 1999

 

Сети MANET — проблемы протоколов маршрутизации и вопросы развития

Mobile Ad hoc Networking (MANET):

Routing Protocol Performance Issues and Evaluation Considerations

PDF

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

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

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

Тезисы

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

1. Введение

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

В сообществе Internet поддержка маршрутизации для мобильных хостов разрабатывается в рамках технологии mobile IP. Эта технология предназначена для поддержки роуминга (roaming) перемещающихся в пространстве хостов, которые могут разными способами подключаться к сети Internet с возможностью изменения при этом используемого блока адресов. Хост может напрямую подключиться к стационарной сети (чужой), а также использовать для подключения беспроводное соединение, телефонную линию и т. п. Поддержка этих форм мобильности хостов («блуждания») требует управления адресами, расширения интероперабельности протоколов и поддержки функция типа поэтапной (hop-by-hop) маршрутизации на основе имеющихся протоколов маршрутизации, работающих в стационарных сетях. В отличие от этого задачей специализированных мобильных сетей (mobile ad hoc network) является расширение мобильности на область автономных мобильных беспроводных доменов, где множество узлов, способных объединять в себе функции хостов и маршрутизаторов, сами по себе формируют инфраструктуру сетевой маршрутизации.

2. Применение

Термин «специализированная мобильная сеть» (Mobile Ad hoc Networking) в какой-то мере является синонимом термина «мобильные пакетные радиосети» (Mobile Packet Radio Networking), пришедшего из ранних военных исследований 70-80-х годов, термина «мобильные меш-сети» (Mobile Mesh Networking), введенного журналом The Economist для обозначения военных сетей будущего), а также термина «мобильные многоинтервальные беспроводные сети» (Mobile, Multihop, Wireless Networking), который более точен, хотя и выглядит громоздким.

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

Технологии MANET иногда применяются в промышленных и коммерческих приложениях, включающих обмен данными с мобильными устройствами. Кроме того, мобильные меш-сети могут служить недорогой отказоустойчивой альтернативой сетям сотовой связи. Имеются и будут появляться потребности военных в отказоустойчивых, совместимых с IP службах для мобильных беспроводных коммуникационных сетей [1], многие из которых состоят из весьма динамичных автономных топологических сегментов. Кроме того, применение технологий MANET, весьма вероятно в развивающихся системах «переносных» вычислений и коммуникаций. Продуманное объединение со спутниковыми системами передачи данных позволяет создать на базе технологии MANET гибкие коммуникационные системы для служб спасения, пожарных и т. п., обеспечивающие быстро развертываемые, жизнестойкие и эффективные динамические сети. Очевидны и другие применения технологии MANET, которые в настоящее время не реализованы и не видны авторам документа. Попросту говоря, эта технология обеспечивает распространение сетевых технологий IP на динамические, автономные беспроводные сети.

3. Характеристики сетей MANET

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

Узлы MANET оснащаются беспроводными передатчиками и приемниками, использующими антенны, которые могут быть всенаправленными (omnidirectional) для широковещания, направленными для соединений «точка-точка», возможно, управляемыми. Могут применяться и комбинации указанных антенн. В каждый момент в зависимости от местоположения узлов, зон покрытия их приемников и передатчиков, уровня мощности передатчиков и уровня взаимодействия между каналами картина беспроводной связности имеет форму случайного многоплечевого (multihop) или сети ad hoc. Топология такой сети может меняться с течением времени в результате перемещения узлов или изменения их параметров приема и передачи.

Ниже перечислены отличительные характеристики сетей MANET.

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

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

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

  3. Энергетические ограничения. Часть или все узлы сети MANET могут работать от батарей или других источников с ограниченной емкостью. Для таких узлов важную роль играют вопросы экономии энергии.

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

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

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

4. Цели рабочей группы IETF Mobile Ad Hoc Network (manet)

Целью недавно организованной рабочей группы IETF manet является разработка средств одноранговой мобильной маршрутизации (peer-to-peer mobile routing) в полностью мобильных беспроводных доменах. Эти средства будут использоваться вне стационарных сетей, где предполагается обычная маршрутизация IP и на расстояниях более одного интервала (hop) от стационарных сетей.

Ближайшей задачей рабочей группы manet является стандартизация одного или нескольких протоколов внутридоменной индивидуальной маршрутизации (unicast) и связанной с этим технологии сетевого уровня, которая:

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

  • поддерживает традиционный сервис IP без организации явных соединений (connectionless );

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

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

5. Мобильная маршрутизация на уровне IP

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

Иными словами, реальное преимущество использования маршрутизации на уровне IP в MANET заключается в обеспечении согласованности на сетевом уровне для сетей с множеством интервалов пересылки (multihop network), состоящих из узлов, на которых применяется «мешанина» из физических сред (т. е, смесь того, что обычно называют подсетями технологии). Узел MANET включает маршрутизатор, который может быть физически подключен к множеству хостов IP (или устройств с адресами IP) и потенциально имеет «множество» беспроводных интерфейсов, на каждом из которых применяется своя беспроводная технология. Таким образом, узел MANET с интерфейсами, использующими технологии A и B, может взаимодействовать с любым другим узлом MANET, имеющим интерфейс с технологией A или B. Многоинтервальная связность технологии A формирует многоинтервальную топологию физического уровня, а многоинтервальная связность технологии B формирует другую топологию физического уровня (она может отличаться от топологии для A) и объединение этих топологий формирует новую топологию (в терминах теории графов — мультиграф), завершающейся «машиной маршрутизации IP» сети MANET. Узлы MANET, принимающие решения о маршрутизации с использованием этой «машины», могут обмениваться данными с использованием любой или обеих упомянутых топологий физического уровня. По мере разработки новых технологий физического уровня будут создаваться новые драйверы устройств и к «машине маршрутизации IP» могут добавляться другие многоинтервальные топологии физического уровня. Некоторые старые технологии могут выводиться из обращения. Функциональная и архитектурная гибкость, обеспечиваемая маршрутизацией на уровне IP, будет существенно снижать аппаратные издержки при масштабировании.

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

5.1. Взаимодействие со стандартной маршрутизацией IP

На ближайшую перспективу сети MANET сейчас считаются тупиковыми (stub) — это означает что весь трафик через узлы MANET адресован в сеть MANET или исходит из нее. Ограниченная пропускная способность и возможные ограничения по питанию не позволяют рассматривать сети MANET в качестве транзитных (хотя это ограничение может быть снято по мере развития технологий). Данное ограничение существенно снижает число маршрутов, которые требуется анонсировать для взаимодействия со стационарными сетями Internet. Для оконечной сети маршрутное взаимодействие может в ближайшей перспективе обеспечиваться той или иной комбинацией механизмов типа anycast-передач в масштабе сети MANET и mobile IP. В будущем для такого взаимодействия могут послужить и отличные от mobile IP механизмы.

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

6. Проблемы протоколов маршрутизации MANET

Для оценки достоинств протокола маршрутизации нужна метрика — как количественная, так и качественная, — которая позволит измерить устойчивость и производительность. Метрика не должна зависеть от какого-либо конкретного протокола маршрутизации.

Ниже приведен список качественных показателей протколов маршрутизации MANET.

  1. Распределенные возможности. Существенное свойство, которое следует отметить.

  2. Отсутствие петель. Само по себе с учетом некоторых количественных параметров (например, производительности) не требуется, однако весьма желательно для предотвращения таких проблем, как «феномен худшего» (worst-case phenomena), когда, например, небольшая часть пакетов может неограниченно долго перемещаться по сети «кругами». Для решения этой проблемы существуют специальные механизмы (например, TTL), но желательны более структурированные и хорошо сформированные модели, которые обычно обеспечивают более высокую общую производительность.

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

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

  5. Безопасность. Без тех или иных средств защиты на сетевом и канальном уровне протокол маршрутизации MANET уязвим для многих типов атак. Сравнительно просто можно организовать перехват сетевого трафика, повторное использование сообщение, изменение заголовков пакетов и перенаправление маршрутных сообщений в беспроводных сетях без подходящих мер защиты. Хотя упомянутые проблемы возникают и в кабельных сетях, а также самих протоколах маршрутизации, поддержка «физической» защиты среды передачи на практике с сетях MANET оказывается сложнее. Желательно обеспечивать защиту, препятствующую нарушению протокольных операций. Это можно в той или иной мере реализовать для любого протокола маршрутизации с помощью внешних средств (например, методов IP Security).

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

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

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

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

  2. Время нахождения маршрута. Одна из форм «внешнего» измерения сквозной задержки (особенно важная для алгоритмов маршрутизации «по потребности») — время, требуемое для организации маршрута после его запроса.

  3. Доля пакетов с нарушением порядка доставки. Внешняя характеристика производительности маршрутизации без организации явных соединений (connectionless routing) особенно интересная для протоколов транспортного уровня типа TCP, которые предпочитают упорядоченную доставку.

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

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

    • Среднее отношение переданных/доставленных битов данных может служить мерой эффективности доставки данных в сети. Опосредованно это значение также характеризует среднее число этапов пересылки пакетов данных.

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

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

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

  1. Размер сети, определяемый числом узлов.

  2. Связность — среднее число соседей узла сети.

  3. Topological rate of change—the speed with which a network’s topology is changing

  4. Емкость каналов — эффективная скорость канала в бит/с с учетом потерь от множественного доступа, кадрирования, кодирования и т. п.

  5. Влияние односторонних соединений — насколько эффективно протокол работает при наличии односторонних соединений в сети.

  6. Картина трафика — насколько эффективно протокол адаптируется к неоднородностям и всплескам трафика.

  7. Мобильность — влияние долгосрочных и краткосрочных изменений топологии сети на производительность протокола маршрутизации.

  8. Доля «спящих» узлов и продолжительность «сна» — влияние присутствия засыпающих и просыпающихся узлов на работу протокола.

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

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

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

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

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

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

[1] Adamson, B., «Tactical Radio Frequency Communication Requirements for IPng», RFC 1677, August 1994.

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

M. Scott Corson

Institute for Systems Research

University of Maryland

College Park, MD 20742

Phone: (301) 405-6630

EMail: corson@isr.umd.edu

Joseph Macker

Information Technology Division

Naval Research Laboratory

Washington, DC 20375

Phone: (202) 767-2001

EMail: macker@itd.nrl.navy.mil

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

1Mobile Ad hoc Network — мобильная сеть специального назначения.




RFC 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms

Network Working Group                                    M. Allman
Request for Comments: 2488            NASA Lewis/Sterling Software
BCP: 28                                                  D. Glover
Category: Best Current Practice                         NASA Lewis
                                                        L. Sanchez
                                                               BBN
                                                      January 1999

PDF

 

Повышение эффективности работы TCP через спутниковые каналы стандартными средствами

Enhancing TCP Over Satellite Channels using Standard Mechanisms

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

Этот документ относится к категории «Обмен опытом» (Best Current Practices) для сообщества Internet и служит приглашением к дискуссии в целях дальнейшего развития. Документ может распространяться свободно.

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

Тезисы

Протокол TCP1 обеспечивает гарантированную доставку данных по любому пути через сеть, включая пути со спутниковыми сегментами. Для работы TCP через спутниковые каналы имеется несколько стандартизованных IETF механизмов, позволяющих этому протоколу более эффективно использовать доступную полосу пропускания спутниковых каналов. В этом документе рассмотрены некоторые из этих «улучшений» TCP. В данный момент все рассматриваемые здесь механизмы имеют статус проектов стандартов IETF (или соответствуют стандартам IETF).

1. Введение

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

Документ разделен на несколько частей: в разделе 2 приведены краткие характеристики спутниковых сетей, раздел 3 посвящен двум не относящимся к TCP механизмам, которые позволяют протоколу TCP более эффективно использовать доступную полосу каналов, в разделе 4 описаны определенные IETF механизмы TCP, которые могут быть полезны на спутниковых каналах, а в разделе 5 приведены рекомендации для современных реализаций TCP с точки зрения использования спутниковых каналов.

2. Характеристики спутниковых каналов

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

Многие коммуникационные спутники размещаются на геостационарной орбите (GSO2), радиус которой составляет приблизительно 36 000 км [Sta94]. Нахождение спутника на геостационарной орбите обеспечивает его стабильное положение относительно земной поверхности. Т. е., каждая наземная станция всегда «видит» спутник в одной точке небосвода. Время распространения сигнала, определяемое двойным расстоянием до спутника составляет 239,6 мсек (для случая нахождения спутника строго вертикально над земной станцией) [Mar78]. Для наземных станций, находящихся на краях зоны обслуживания спутников расстояние составит 2 x 41 756 км, а задержка — 279,0 мсек [Mar78]. Приведенные значения задержек справедливы для одного «прыжка» (hop) земля-спутник-земля. Минимальное время между отправкой запроса и получением отклика на него (время кругового обхода — RTT3) будет составлять по крайней мере 558 мсек. Значение RTT обусловлено не только задержками на распространение радиосигнала между землей и спутником и находится под влиянием таких факторов, как задержки на передачу через наземные сети, ожидание в очередях шлюзов и т. п. Дополнительная задержка будет возникать в тех случаях, когда между конечными станциями будет более одного спутникового интервала. По мере реализации на спутниках операций по обработке сигналов это тоже может увеличивать задержки.

Спутники могут находиться и на других орбитах, включая LEO4 [Stu95] [Mon98] и MEO5 [Mar78]. Для связи через низкоорбитальные спутники последних требуется целая группировка. Иными словами, когда один спутник выходит из зоны видимости наземной станции, другой уже находится в этой зоне и «подхватывает» станцию. Задержка распространения сигналов для случая LEO составляет от нескольких миллисекунд для спутника, находящегося на одной вертикали с земной станцией, примерно до 80 мсек для спутника, приближающегося к горизонту. Такие системы зачастую используют межспутниковые соединения и задержка будет зависеть от маршрутизации в сети.

Два фундаментальных свойства спутниковых каналов рассмотрены ниже.

Шум — Уровень радиосигнала падает пропорционально квадрату пройденного расстояния. Для спутниковых каналов расстояние велико и сигнал ослабляется достаточно сильно. Это приводит к низкому отношению сигнал/шум. Некоторые частотные диапазоны весьма чувствительным к воздействиям атмосферы (например, затухание из-за дождей). Для мобильных приложений спутниковые каналы особенно чувствительны к возникающим из-за отражений множественным путям, а также к затенению (например, зданиями). Типичная частота битовых ошибок (BER6) для современного спутникового канала составляет не более 10-7 (1 ошибка на 10 миллионов битов). Эффективное кодирование с контролем ошибок (например, Reed Solomon) может быть реализовано на существующих спутниковых каналах и в настоящее время это уже используется во многих случаях. По мере внедрения новых механизмов контроля ошибок вероятность возникновения ошибок в спутниковых каналах становится сравнимой с вероятностью ошибок в оптических кабелях. Однако во многих старых системах значения BER во много раз превышают частоту ошибок в наземных каналах и новых спутниковых каналах.

Полоса пропускания — спектр радиочастот ограничен по своей природе, следовательно полоса спутниковых каналов тоже ограничена и обычно контролируется лицензиями. Дефицит частотного ресурса осложняет расширение полосы для решения других проблем. Для современных коммерческих спутниковых соединений «точка-точка» используется частота 6 ГГц в направлении спутника и 4 ГГц в направлении наземных станций (диапазон C) или 14/12 ГГц (диапазон Ku). Позднее был добавлен диапазон Ka с частотами 30/20 ГГц. Используемые на спутниках радио-повторители называют транспондерами. В диапазоне C полоса 36 МГц обычно обеспечивает передачу одного цветного телевизионного канала или 1200 телефонных каналов. Транспондеры диапазона Ku обычно работают с полосой канала 50 МГц. На одном спутнике может размещаться несколько десятков транспондеров.

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

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

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

Long feedback loop — значительное время отклика

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

Large delay*bandwidth product — большое значение задержка*полоса

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

Transmission errors — ошибки при передаче

Число битовых ошибок (BER) на спутниковых каналах превышает число ошибок в типовых наземных каналах. TCP использует факты отбрасывания пакетов, как сигналы о перегрузке в сети и снижает размер окна в попытке преодолеть насыщение. При отсутствии данных о причине отбрасывания пакетов (перегрузка или повреждение) TCP должен предполагать, что причиной отбрасывания является перегрузка, чтобы избежать коллапса, описанного в [Jac88] [FF98]. Следовательно, отбрасывание поврежденных пакетов вынуждает TCP уменьшать размер окна даже в случае отсутствия реальных перегрузок в сети.

Asymmetric use — асимметрия

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

Variable Round Trip Times — переменное значение RTT

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

Intermittent connectivity — прерывистая связность

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

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

3. Улучшения на нижних уровнях

При использовании спутниковых каналов в сетях рекомендуется использовать два не связанных с TCP, которые могут повысить производительность TCP. Эти механизмы — Path MTU Discovery и FEC8 — описаны в двух следующих параграфах.

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

3.1 Определение Path MTU

Механизм Path MTU Discovery [MD90] служит для определения максимального размера пакетов, который соединение может использовать на данном пути через сеть без фрагментации IP. Отправитель передает пакет подходящего для локальной сети, к которой он подключен, размера (например, 1500 байтов для Ethernet) с установленном в заголовке флагом IP DF9. Если пакет слишком велик для пересылки по сетевому пути без фрагментирования, шлюз который должен был фрагментировать пакет и переслать фрагменты дальше, вместо этого будет возвращать сообщение ICMP отправителю пакета. Это сообщение будет показывать невозможность передачи исходного пакета без фрагментирования и указывать максимальный размер пакета, который шлюз может переслать. Дополнительная информация IESG в части определения Path MTU приведена в [Kno93].

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

Однако результатом применения Path MTU Discovery может быть задержка перед тем, как TCP сможет начать передачу данных. Предположим, например, что передается пакет с установленным флагом DF и один из промежуточных шлюзов (G1) возвращает сообщение ICMP указывающее невозможность передачи без фрагментирования. После этого хост снижает размер пакетов до значения, указанного в сообщении ICMP от шлюза G1 и передает новый пакет с флагом DF. Это пакет будет переслан шлюзом G1, однако это не дает гарантий того, что все последующие шлюзы смогут передать этот сегмент без фрагментирования. Если другой шлюз (G2) не может переслать сегмент, он будет возвращать отправителю сообщение ICMP и процесс повторится. Следовательно определение MTU для пути может потребовать достаточно большого времени. Задержки на спутниковых каналах будут усугублять проблему (например, спутниковый канал между G1 и G2). Однако на практике Path MTU Discovery не занимает чрезмерного времени, поскольку значения MTU достаточно «стандартны». Кроме того, кэширование значений MTU во многих случаях позволяет смягчить проблему, хотя реализация такого кэширования и время хранения записей в кэше требуют дополнительного изучения.

Связь между значением BER и размером сегментов существенно зависит от характеристик конкретного канала. Эти связи требуют дальнейших исследований, однако при использовании упреждающей коррекции ошибок (параграф 3.2) увеличение размера сегментов будет повышать производительность как и в других сетях [MSMO97]. Хотя точный метод выбора лучшего значения MTU для спутниковых каналов выходит за рамки этого документа, рекомендуется применять Path MTU Discovery, чтобы протокол TCP мог использовать максимально возможное значение MTU на спутниковом канале.

3.2 Упреждающая коррекция ошибок

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

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

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

Требуются дальнейшие исследования в части механизмов, позволяющих протоколу TCP различать потери в результате перегрузок и повреждения пакетов. Такие механизмы позволят TCP отвечать подобающим способом на перегрузку и пытаться исправить поврежденные пакеты без снижения скорости передачи. Однако в отсутствие таких механизмов потеря пакета должна для предотвращения нестабильности в сети восприниматься, как индикация перегрузки. Некорректная интерпретация потери, как результата повреждения пакета, без снижения скорости передачи может привести к коллаптической перегрузке [Jac88] [FF98].

4. Стандартные механизмы TCP

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

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

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

Отправители TCP используют две переменных состояния в целях контроля перегрузок. Первой переменной является окно насыщения cwnd10. Это значение определяет верхнюю границу объема данных, которые отправитель может передать в сеть до того, как получит подтверждение (ACK). Значение cwnd ограничено размером анонсируемого получателем окна. Размер окна насыщения может меняться в процессе передачи на основе заключений об уровне перегрузки в сети. Второй переменной является порог замедленного старта ssthresh11. Эта переменная определяет алгоритм, используемый для управления значением cwnd. Если cwnd < ssthresh, используется алгоритм замедленного старта (slow start) для увеличения cwnd. Однако при cwnd ssthresh (или просто > для некоторых реализаций TCP), применяется алгоритм предотвращения перегрузки. Начальное значение ssthresh совпадает с анонсируемым получателем размером окна. Кроме того, значение ssthresh устанавливается при обнаружении перегрузки.

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

4.1.1 Замедленный старт и предотвращение перегрузок

Начиная передачу через соединение TCP, хост не знает состояния сети между собой и получателем данных. Для предотвращения отправки неприемлемо большого объема данных отправителю нужно в начале передачи использовать алгоритм замедленного старта [Jac88] [Bra89] [Ste97]. Процедура начинается с инициализации cwnd = 1 (хотя экспериментальный механизм IETF будет увеличивать размер начального окна приблизительно до 4 Кбайт [AFP98]) и установки для ssthresh размера анонсируемого получателем окна. Это заставляет TCP передать один сегмент и ждать соответствующего подтверждения ACK. Для каждого ACK, полученного во время процедуры замедленного старта, значение cwnd увеличивается на 1 сегмент. Например, после первого принятого ACK будет установлено cwnd = 2, что позволяет отправителю передать 2 пакета данных. Процедура повторяется до тех пор, пока cwnd достигнет или превзойдет ssthresh (или, в некоторых реализациях, cwnd = ssthresh) или не возникнет потеря.

Когда значение cwnd достигает или превышает (или равно для некоторых реализаций) ssthresh, используется алгоритм предотвращения перегрузок для увеличения [Jac88] [Bra89] [Ste97]. Это алгоритм обеспечивает более медленное увеличение размера окна по сравнению с процедурой замедленного старта. Предотвращение перегрузок используется для медленного зондирования пропускной способности сети. В процессе congestion avoidance размер cwnd увеличивается на 1/cwnd по каждому принятому подтверждению ACK. Следовательно, если приходит одно подтверждение для каждого сегмента данных, cwnd будет увеличиваться примерно на 1 сегмент за период кругового обхода (RTT).

Алгоритмы замедленного старта и предотвращения перегрузок могут снижать эффективную пропускную способности канала при работы в спутниковых сетях с большими задержками [All97]. Например, передача начинается с окна размером 1 сегмент. После его передачи отправитель должен ждать приема соответствующего пакета ACK. На спутниковых каналах GSO время ожидания составит приблизительно 500 мсек и в течение этого времени соединение будет простаивать. Процедура замедленного старта на спутниковых каналах GSO будет длиться значительно дольше, чем на типичных наземных каналах. Это задержит начало использования алгоритма предотвращения перегрузок [All97]. По этой причине так важно использование механизмов Path MTU Discovery. Хотя число сегментов все равно будет определяться алгоритмами контроля насыщения, размеры сегмента зависят от MTU.

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

4.1.2 Ускоренный повтор и быстрое восстановление

По умолчанию TCP использует для детектирования отброшенных сегментов тайм-аут [Pos81]. Иными словами, если отправитель не получит ACK для данного пакета за ожидаемый интервал времени, передача сегмента повторяется. Тайм-аут повторной передачи (RTO12) определяется на основе наблюдений за RTT. В дополнение к повтору передачи по истечении RTO протокол TCP использует факт потери сегмента в качестве индикации насыщения в сети. В ответ на перегрузку значение ssthresh устанавливается равным половине cwnd, а затем значение cwnd уменьшается до 1 сегмента. Это инициирует подключение алгоритма замедленного старта для увеличения cwnd, пока оно не достигнет половины значения cwnd на момент обнаружения перегрузки. После фазы замедленного старта используется алгоритм предотвращения перегрузок для проверки наличия дополнительной пропускной способности в сети.

Пакеты TCP ACK всегда повторяют пакет со старшим номером из числа доставленных с сохранением порядка. Следовательно, ACK для сегмента X также является подтверждением для всех сегментов с номерами меньше X. Более того, при доставке сегмента с нарушением порядка пакет ACK все равно будет подтверждать старший номер доставленных упорядоченно сегментов, а не прибывший сегмент. Например, предположим, что сегмент 11 был отброшен в сети, а сегмент 12 принят получателем. Получатель в этом случае передаст дубликат ACK, подтверждающий доставку сегмента 10 (и всех предшествующих).

Алгоритм ускоренного повтора использует такие дубликаты ACK для детектирования потери сегментов. Если отправитель данных получил 3 дубликата ACK, TCP предполагает потерю сегмента и повторяет передачу отсутствующего сегмента, не ожидая тайм-аута RTO. После отправки сегмента с использованием ускоренного повтора используется алгоритм быстрого восстановления для настройки окна насыщения. Сначала устанавливается значение ssthresh, равное половине cwnd. Затем значение cwnd уменьшается наполовину. В заключение cwnd дополнительно увеличивается на 1 для каждого полученного дубликата ACK. Такое увеличение обусловлено тем, что каждый дубликат ACK представляет уже покинувший сеть сегмент. Если cwnd позволяет, TCP может передать новые данные. Такой подход позволяет TCP сохранять поток данных на уровне половины скорости, при которой была обнаружена потеря пакетов. При получении ACK для переданных повторно пакетов значение cwnd снижается обратно до ssthresh (половина значения cwnd в момент обнаружения перегрузки).

В общем случае при ускоренном повторе может быть повторен только один сегмент на окно переданных данных. При потере множества сегментов из одного окна один из них будет передан заново с использованием ускоренного повтора, а для остальных потерянных сегментов придется, как обычно, ждать тайм-аута RTO, по которому TCP инициирует процедуру slow start.

Отклик TCP на перегрузку зависит от способа ее обнаружения. Если повторная передача пакета была вызвана таймером повтора, TCP сбрасывает значение ssthresh до половины текущего значения cwnd и снижает значение cwnd до 1 сегмента (инициируя, таким образом, замедленный старт). Однако, если повтор передачи был вызван механизмом fast retransmit для обоих параметров ssthresh и cwnd значения уменьшаются до половины текущего значения cwnd и для отправки новых данных используется механизм предотвращения перегрузок. Различие заключается в том, что при повторе, вызванном дубликатами ACK, TCP знает, что пакеты продолжают находиться в сети и можно считать, что перегрузка не велика. Однако при повторе передачи по таймеру повтора TCP ничего не знает о состоянии сети и, следовательно, должен быть консервативным при передаче новых данных, используя механизм замедленного старта.

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

Лучшим способом повысить эффективность механизмов ускоренного повтора и восстановления является детектирование потерь на основе механизма селективных подтверждений. Как описано ниже, такие механизмы обычно способны обеспечить быстрое восстановление при потере множества сегментов без необходимости снижения cwnd. В отсутствие SACK следует применять алгоритмы ускоренного повтора и восстановления. Корректировка этих алгоритмов для достижения высокой производительности в случае множественных ускоренных повторов выходит за рамки данного документа. По этой причине разработчикам TCP следует реализовать текущие варианты алгоритмов ускоренного повтора и быстрого восстановления, описанных в RFC 2001 [Ste97] или последующих вариантах RFC 2001.

4.1.3 Контроль насыщения в спутниковой среде

Упомянутые выше алгоритмы оказывают негативное влияние на производительность отдельных соединений TCP, поскольку алгоритмы достаточно зондируют сеть на предмет дополнительных «мощностей», потребляя для этого некоторую часть доступной пропускной способности. Это, в частности, правильно для спутниковых каналов со значительными задержками, поскольку на получение отправителем отклика от получателя уходит много времени [All97] [AHKO97]. Однако эти алгоритмы необходимы для предотвращения коллапса насыщения в сети с совместным доступом [Jac88]. Следовательно, негативное влияние на отдельные соединения приходится принимать ради преимуществ сети в целом.

4.2 Большое окно TCP

Стандартное значение максимального размера окна TCP (65 535 байтов) не позволяет одному соединению TCP полностью воспользоваться доступной полосой на некоторых спутниковых каналах. Пропускная способность соединения TCP определяется формулой [Pos81]:

throughput = window size / RTT

Следовательно, при максимальном размере окна 65 535 байтов и работе через геостационарный спутник с RTT = 560 мсек [Kru95] максимальная пропускная способность составит

throughput = 65535 / 560 = 117027 байт/сек.

Следовательно, одно стандартное соединение TCP не сможет полностью воспользоваться, например, каналом T1 (скорость около 192000 байт/сек.) при работе через спутник GSO. Однако протокол TCP был расширен с целью поддержки больших размеров окон [JBB92]. Описанное в [JBB92] масштабирование окна следует применять в спутниковых средах вместе с алгоритмами PAWS13 и RTTM14.

Следует отметить, что при использовании одного спутникового канала для множества соединений увеличение размера окна не является обязательным. Например, два долгосрочных соединения TCP с окнами размером 65535 байтов могут полностью использовать канал T1 через спутник GSO.

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

4.3 Стратегия подтверждений

Есть два стандартных метода генерации подтверждений получателями TCP. В методе [Pos81] генерируется пакет ACK для каждого входящего сегмента. В работе [Bra89] утверждается, что хостам следует использовать отложенные подтверждения. При использовании этого алгоритма пакеты ACK генерируются для каждого второго полноразмерного сегмента или, если второй полноразмерный сегмент не приходит в течение заданного времени (обычно не более 500 мсек.). Окно насыщения увеличивается в соответствии с номерами входящих пакетов ACK и отложенная отправка подтверждений снижает число пакетов ACK, отправленных получателем. Следовательно, рост параметра cwnd замедляется при использовании отложенных подтверждений по сравнению со случаем генерации ACK на каждый принятый сегмент [All98].

Заманчивым «решением» проблемы, вызываемой отложенными подтверждениями, кажется отключение данного механизма и передача ACK для каждого входящего сегмента. Однако делать это не рекомендуется. Во-первых, в документе [Bra89] указано, что получателям TCP следует использовать отложенные подтверждения. Во-вторых, двойное увеличение числа пакетов ACK в разделяемой сети может привести к неочевидным последствиям. Следовательно, запрет использования отложенных подтверждений требует дополнительного изучения и в настоящее время получателям TCP следует продолжать генерацию пакетов ACK в соответствии с [Bra89].

4.4 Селективные подтверждения

Селективные подтверждения (SACK15) [MMFR96] позволяют получателям TCP сообщать отправителям точную информацию о доставленных пакетах. SACK позволяют TCP быстрее восстанавливаться после потери сегментов, а также предотвращают ненужные повторы передачи.

Алгоритм ускоренного повтора обычно позволяет исправить лишь одну потерю на окно данных. При возникновении множества потерь отправитель обычно должен использовать тайм-аут для определения сегмента, который нужно повторно передать следующим. В процессе ожидания тайм-аута сегменты данных и подтверждения для них уходят из сети. При отсутствии входящих пакетов ACK для инициирования отправки в сеть новых сегментов отправитель должен использовать для повтора передачи алгоритм замедленного старта. Как отмечено выше, применение этого алгоритма на спутниковых каналах может быть связано со значительными временными издержками. При использовании SACK отправитель обычно может определить какие сегменты следует передать повторно за первый период RTT после обнаружения потери. Это позволяет отправителю продолжать передачу сегментов (отправлять новые сегменты, если это приемлемо) с подходящей скоростью и, следовательно, поддерживать синхронизацию ACK. Это позволяет избавиться от длительной процедуры замедленного старта при потере множества сегментов. Обычно применение SACK позволяет повторить передачу всех потерянных сегментов в течение первого периода RTT после обнаружения потери. В работах [MM96] и [FF96] рассмотрены специфические механизмы контроля насыщения, использующие информацию SACK для определения необходимости повторной передачи и подходящего для повтора времени. В обоих этих алгоритмах используются базовые принципы контроля насыщения, описанные в [Jac88] и при обнаружении перегрузки окно уменьшается наполовину.

5. Обзор улучшений

В таблице 1 перечислены рассмотренные в этом документе механизмы. Некоторые механизмы имеют статус Recommended в процессе стандартизации IETF и рекомендуются авторами для использования в сетях со спутниковыми каналами. Часть механизмов обязательна для применения (статус Required в процессе стандартизации IETF) и они должны использоваться на хостах с доступом в Internet [Bra89]. В таблице указаны разделы документа, посвященные каждому механизму и места использования — символ S указывает механизмы, используемые на стороне отправителя, R — на стороне получателя и L — на спутниковых каналах.

Таблица 1

Механизм

Применение

Описание

Место

Path-MTU Discovery

Рекомендуется

3.1

S

FEC

Рекомендуется

3.2

L

TCP Congestion Control

Slow Start

Обязательно

4.1.1

S

Congestion Avoidance

Обязательно

4.1.1

S

Fast Retransmit

Рекомендуется

4.1.2

S

Fast Recovery

Рекомендуется

4.1.2

S

TCP Large Windows

Window Scaling

Рекомендуется

4.2

S, R

PAWS

Рекомендуется

4.2

S, R

RTTM

Рекомендуется

4.2

S, R

TCP SACK

Рекомендуется

4.4

S, R

Пользователям спутниковых каналов следует выяснить у разработчиков (производителей), поддерживают ли их реализации TCP рекомендованные здесь механизмы. Pittsburgh Supercomputer Center отслеживает функциональность реализаций TCP и поддерживаемых ими расширений, а также публикует рекомендации по настройке различных реализаций TCP [PSC].

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

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

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

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

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

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

При подготовке этого документа важную роль сыграли комментарии членов рабочей группы TCP Over Satellite. В частности, авторы благодарят Aaron Falk, Matthew Halsey, Hans Kruse, Matt Mathis, Greg Nakanishi, Vern Paxson, Jeff Semke, Bill Sepmeier и Eric Travis за их полезные замечания к данному документу.

Литература

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

[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann. TCP Performance Over Satellite Links. In Proceedings of the 5th International Conference on Telecommunication Systems, March 1997.

[All97] Mark Allman. Improving TCP Performance Over Satellite Channels. Master’s thesis, Ohio University, June 1997.

[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.

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

[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996.

[FF98] Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking.

[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical report, October 1994. ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.

[GJKFV98] Rohit Goyal, Raj Jain, Shiv Kalyanaraman, Sonia Fahmy, Bobby Vandalore, Improving the Performance of TCP over the ATM-UBR service, 1998. Sumbitted to Computer Communications.

[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical Report, LBL, April 1990.

[JBB92] Jacobson, V., Braden, R. and D. Borman, «TCP Extensions for High Performance», RFC 1323, May 1992.

[Jac88] Van Jacobson. Congestion Avoidance and Control. In ACM SIGCOMM, 1988.

[Kno93] Knowles, S., «IESG Advice from Experience with Path MTU Discovery», RFC 1435, March 1993.

[Mar78] James Martin. Communications Satellite Systems. Prentice Hall, 1978.

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

[MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment: Refining TCP Congestion Control. In ACM SIGCOMM, 1996.

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

[Mon98] M. J. Montpetit. TELEDESIC: Enabling The Global Community Interaccess. In Proc. of the International Wireless Symposium, May 1998.

[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, «The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm», Computer Communication Review, volume 27, number3, July 1997. available from http://www.psc.edu/networking/papers/papers.html.

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

[PS97] Craig Partridge and Tim Shepard. TCP Performance Over Satellite Links. IEEE Network, 11(5), September/October 1997.

[PSC] Jamshid Mahdavi. Enabling High Performance Data Transfers on Hosts. http://www.psc.edu/networking/perf_tune.html.

[SMM98] Jeff Semke, Jamshid Mahdavi and Matt Mathis. Automatic TCP Buffer Tuning. In ACM SIGCOMM, August 1998. To appear.

[Sta94] William Stallings. Data and Computer Communications. MacMillian, 4th edition, 1994.

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

[Stu95] M. A. Sturza. Architecture of the TELEDESIC Satellite System. In Proceedings of the International Mobile Satellite Conference, 1995.

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

Mark Allman

NASA Lewis Research Center/Sterling Software

21000 Brookpark Rd. MS 54-2

Cleveland, OH 44135

Phone: +1 216 433 6586

EMail: mallman@lerc.nasa.gov

http://roland.lerc.nasa.gov/~mallman

Daniel R. Glover

NASA Lewis Research Center

21000 Brookpark Rd.

Cleveland, OH 44135

Phone: +1 216 433 2847

EMail: Daniel.R.Glover@lerc.nasa.gov

Luis A. Sanchez

BBN Technologies

GTE Internetworking

10 Moulton Street

Cambridge, MA 02140

USA

Phone: +1 617 873 3351

EMail: lsanchez@ir.bbn.com

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

1Transmission Control Protocol — протокол управления передачей.

2Geostationary Orbit.

3Round-trip time.

4Low Earth Orbit — околоземная орбита.

5Medium Earth Orbit — средневысотная орбита.

6Bit error rate.

7Delay*bandwidth product.

8Forward error correction — упреждающая корректировка ошибок.

9Don’t fragment — не фрагментировать.

10Congestion window.

11Slow start threshold.

12Retransmission timeout.

13Protection Against Wrapped Sequence space — защита от перехода через границу отсчета порядковых номеров.

14Round-Trip Time Measurements — измерение времени кругового обхода.

15Selective acknowledgment.

16Этот документ признан устаревшим и заменен RFC 3390.