Network Working Group                                   D. Eastlake, 3rd
Request for Comments: 3174                                      Motorola
Category: Informational                                         P. Jones
                                                           Cisco Systems
                                                          September 2001

US Secure Hash Algorithm 1 (SHA1)

Алгоритм хеширования SHA1 (США)

PDF

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

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

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

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

Аннотация

Этот документ стремится сделать алгоритм хэширования SHA-1 (Secure Hash Algorithm 1) удобным для сообщества Internet. В США описанный здесь алгоритм SHA-1 принят как федеральный стандарт обработки информации (Federal Information Processing Standard) и большая часть приведённого ниже текста заимствована из документа FIPS 180-1. «Оригинальным» является лишь код на языке C.

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

Большая часть текста документа заимствована из [FIPS 180-1]. Реализация кода C является «оригинальной», но стиль похож на опубликованные ранее в RFC для MD4 и MD5 [RFC 1320, RFC 1321].

Алгоритм SHA-1 основан на принципах, похожих на использованные профессором Ronald L. Rivest из MIT при создании алгоритма цифровых дайджестов MD4 [MD4] и промоделированные в [RFC 1320].

Спасибо Tony Hansen, Garrett Wollman за полезные комментарии.

1. Содержимое документа

Примечание. Приведённый ниже текст в основном заимствован из [FIPS 180-1] и заявления о безопасности SHA-1 сделаны правительством США, автором [FIPS 180-1], а не авторами этого документа.

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

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

В разделе 2 определены термины и функции, применяемые в SHA-1.

2. Определения битовых строк и целых чисел

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

1. Шестнадцатеричной (hex) цифрой считается элемент из множества {0, 1, … , 9, A, … , F}. Такие цифры представляются 4 битами. Например, 7 = 0111, A = 1010.

2. Словом (word) является 32-битовая строка, которую можно представить последовательностью из 8 шестнадцатеричных цифр. Для преобразования word в 8 hex-цифр каждая 4-битовая строка преобразуется в символьный элемент из п. a. Например,

   1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23.

3. Целые числа из диапазона от 0 до 2³² — 1 (включительно) можно представить как word. Младшие 4 бита числа представляет самая правая hex-цифра в представлении word. Например, целое число 291 = 2⁸+2⁵+2¹+2⁰ = 256+32+2+1 представляется шестнадцатеричным словом 00000123.

   Если z — целое число из диапазона 0 — 2⁶⁴, то z = (2³²)x + y, где 0 <= x < 2³² и 0 <= y < 2³². Поскольку x и y можно представить как слова X и Y, соответственно, z можно представить парой (X,Y).

4. block — строка из 512 битов. Блок (например, B) можно представить последовательностью из 16 word.

3. Операции со словами

Ниже указаны логические операции, применяемые к словам (word).

1. Побитовые логические операции для word.

   X AND Y = побитовая логическая операция И (AND) для X и Y.

   X OR Y = побитовая логическая операция ИЛИ (OR) для X и Y.

   X XOR Y = побитовая логическая операция Исключительное-ИЛИ (XOR) для X и Y.

   NOT X = побитовое логическое «дополнение» X.

   Пример

                  01101100101110011101001001111011
            XOR   01100101110000010110100110110111
                  --------------------------------
              =   00001001011110001011101111001100

2. Операция X + Y определяется следующим образом: слова X и Y представляют целые числа x и y из диапазона от 0 до 2³² — 1 (включительно). Пусть для положительных чисел n и значение n mod m является остатком от деления n на m. Тогда

   z  =  (x + y) mod 2^32.

   При этом 0 <= z < 2³². Значение z преобразуется в word (Z) и определяется Z = X + Y.

3. Операция циклического сдвига влево S^n(X), где X — слово, а n — целое число от 0 до 31, определяется выражением

   S^n(X)  =  (X << n) OR (X >> 32-n).

   В приведённом примере X << n выполняется следующим образом: отбрасываются n битов X слева, оставшиеся биты переносятся на n позиций влево, а справа добавляется n нулей (результат остаётся 32-битовым). X >> n выполняется путём отбрасывания n справа, переноса оставшихся битов X на n позиций вправо и заполнение нулями n битов слева. Таким образом, Sn(X) эквивалентно циклическому сдвигу X на n позиций влево.

4. Дополнение сообщений

SHA-1 применяется для расчёта дайджеста сообщения или файла данных, переданного на вход алгоритма. Сообщение или файл данных следует рассматривать как строку. Размер сообщения определяется числом битов в нем (пустое сообщение имеет размер 0). Если число битов сообщения кратно 8, для компактности сообщение можно представить шестнадцатеричными цифрами. Чтобы сделать размер сообщения кратный 512 битам, применяется заполнение. При расчёте дайджеста SHA-1 последовательно обрабатывает 512-битовые блоки. Процесс заполнения описан ниже. В итоге в конце сообщения помещается «1», затем m нулей и 64-битовое целое число (размер исходного сообщения), чтобы размер сообщения составлял 512 * n. Дополненное сообщение обрабатывается SHA-1 как цепочка из n блоков по 512 битов.

Предположим, что сообщение имеет размер l < 2⁶⁴. До передачи в SHA-1, сообщение дополняется, как показано ниже.

1. В конец добавляется 1. Например, исходное сообщение 01010000 станет 010100001.

2. В конец добавляются нули (0), число которых зависит от размера исходного сообщения. Последние 64 бита последнего 512-битового блока резервируются для размера исходного сообщения. Предположим, что исходное сообщение имеет вид

   01100001 01100010 01100011 01100100 01100101.

   После п. a) оно приобретёт форму

   01100001 01100010 01100011 01100100 01100101 1

   Так как l = 40, число битов в приведённой выше строке составит 41 и в конце сообщения будет добавлено 407 нулей, после чего сообщение достигнет размера 448 битов и примет вид (в шестнадцатеричной форме)

   61626364 65800000 00000000 00000000
   00000000 00000000 00000000 00000000
   00000000 00000000 00000000 00000000
   00000000 00000000

3. Создаётся 64-битовое (два word) представление l — числа битов в исходном сообщении. Если l < 2³², первое слово заполняется нулями. Оба полученных слова добавляются в конец сообщения.

   Например, для сообщения из b) размер l = 40 (до заполнения). 64-битовое представление числа 40 имеет вид 00000000 00000028 и окончательный блок (сообщение) становится

   61626364 65800000 00000000 00000000
   00000000 00000000 00000000 00000000
   00000000 00000000 00000000 00000000
   00000000 00000000 00000000 00000028

   Дополненное сообщение содержит 16 * n слов, где n > 0. Дополненное сообщение рассматривается как последовательность из n блоков M(1) , M(2).

5. Функции и константы

В SHA-1 применяется последовательность логических функций f(0), f(1),…, f(79). Каждая функция f(t) (0 <= t <= 79) работает с тремя 32-битовыми словами (B, C, D) и даёт на выход 32-битовое слово (word). Функция f(t;B,C,D) для B, C, D определена ниже.

      f(t;B,C,D) = (B AND C) OR ((NOT B) AND D)         ( 0 <= t <= 19)
      f(t;B,C,D) = B XOR C XOR D                        (20 <= t <= 39)
      f(t;B,C,D) = (B AND C) OR (B AND D) OR (C AND D)  (40 <= t <= 59)
      f(t;B,C,D) = B XOR C XOR D                        (60 <= t <= 79).

В SHA-1 применяется последовательность констант (word) K(0), K(1), … , K(79), показанных ниже.

      K(t) = 5A827999         ( 0 <= t <= 19)
      K(t) = 6ED9EBA1         (20 <= t <= 39)
      K(t) = 8F1BBCDC         (40 <= t <= 59)
      K(t) = CA62C1D6         (60 <= t <= 79)

6. Расчёт дайджеста сообщения

Методы, описанные в параграфах 6.1 и 6.2, дают одинаковый результат. Метод 2 позволяет сэкономить 64 32-битовых слова памяти, но это увеличивает время расчёта в результате роста сложности вычисления адресов для { W[t] } в c). Имеются иные методы расчёта с такими же результатами.

6.1. Метод 1

Дайджест сообщения рассчитывается с использованием дополнения, описанного в разделе 4. расчёт описывается с использованием двух буферов, каждый из которых включает пять 32-битовых слов, и последовательности из 80 32-битовых слов. Слова первого буфера обозначены A, B, C, D, E, второго — H0, H1, H2, H3, H4, слова 80-словной последовательности — W(0), W(1),…, W(79). Используется также буфер TEMP типа word.

Для генерации дайджеста блоки по 16 слов M(1), M(2),…, M(n), определённые в разделе 4, обрабатываются по порядку. Обработка каждого M(i) включает 80 шагов. Перед обработкой блоков переменные H инициализируются, как показано ниже.

      H0 = 67452301
      H1 = EFCDAB89
      H2 = 98BADCFE
      H3 = 10325476
      H4 = C3D2E1F0.

Затем обрабатываются блоки M(1), M(2), … , M(n). Обработка блока M(i) описана ниже.

1. M(i) делится на 16 слов (word) W(0), W(1), … , W(15), где W(0) является первым слева.

2. Для t от 16 до 79 (включительно)

   W(t) = S^1(W(t-3) XOR W(t-8) XOR W(t-14) XOR W(t-16))

3. Пусть A = H0, B = H1, C = H2, D = H3, E = H4.

4. Для t от 0 до 79 (включительно)

   TEMP = S^5(A) + f(t;B,C,D) + E + W(t) + K(t);
   E = D;  D = C;  C = S^30(B);  B = A; A = TEMP;

5. Принимается H0 = H0 + A, H1 = H1 + B, H2 = H2 + C, H3 = H3 + D, H4 = H4 + E.

После обработки M(n) дайджест сообщения будет представлять 160-битовую строку из 5 слов (word)

         H0 H1 H2 H3 H4.

6.2. Метод 2

Описанный выше метод предполагает, что последовательность W(0), … , W(79) реализована как массив из восьмидесяти 32-битовых слов. Это эффективно с точки зрения времени выполнения, поскольку адреса W(t-3), … ,W(t-16) на этапе b) рассчитываются легко. Если важнее экономия памяти, можно рассматривать { W(t) } как циклическую очередь, которую можно реализовать в виде массива из 16 32-битовых слов W[0], … W[15]. Пусть MASK = 0000000F. Тогда обработка M(i) будет иметь представленный ниже вид

1. M(i) делится на 16 слов W[0], … , W[15], где W(0) является первым слева.

2. Пусть A = H0, B = H1, C = H2, D = H3, E = H4.

3. Для t от 0 до 79 (включительно)

   s = t AND MASK;
   if (t >= 16) W[s] = S^1(W[(s + 13) AND MASK] XOR W[(s + 8) AND
   MASK] XOR W[(s + 2) AND MASK] XOR W[s]);
   TEMP = S^5(A) + f(t;B,C,D) + E + W[s] + K(t);
   E = D; D = C; C = S^30(B); B = A; A = TEMP;

4. Принимается H0 = H0 + A, H1 = H1 + B, H2 = H2 + C, H3 = H3 + D, H4 = H4 + E.

7. Код C

Ниже приведена демонстрационная реализация SHA-1 на языке C. В параграфе 7.1 содержится заголовочный файл, в 7.2 — код C, а в 7.3 — тестовый драйвер.

7.1. Файл .h

/*
 *  sha1.h
 *
 *  Описание
 *      Это файл заголовков для кода, реализующего алгоритм SHA-1,
 *      определённый в FIPS PUB 180-1, опубликованном 17 апреля 1995 г.
 *
 *      Многие из имён переменных в этом коде заимствованы из 
 *      публикации алгоритма.
 *
 *      Дополнительные сведения приведены в файле sha1.c.
 *
 */

#ifndef _SHA1_H_
#define _SHA1_H_

#include <stdint.h>
/*
 * если вы не используете стандартный файл ISO stdint.h, нужно задать
 * приведённые ниже определения.
 *    имя              назначение
 *  uint32_t         32-битовое целое число без знака
 *  uint8_t          8-битовое целое число без знака (т. е. unsigned char)
 *  int_least16_t    целое число размером 16 битов или больше
 *
 */

#ifndef _SHA_enum_
#define _SHA_enum_
enum
{
    shaSuccess = 0,
    shaNull,            /* параметр Null-указателя */
    shaInputTooLong,    /* слишком много входных данных */
    shaStateError       /* Вызывать Input после Result */
};
#endif
#define SHA1HashSize 20

/*
 *  В этой структуре хранятся контекстные данные для операции 
 *  хэширования SHA-1.
 */
typedef struct SHA1Context
{
    uint32_t Intermediate_Hash[SHA1HashSize/4]; /* дайджест сообщения */

    uint32_t Length_Low;            /* Размер сообщения в битах */
    uint32_t Length_High;           /* Размер сообщения в битах */

                               
    int_least16_t Message_Block_Index; /* Индекса массива блоков */
    uint8_t Message_Block[64];      /* 512-битовые блоки сообщения */

    int Computed;               /* Дайджест рассчитан? */
    int Corrupted;              /* Дайджест повреждён? */
} SHA1Context;

/*
 *  Прототипы функций
 */

int SHA1Reset(  SHA1Context *);
int SHA1Input(  SHA1Context *,
                const uint8_t *,
                unsigned int);
int SHA1Result( SHA1Context *,
                uint8_t Message_Digest[SHA1HashSize]);

#endif

7.2. Файл .c

/*
 *  sha1.c
 *
 *  Описание
 *      Этот файл реализует SHA-1, определённый в 
 *      FIPS PUB 180-1, опубликованном 17 апреля 1995 г.
 *
 *      SHA-1 создаёт 160-битовый дайджест для представленного
 *      потока данных. Требуется около 2**n шагов чтобы найти
 *      сообщение с таким же дайджестом как у данного сообщения
 *      и около 2**(n/2) на нахождения двух сообщений с одинаковым
 *      дайджестом, где n - размер дайджеста в битах. Поэтому 
 *      алгоритм можно применять для создания отпечатка сообщений
 *      (fingerprint).
 *
 *  Проблемы переносимости
 *      SHA-1 определён в терминах 32-битовых слов (word). Этот код
 *      использует файл <stdint.h> (включён из sha1.h) для определения
 *      32- и 8-битовых целых чисел без знака. Если компилятор C не
 *      поддерживает 32-битовые целые числа без знака, этот код не
 *      подойдёт.
 *
 *  Предостережения
 *      SHA-1 разработан для сообщений размером меньше 2^64 битов.
 *      Хотя SHA-1 позволяет создавать дайджесты для сообщений с
 *      любым числом битов меньше 2^64, данная реализация работает
 *      лишь с сообщениями, размер которых кратен 8 битам.
 *
 */

#include "sha1.h"

/*
 *  Определение макроса циклического сдвига влево.
 */
#define SHA1CircularShift(bits,word) \
                (((word) << (bits)) | ((word) >> (32-(bits))))

/* Локальные прототипы функций */
void SHA1PadMessage(SHA1Context *);
void SHA1ProcessMessageBlock(SHA1Context *);

/*
 *  SHA1Reset
 *
 *  Описание
 *      Эта функция инициализирует SHA1Context при подготовке к
 *      расчёту нового дайджеста SHA1.
 *
 *  Параметры
 *      context: [in/out]
 *          Контекст для инициализации.
 *
 *  Возвращает код ошибки.
 *
 */
int SHA1Reset(SHA1Context *context)
{
    if (!context)
    {
        return shaNull;
    }

    context->Length_Low             = 0;
    context->Length_High            = 0;
    context->Message_Block_Index    = 0;

    context->Intermediate_Hash[0]   = 0x67452301;
    context->Intermediate_Hash[1]   = 0xEFCDAB89;
    context->Intermediate_Hash[2]   = 0x98BADCFE;
    context->Intermediate_Hash[3]   = 0x10325476;
    context->Intermediate_Hash[4]   = 0xC3D2E1F0;

    context->Computed   = 0;
    context->Corrupted  = 0;

    return shaSuccess;
}

/*
 *  SHA1Result
 *
 *  Описание
 *      Эта функция возвращает 160-битовый дайджест сообщения в
 *      массиве Message_Digest, предоставленном вызывающим.
 *      Примечание. Первый октет хэша сохраняется в элементе 0,
 *                  последний - в элементе массива 19.
 *
 *  Параметры
 *      context: [in/out]
 *          Контекст для расчёта хэша SHA-1.
 *      Message_Digest: [out]
 *          Возвращаемый функцией дайджест.
 *
 *  Возвращает код ошибки.
 *
 */
int SHA1Result( SHA1Context *context,
                uint8_t Message_Digest[SHA1HashSize])
{
    int i;

    if (!context || !Message_Digest)
    {
        return shaNull;
    }

    if (context->Corrupted)
    {
        return context->Corrupted;
    }

    if (!context->Computed)
    {
        SHA1PadMessage(context);
        for(i=0; i<64; ++i)
        {
            /* Сообщение может быть секретным, переменная очищается */
            context->Message_Block[i] = 0;
        }
        context->Length_Low = 0;    /* Размер очистки */
        context->Length_High = 0;
        context->Computed = 1;
    }

    for(i = 0; i < SHA1HashSize; ++i)
    {
        Message_Digest[i] = context->Intermediate_Hash[i>>2]
                            >> 8 * ( 3 - ( i & 0x03 ) );
    }

    return shaSuccess;
}

/*
 *  SHA1Input
 *
 *  Описание
 *      Функция принимает следующую часть сообщения как массив октетов.
 *
 *  Параметры
 *      context: [in/out]
 *          Контекст SHA для обновления
 *      message_array: [in]
 *          Массив символов следующей части сообщения.
 *      length: [in]
 *          Размер сообщения в message_array
 *
 *  Возвращает код ошибки.
 *
 */
int SHA1Input(    SHA1Context    *context,
                  const uint8_t  *message_array,
                  unsigned       length)
{
    if (!length)
    {
        return shaSuccess;
    }

    if (!context || !message_array)
    {
        return shaNull;
    }

    if (context->Computed)
    {
        context->Corrupted = shaStateError;

        return shaStateError;
    }

    if (context->Corrupted)
    {
         return context->Corrupted;
    }
    while(length-- && !context->Corrupted)
    {
    context->Message_Block[context->Message_Block_Index++] =
                    (*message_array & 0xFF);

    context->Length_Low += 8;
    if (context->Length_Low == 0)
    {
        context->Length_High++;
        if (context->Length_High == 0)
        {
            /* Слишком длинное сообщение */
            context->Corrupted = 1;
        }
    }

    if (context->Message_Block_Index == 64)
    {
        SHA1ProcessMessageBlock(context);
    }

    message_array++;
    }

    return shaSuccess;
}

/*
 *  SHA1ProcessMessageBlock
 *
 *  Описание
 *      Функция обрабатывает следующие 512 битов сообщения,
 *      хранящиеся в массиве Message_Block.
 *
 *  Параметров нет.
 *
 *  Функция не возвращает значения.
 *
 *  Комментарий
 *      Многие имена переменных в этом коде, особенно 1-символьные,
 *      заимствованы из спецификации алгоритма.
 *
 *
 */
void SHA1ProcessMessageBlock(SHA1Context *context)
{
    const uint32_t K[] =    {       /* Константы, заданные в SHA-1 */
                            0x5A827999,
                            0x6ED9EBA1,
                            0x8F1BBCDC,
                            0xCA62C1D6
                            };
    int           t;                 /* Счётчик циклов */
    uint32_t      temp;              /* Временное значение слова */
    uint32_t      W[80];             /* Последовательность слов */
    uint32_t      A, B, C, D, E;     /* Буферы для слов */

    /*
     *  Инициализация первых 16 слов массива W
     */
    for(t = 0; t < 16; t++)
    {
        W[t] = context->Message_Block[t * 4] << 24;
        W[t] |= context->Message_Block[t * 4 + 1] << 16;
        W[t] |= context->Message_Block[t * 4 + 2] << 8;
        W[t] |= context->Message_Block[t * 4 + 3];
    }

    for(t = 16; t < 80; t++)
    {
       W[t] = SHA1CircularShift(1,W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]);
    }

    A = context->Intermediate_Hash[0];
    B = context->Intermediate_Hash[1];
    C = context->Intermediate_Hash[2];
    D = context->Intermediate_Hash[3];
    E = context->Intermediate_Hash[4];

    for(t = 0; t < 20; t++)
    {
        temp =  SHA1CircularShift(5,A) +
                ((B & C) | ((~B) & D)) + E + W[t] + K[0];
        E = D;
        D = C;
        C = SHA1CircularShift(30,B);
        B = A;
        A = temp;
    }

    for(t = 20; t < 40; t++)
    {
        temp = SHA1CircularShift(5,A) + (B ^ C ^ D) + E + W[t] + K[1];
        E = D;
        D = C;
        C = SHA1CircularShift(30,B);
        B = A;
        A = temp;
    }

    for(t = 40; t < 60; t++)
    {
        temp = SHA1CircularShift(5,A) +
               ((B & C) | (B & D) | (C & D)) + E + W[t] + K[2];
        E = D;
        D = C;
        C = SHA1CircularShift(30,B);
        B = A;
        A = temp;
    }

    for(t = 60; t < 80; t++)
    {
        temp = SHA1CircularShift(5,A) + (B ^ C ^ D) + E + W[t] + K[3];
        E = D;
        D = C;
        C = SHA1CircularShift(30,B);
        B = A;
        A = temp;
    }

    context->Intermediate_Hash[0] += A;
    context->Intermediate_Hash[1] += B;
    context->Intermediate_Hash[2] += C;
    context->Intermediate_Hash[3] += D;
    context->Intermediate_Hash[4] += E;

    context->Message_Block_Index = 0;
}


/*
 *  SHA1PadMessage
 *
 *  Описание
 *      В соответствии со стандартом сообщение должно дополняться до
 *      размера, кратного 512 битам. Первый бит дополнения имеет значение 1. 
 *      В последних 64 битах дополнения указывается размер исходного 
 *      сообщения. Остальные биты имеют значение 0. Эта функция дополняет
 *      сообщение в соответствии с указанными выше правилами путём заполнения
 *      массива Message_Block. Функция также вызывает ProcessMessageBlock.
 *      При возврате предполагается что дайджест рассчитан.
 *
 *  Параметры
 *      context: [in/out]
 *          Контекст для дополнения
 *      ProcessMessageBlock: [in]
 *          Подходящая функция SHA*ProcessMessageBlock.
 *  
 *  Функция не возвращает значения.
 *
 */

void SHA1PadMessage(SHA1Context *context)
{
    /*
     *  Проверяет, не слишком ли мал текущий блок сообщения для размещения
     *  начальных битов заполнения и размера. Если блок мал, он дополняется, 
     *  обрабатывается, а затем заполнение продолжается в другом блоке.
     */
    if (context->Message_Block_Index > 55)
    {
        context->Message_Block[context->Message_Block_Index++] = 0x80;
        while(context->Message_Block_Index < 64)
        {
            context->Message_Block[context->Message_Block_Index++] = 0;
        }

        SHA1ProcessMessageBlock(context);

        while(context->Message_Block_Index < 56)
        {
            context->Message_Block[context->Message_Block_Index++] = 0;
        }
    }
    else
    {
        context->Message_Block[context->Message_Block_Index++] = 0x80;
        while(context->Message_Block_Index < 56)
        {
            context->Message_Block[context->Message_Block_Index++] = 0;
        }
    }

    /*
     *  Сохранение размера сообщения в последних 8 октетах.
     */
    context->Message_Block[56] = context->Length_High >> 24;
    context->Message_Block[57] = context->Length_High >> 16;
    context->Message_Block[58] = context->Length_High >> 8;
    context->Message_Block[59] = context->Length_High;
    context->Message_Block[60] = context->Length_Low >> 24;
    context->Message_Block[61] = context->Length_Low >> 16;
    context->Message_Block[62] = context->Length_Low >> 8;
    context->Message_Block[63] = context->Length_Low;

    SHA1ProcessMessageBlock(context);
}

7.3. Тестовый драйвер

Ниже приведён текст программы тестового драйвера для кода sha1.c.

/*
 *  sha1test.c
 *
 *  Описание
 *      Этот файл служит для выполнения кода SHA-1 в трёх тестах,
 *      указанных в FIPS PUB 180-1, а также дополнительного теста
 *      с вызовом SHA1Input для сообщения размером, кратным 512 битам,
 *      а также проверки кодов ошибок.
 *
 *  Проблем переносимости нет.
 *
 */

#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include "sha1.h"

/*
 *  Определение шаблонов для тестирования.
 */
#define TEST1   "abc"
#define TEST2a  "abcdbcdecdefdefgefghfghighijhi"
#define TEST2b  "jkijkljklmklmnlmnomnopnopq"
#define TEST2   TEST2a TEST2b
#define TEST3   "a"
#define TEST4a  "01234567012345670123456701234567"
#define TEST4b  "01234567012345670123456701234567"
    /* Кратно 512 битам */
#define TEST4   TEST4a TEST4b
char *testarray[4] =
{
    TEST1,
    TEST2,
    TEST3,
    TEST4
};
long int repeatcount[4] = { 1, 1, 1000000, 10 };
char *resultarray[4] =
{
    "A9 99 3E 36 47 06 81 6A BA 3E 25 71 78 50 C2 6C 9C D0 D8 9D",
    "84 98 3E 44 1C 3B D2 6E BA AE 4A A1 F9 51 29 E5 E5 46 70 F1",
    "34 AA 97 3C D4 C4 DA A4 F6 1E EB 2B DB AD 27 31 65 34 01 6F",
    "DE A3 56 A2 CD DD 90 C7 A7 EC ED C5 EB B5 63 93 4F 46 04 52"
};

int main()
{
    SHA1Context sha;
    int i, j, err;
    uint8_t Message_Digest[20];

    /*
     *  Выполнение тестов SHA-1
     */
    for(j = 0; j < 4; ++j)
    {
        printf( "\nTest %d: %d, '%s'\n",
                j+1,
                repeatcount[j],
                testarray[j]);

        err = SHA1Reset(&sha);
        if (err)
        {
            fprintf(stderr, "SHA1Reset Error %d.\n", err );
            break;    /* Выход из цикла j */
        }

        for(i = 0; i < repeatcount[j]; ++i)
        {
            err = SHA1Input(&sha,
                  (const unsigned char *) testarray[j],
                  strlen(testarray[j]));
            if (err)
            {
                fprintf(stderr, "SHA1Input Error %d.\n", err );
                break;    /* Выход из цикла i */
            }
        }

        err = SHA1Result(&sha, Message_Digest);
        if (err)
        {
            fprintf(stderr,
            "SHA1Result Error %d, could not compute message digest.\n",
            err );
        }
        else
        {
            printf("\t");
            for(i = 0; i < 20 ; ++i)
            {
                printf("%02X ", Message_Digest[i]);
            }
            printf("\n");
        }
        printf("Should match:\n");
        printf("\t%s\n", resultarray[j]);
    }

    /* проверка кодов ошибок */
    err = SHA1Input(&sha,(const unsigned char *) testarray[1], 1);
    printf ("\nError %d. Should be %d.\n", err, shaStateError );
    err = SHA1Reset(0);
    printf ("\nError %d. Should be %d.\n", err, shaNull );
    return 0;
}

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

Документ адресован сообществу Internet и предоставляет открытый код функции защищённого хэширования SHA-1 [FIPS 180-1]. Авторы не делают каких-либо заявлений о безопасности этой хэш-функции для конкретного применения.

Литература

[FIPS 180-1] «Secure Hash Standard», United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 180-1, April 1993.

[MD4] «The MD4 Message Digest Algorithm,» Advances in Cryptology — CRYPTO ’90 Proceedings, Springer-Verlag, 1991, pp. 303-311.

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

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

[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, «Randomness Requirements for Security», RFC 1750, December 1994.

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

Donald E. Eastlake, 3rd

Motorola

155 Beaver Street

Milford, MA 01757 USA

Phone: +1 508-634-2066 (h)

+1 508-261-5434 (w)

Fax: +1 508-261-4777

EMail: Donald.Eastlake@motorola.com

Paul E. Jones

Cisco Systems, Inc.

7025 Kit Creek Road

Research Triangle Park, NC 27709 USA

Phone: +1 919 392 6948

EMail: paulej@packetizer.com

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2001). Все права защищены.

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

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

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

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

Финансирование функций RFC Editor обеспечено Internet Society.

---

Network Working Group                                     A. Shacham
Request for Comments: 3173                                   Juniper
Obsoletes: 2393                                           B. Monsour
Category: Standards Track                                 Consultant
                                                          R. Pereira
                                                               Cisco
                                                           M. Thomas
                                                          Consultant
                                                      September 2001

Протокол компрессии данных IP

IP Payload Compression Protocol (IPComp)

PDF

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

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

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

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

Аннотация

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

1. Введение

Протокол сжатия данных (payload) IP (IPComp) предназначен для снижения размера дейтаграмм IP. Этот протокол будет повышать общую производительность связи между парой обменивающихся данными устройств (хосты, шлюзы), которые будем для простоты называть узлами (node), за счет сжатия дейтаграмм, обеспечиваемого вычислительными ресурсами узлов (основного процессора — CPU или специального сопроцессора компрессии), при передаче данных по низкоскоростным или загруженным каналам.

Компрессия данных IP особенно полезна для шифрованных дейтаграмм IP. Шифрование дейтаграмм делает распределение кодов случайным, поэтому компрессия на нижележащих уровнях (например, PPP Compression Control Protocol [RFC1962]) становится неэффективной. При совместном использовании компрессия должна выполняться до шифрования.
Этот документ определяет протокол компрессии данных IP (IPComp), структуру пакетов IPComp , ассоциации IPComp (IPCA) и несколько методов согласования IPCA.

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

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

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

2. Процесс сжатия

Процесс компрессии дейтаграмм IP состоит из 2 фаз – сжатие исходящих дейтаграмм IP (compression — компрессия) и декомпрессия входящих дейтаграмм (decompression). Процесс компрессии должен осуществляться без потерь (lossless), чтобы дейтаграммы IP после декомпрессии оставались тождественными исходным дейтаграммам.
Процессы сжатия и декомпрессии выполняются независимо для каждой дейтаграммы IP, вне связи с компрессией других дейтаграмм (stateless compression), поскольку доставка дейтаграмм IP может происходить с нарушением их порядка, а некоторые дейтаграммы могут просто оказаться недоставленными. Каждая сжатая дейтаграмма IP инкапсулирует одну порцию пользовательских данных (single IP payload).

На приемной стороне должна обеспечиваться обработка сжатых и несжатых дейтаграмм IP для того, в соответствии с политикой non-expansion, описанной в параграфе 2.2.

Компрессия исходящих дейтаграмм IP должна выполняться до того, как начнется какая-либо обработка, связанная с безопасностью IP (например, шифрование или аутентификация) и до фрагментации дейтаграмм IP. Кроме того, в IPv6 [RFC2460] компрессия исходящих дейтаграмм должна выполняться перед добавлением заголовка Hop-by-Hop Options или Routing Header, поскольку оба эти заголовка в обоих заголовках содержится информация, которая может проверяться и обрабатываться каждым узлом на пути доставки пакета, и, следовательно, должна передаваться в исходном виде.

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

2.1. Сжатые данные

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

В IPv4 [RFC0791] компрессия применяется к пользовательским данным (payload) дейтаграммы IP, начиная с первого октета после заголовка IP и продолжается до последнего октета дейтаграммы. Ни одна часть заголовка IP или опций IP не сжимается. Отметим, что в случае инкапсулированного заголовка IP (например, туннельная инкапсуляция в Ipsec) начало данных в дейтаграмме располагается сразу же после внешнего (outer) заголовка IP. В результате вложенный (инкапсулированный) заголовок IP рассматривается как часть данных и сжимается.

В контексте IPv6 протокол IPComp рассматривается как данные на всем пути (end-to-end) и не требуется поэтапный (hop-by-hop) анализ и преобразование заголовков. В результате компрессия используется, начиная с первого поля IP Header Option, которое не содержит информации, проверяемой и обрабатываемой узлами на пути доставки пакета (если такое поле имеется в заголовке) и продолжается до данных ULP в дейтаграмме IP.

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

Как показано в параграфе 3, заголовок IPComp вставляется непосредственно перед сжатыми данными. Исходный заголовок IP изменяется для учета нового размера дейтаграммы и индикации протокола IPComp. Исходное содержимое Next Header (IPv6) или поля протокола (IPv4) сохраняется в заголовке IPComp.
Декомпрессия применяется к одному непрерывному массиву октетов дейтаграммы IP. Массив начинается сразу же после заголовка IPComp и заканчивается последним байтом данных в дейтаграмме IP. При успешном завершении декомпрессии заголовок IP изменяется (восстанавливается) с учетом изменения размера дейтаграммы и поля next header (или протокол), сохраненного в заголовке IPComp. Заголовок IPComp удаляется из дейтаграммы IP и данные после декомпрессии размещаются вслед за оригинальным заголовком IP.

2.2. Правило Non-Expansion

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

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

Дейтаграммы IP со сжатыми данными нет смысла подвергать дополнительной компрессии. Предыдущая компрессия данных может быть результатом внешних процессов, выполненных протоколами более высоких уровней или внешними системами сжатия. Во избежание ненужного расхода ресурсов следует использовать адаптивные алгоритмы компрессии. Например, если сжатие i последовательных дейтаграмм IP с помощью IPCA дает отрицательный результат, следующие дейтаграммы (скажем, k) передаются без попыток сжатия. Если сжатие последующих j дейтаграмм также не дает результата, без попыток компрессии передается большее число дейтаграмм (k + n). После успешного сжатия дейтаграммы восстанавливается обычная работа IPComp. Выбор адаптивного алгоритма и пороговых значений зависит от реализации.

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

3. Структура заголовка сжатых дейтаграмм IP

Сжатые дейтаграммы IP инкапсулируются путем изменения стандартного заголовка IP и включения после него заголовка IPComp, непосредственно за которым располагаются сжатые данные. В этом разделе определяется процедура изменения заголовков IPv4 и Ipv6, а также структура заголовка IPComp.

3.1. Изменение заголовка IPv4

Перед отправкой сжатой дейтаграммы изменяются следующие поля заголовка IPv4:

Total Length

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

Protocol

В поле протокола помещается значение 108, выделенное для дейтаграмм IPComp [RFC1700].

Header Checksum

Контрольная сумма заголовка IP [RFC0791].

Остальные поля заголовка IPv4 (включая поле опций) не изменяются.

3.2. Изменение заголовка IPv6

Перед отправкой сжатой дейтаграммы изменяются следующие поля заголовка IPv6:

Payload Length

Размер сжатых данных IP.

Next Header

В поле Next Header помещается значение 108 – идентификатор дейтаграммы IPComp [RFC1700].

Все остальные поля заголовка IPv6 (включая все несжатые поля) сохраняются неизменными.

Заголовок IPComp помещается в пакет IPv6 с использованием таких же правил, как для заголовка IPv6 Fragment Header. Однако для пакетов Ipv6, содержащих одновременно заголовки IPv6 Fragment Header и IPComp, заголовок IPv6 Fragment Header должен предшествовать IPComp. Отметим, что между IPv6 Fragment Header и заголовком IPComp могут размещаться другие заголовки IPv6.

3.3. Структура заголовка IPComp

4-октетный заголовок IPComp имеет следующую структуру:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |     Flags     | Compression Parameter Index |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Next Header

8-битовый селектор, сохраняющий значение поля Protocol (IPv4) или IPv6 Next Header из оригинального заголовка IP.

Flags

8-битовое поле флагов зарезервировано для использования в будущем и должно иметь нулевое значение. На приемной стороне это поле должно игнорироваться.

Compression Parameter Index (CPI)

16-битовый индекс, определяющий тип компрессии. Значения 0-63 обозначают хорошо известные алгоритмы компрессии, не требующие дополнительной информации и устанавливаемые вручную. Сами значения индексов совпадают с идентификаторами IPCOMP Transform, определенными в [SECDOI]. Для выяснения распределенных значений и получения инструкций по выделению новых индексов следует обращаться к работе [SECDOI]. Значения 64-255 зарезервированы для использования в будущем. Значения 256-61439 согласуются между парой узлов при создании IPComp Association¹, как описано в разделе 4. Значения 61440-65535 выделены для частного использования по согласованию сторон. Оба узла могут выбирать значения CPI независимо и не существует каких-либо соотношений между выбранными каждой стороной CPI. Заголовок IPComp в исходящих пакетах должен использовать значение CPI, выбранное принимающей стороной. CPI вместе с IP-адресом получателя обеспечивает уникальную идентификацию параметров компрессии для дейтаграмм.

4. Согласование IPComp Association (IPCA)

Для использования протокола IPComp два узла должны сначала создать ассоциацию IPComp Association (IPCA) между собой. IPCA включает всю информацию, требуемую для работы IPComp, включая значения CPI, режим работы, используемые алгоритмы компрессии и все требуемые для выбранных алгоритмов параметры.
Правила организации IPComp могут задаваться на уровне пары узлов (тогда IPComp используется для всего трафика между узлами) или на уровне сеансов, когда компрессия используется только для выбранных сессий между парой узлов.
Пара узлов может согласовать использование IPComp в одном или обоих направлениях и допускается использование разных алгоритмов компрессии для каждого направления. Узлы, однако, должны согласовать между собой алгоритм компрессии для каждого из направлений, в котором они будут использовать IPCA – по умолчанию никакой алгоритм компрессии не определен.

Никакой из алгоритмов компрессии не является обязательным для реализации IPComp.
Ассоциации IPCA создаются путем динамического согласования параметров или вручную. При динамическом согласовании следует использовать протокол обмена ключами Internet Key Exchange [IKE] с IPsec. Динамическое согласование может выполняться на основе разных протоколов.

4.1. Использование IKE

Для IPComp в контексте безопасности IP протокол IKE обеспечивает требуемые механизмы и рекомендации по созданию IPCA. Используя IKE, протокол IPComp может согласовывать ассоциации как автономный или совместно с другими протоколами IPsec.

Ассоциации IPComp согласуются инициатором с использованием Proposal Payload (предложенные данные) и включением Transform Payload. Proposal Payload задает протокол компрессии данных IP (Payload Compression Protocol) в поле идентификатора протокола, а каждый элемент Transform Payload содержит конкретный алгоритм, предлагаемый другой стороне.

Значение CPI передается в поле SPI с соответствующим значением поля размера SPI. Значение CPI следует передавать как 16-битовое целое, устанавливая в поле размера SPI значение 2. Возможна также передача CPI в форме 32-битового значения с установкой размера SPI = 4. В этом случае 16-битовое значение CPI должно помещаться в два младших октета поля SPI, а старшие октеты должны содержать нулевое значение и приемная сторона должна игнорировать эти октеты. Принимающий узел должен уметь обрабатывать обе формы предложения CPI.

В домене интерпретации IP Security (Internet IP Security Domain of Interpretation или DOI) протокол IPComp должен согласовываться как Protocol ID PROTO_IPCOMP. Алгоритм компрессии согласуется как один из определенных транспортных идентификаторов IPCOMP (Transform Identifier).

Предложения IPComp могут содержать следующие атрибуты:

Encapsulation Mode

Чтобы предложить нестандартный режим инкапсуляции (например, Tunnel Mode), предложение IPComp должно включать атрибут Encapsulation Mode. Если этот атрибут не задан, используется принятая по умолчанию инкапсуляция Transport Mode.

Lifetime

Предложения IPComp используют атрибуты Life Duration (время жизни) и Life Type (жизненный тип) для определения времени жизни IPCA.

Когда согласование IPComp является частью Protection Suite, все логически связанные предложения должны быть согласованы. Однако в предложения IPComp не следует включать атрибуты, неприменимые к IPComp. Недопустимо отвергать предложения IPComp из-за того, что они не включают атрибутов других протоколов Protection Suite, не имеющих отношения к IPComp. Когда предложение IPComp включает такие атрибуты, они должны игнорироваться при создании ассоциации IPCA и, следовательно, не учитываются в работе IPComp.

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

1. Узел может избавиться от необходимости вычислений для определения алгоритма компрессии из CPI, используя один из хорошо известных алгоритмов – это может сократить время декомпрессии. Для решения этой задачи узел может согласовать CPI, значение которого совпадает с одним из предопределенных идентификаторов Transform для данного алгоритма компрессии. В частности, узел может предложить CPI из предопределенного диапазона, передавая Proposal Payload с единственным значением Transform Payload, которое совпадает с CPI. Когда предлагается более одного значения Transform Payload, узел может предложить CPI из предопределенного диапазона, используя множество предложений IPComp, каждое из которых должно включать единственное значение Transform Payload. Иными словами, если Proposal Payload содержит более одного значения Transform Payload, значения CPI должны находиться в согласованном диапазоне. Принимающий узел должен быть способен обрабатывать каждую из предложенных форм.
2. Ассоциации IPCA перестают быть уникальными при организации двух или более сеансов IPComp между парой узлов и использовании одинаковых CPI из числа хорошо известных по крайней мере для двух сессий. Отсутствие уникальности IPCA порождает проблемы при поддержке специфических для каждой ассоциации IPCA атрибутов – согласованных (например, время жизни) или внутренних (например, счетчики адаптивного алгоритма для обработки предварительно сжатого трафика). Для обеспечения уникальности всех IPCA данной пары узлов при наличии двух и более ассоциаций IPCA, использующих одинаковый алгоритм компрессии, значения CPI следует выбирать из согласованного диапазона. Однако в тех случаях, когда уникальность IPCA не требуется (например, при использовании IPCA без атрибутов), можно использовать хорошо известные CPI. Отметим, что ассоциация IPCA является уникальной, когда между парой узлов существует единственный сеанс, использующий данное хорошо известное значение CPI.

4.2. Использование протоколов, отличных от IKE

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

4.3. Ручная настройка конфигурации

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

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

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

При использовании IPComp без IPsec, компрессия данных IP может снижать уровень безопасности в Internet, подобно IP-инкапсуляции [RFC2003]. Например, IPComp может затруднять работу граничных маршрутизаторов по фильтрации дейтаграмм на основе полей заголовков. В частности, исходное значение поля Protocol из заголовка IP перемещается в заголовок IPComp, а все заголовки транспортного уровня внутри дейтаграммы (такие, как номера портов) просто оказываются в сжатой части дейтаграммы и напрямую недоступны. Фильтрующий граничный маршрутизатор сможет выполнять фильтрацию только в тех случаях, когда он принимает участие в ассоциации IPCA, используемой для компрессии. Для использования компрессии в средах. Где требуется фильтрация (или, по крайней мере, учет) всех пакетов, для принимающих узлов должен обеспечиваться механизм безопасного обмена IPCA с граничными маршрутизаторами. Это (в более редких случаях) может быть применимо к IPCA, используемым для исходящих дейтаграмм.

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

Этот документ не требует каких либо действий со стороны IANA. Используемые в данной спецификации хорошо известные номера уже определены в других документах [SECDOI].

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

В этом параграфе перечислены изменения, внесенные в данный документ по сравнению с RFC 2393, о которых должны быть предупреждены разработчики, использующие RFC 2393. Все изменения связаны с уточнением процедуры организации IPCA (IPComp Association) с использованием протокола IKE [IKE] в контексте IPsec.

1. Уточнены процедуры согласования при автономном использовании IPComp и в случаях совместной работы с другими протоколами Protection Suite.
2. Определена передача CPI в поле SPI предложений IKE – следует использовать двухоктетные поля, но могут применяться и 4-октетные. Определено размещение 16-битовых значений CPI 4 4-октетном поле. Указано, что получатель должен обрабатывать поля обоих размеров.

3. Добавлено использование по умолчанию режима инкапсуляции (Encapsulation Mode) Transport. Добавлено требование, в соответствии с которым предложения IPComp должны включать атрибут Encapsulation Mode, если они предлагают использование инкапсуляции, не совпадающей с принятой по умолчанию (например, Tunnel Mode).

4. В список поддерживаемых атрибутов добавлено время жизни – Lifetime (вместе с Transport Mode).
5. Описана обработка атрибутов преобразований в Protection Suite, которые не применимы к IPComp – такие атрибуты не следует включать в предложения IPComp и они должны игнорироваться при установке IPCA и в процессе работы IPComp. Для реализаций IPComp недопустимо отвергать предложения IPCOMP. Не включающие атрибутов других преобразований.
6. Добавлены примечания для разработчиков по вопросам согласования и использования CPI из предопределенного диапазона (хорошо известные значения).

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

[RFC0791] Postel, J., Editor, «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1700] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 1700³, October 1994. См. также www.iana.org/numbers.html

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC1962] Rand, D., «The PPP Compression Control Protocol (CCP)», RFC 1962, June 1996.

[RFC2003] Perkins, C., «IP Encapsulation within IP», RFC 2003, October 1996.

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

[IKE] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409⁴, November 1998.

[SECDOI] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407³, November 1998.

[V42BIS] CCITT, «Data Compression Procedures for Data Circuit Terminating Equipment (DCE) Using Error Correction Procedures», Recommendation V.42 bis, January 1990.

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

Abraham Shacham

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, California 94089

United States of America

EMail: shacham@shacham.net

Bob Monsour

18 Stout Road

Princeton, New Jersey 08540

United States of America

EMail: bob@bobmonsour.com

Roy Pereira

Cisco Systems, Inc.

55 Metcalfe Street

Ottawa, Ontario K1P 6L5

Canada
EMail: royp@cisco.com

Matt Thomas

3am Software Foundry

8053 Park Villa Circle

Cupertino, California 95014

United States of America

EMail: matt@3am-software.com

---

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

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

nmalykh@protokols.ru

Комментарии

Комментарии следует направлять по адресу ippcp@external.cisco.com (список рассылки) или авторам.

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

Copyright (C) The Internet Society (2001). Все права защищены.

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

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

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

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

Финансирование функций RFC Editor обеспечивается Internet Society.

---

Network Working Group                                    K. Ramakrishnan
Request for Comments: 3168                            TeraOptic Networks
Updates: 2474, 2401, 793                                        S. Floyd
Obsoletes: 2481                                                    ACIRI
Category: Standards Track                                       D. Black
                                                                     EMC
                                                          September 2001

Добавление явных уведомлений о перегрузке (ECN) в IP

The Addition of Explicit Congestion Notification (ECN) to IP

PDF

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

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

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

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

Аннотация

В документе приведена спецификация включения ECN¹ в протоколы TCP и IP, включая использование для ECN двух битов заголовка IP.

1. Введение

Сначала рассматривается использование протоколом TCP процедуры отбрасывания пакетов для индикации перегрузки. Далее даются пояснения по поводу новых возможностей, обусловленных добавлением активного управления очередями (например, RED²) в инфраструктуру Internet, когда маршрутизаторы детектируют перегрузку до того, как будет переполнена очередь, и уже не обязаны отбрасывать пакеты для индикации перегрузки. Маршрутизаторы могут устанавливать маркер CE³ в заголовках пакетов IP от поддерживающих ECN транспортных протоколов. Описано, когда маршрутизаторы устанавливают маркер CE, а также рассмотрены изменения, которые нужно внести в протокол TCP для поддержки ECN. Изменения других протоколов транспортного уровня (например, негарантированная доставка пакетов unicast или multicast, гарантированная доставка multicast-пакетов, другие протоколы гарантированной доставки пакетов unicast) могут рассматриваться при разработке или стандартизации таких протоколов. В данном документе описываются также вопросы использования ECN в туннелях IP и, в частности, в IPsec-туннелях.

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

Данный документе отменяет RFC 2481 «A Proposal to add Explicit Congestion Notification (ECN) to IP», в котором ECN определяется как экспериментальный протокол для сообщества Internet. Кроме того, данный документ обновляет RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers» в части определения поля ECN в заголовке IP, RFC 2401 «Security Architecture for the Internet Protocol» (изменение обработки байтов IPv4 TOS и IPv6 Traffic Class Octet при создании в туннельном режиме заголовков, совместимых с ECN) и RFC 793 «Transmission Control Protocol» в части определения новых флагов заголовка TCP.

Алгоритмы контроля и предотвращения перегрузки протокола TCP основаны на представлении сети, как «чёрного ящика» [Jacobson88, Jacobson90]. Перегрузка или её отсутствие определяется конечными системами путём проверки состояния сети за счёт увеличения нагрузки (расширения окна перегрузки — числа пакетов, остающихся в сети) до тех пор, пока не возникнет перегрузка и связанная с ней потеря пакетов. Трактовка сети, как чёрного ящика, и потери пакетов, как индикатора перегрузки, приемлема для случаев передачи по протоколу TCP данных, которые не чувствительны или не критичны к задержкам или потере отдельных пакетов. Алгоритмы контроля перегрузки в TCP используют встроенные методы (такие, как Fast Retransmit и Fast Recovery⁴) для минимизации влияния потерь с точки зрения пропускной способности. Однако эти алгоритмы не подходят для приложений, которые чувствительны к задержкам или потере одного или нескольких пакетов. Интерактивные системы (например, telnet, просмотр web-страниц, передача аудио и видео-потоков) могут быть чувствительны к потере пакетов (при использовании транспорта без гарантии доставки, такого как UDP) или увеличению задержки, вызванному повтором передачи в результате потери пакета (при использовании гарантированного транспорта, такого как TCP).

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

Активные механизмы управления очередями детектируют перегрузку до того, как переполнится очередь, и обеспечивают индикацию перегрузки для конечных узлов. Преимущества активного управления очередями обсуждаются в RFC 2309 [RFC2309]. Такое управление позволяет избавиться от некоторых негативных свойств систем управления очередями, основанных на отбрасывании пакетов при переполнении (в частности, от нежелательной синхронизации потери пакетов во множестве потоков данных). Более важно, что в системах активного управления очередями транспортные протоколы с контролем перегрузки (например, TCP) не используют переполнение буферов в качестве индикатора перегрузки.

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

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

2. Соглашение об использовании терминов

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

3. Исходные допущения и основные принципы

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

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

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

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

• Число пакетов в отдельном потоке (например, в соединении TCP или сеансе обмена данными по протоколу UDP) также может меняться в широких пределах. Мы заинтересованы в контроле перегрузки, создаваемой потоком, который передаёт достаточно большое количество данных, чтобы такой поток оставался активным до того, как будет получен сигнал обратной связи из сети.

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

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

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

4. Активное управление очередями AQM

Упреждающее детектирование RED представляет собой один из механизмов активного управления очередями (Active Queue Management или AQM), предложенный для детектирования начинающейся перегрузки [FJ93] и развёрнутый уже в Internet [RFC2309]. AQM отбрасывает пакеты в тех случаях, когда средний размер очереди превышает пороговое значение, не дожидаясь переполнения очереди. Однако, когда AQM отбрасывает пакеты до переполнения очереди, это отбрасывание не всегда вызвано нехваткой памяти.

AQM может устанавливать маркер CE в заголовке пакета вместо того, чтобы отбросить пакет, если такое поле присутствует в заголовке IP и понятно транспортному протоколу. Использование маркера CE с ECN будет позволять получателю избавиться от избыточной задержки, связанной с повтором передачи после отбрасывания пакета. Для обозначения пакетов с установленным маркером CE далее будет использоваться термин CE-пакет.

5. Явное уведомление о перегрузке в IP

В этом документе указывается, что Internet обеспечивает индикацию наступающей перегрузки (как в RED и более ранней работе [RJ90]) путём маркировки пакетов, а не их отбрасывания. Этот механизм использует двухбитовое поле ECN в заголовке IP, которое может содержать значения от 00 до 11. В поддерживающем ECN транспорте (ECN-Capable Transport или ECT) отправитель устанавливает маркер 10 или 01 для индикации поддержки конечной точкой возможностей ECN, эти маркеры обозначаются ECT(0) и ECT(1), соответственно. Термин «маркер ECT» в данном документе будет использоваться применительно к обоим случаям. Маршрутизаторы трактуют коды ECT(0) и ECT(1) одинаково⁵. Отправитель может выбрать любой из маркеров ECT(0) или ECT(1) для индикации ECT и использовать этот маркер для последующих пакетов.

Использование двух маркеров ECT обусловлено, прежде всего, желанием предоставить отправителю механизм проверки того, что маркер CE не теряется в сети и получатель ответит отправителю пакетов с маркером CE в соответствии с требованиями транспортного протокола. Рекомендации для отправителей и получателей по дифференциации маркеров ECT(0) и ECT(1) следует указать в отдельных документах для каждого из транспортных протоколов. В частности, данный документ не описывает различий между маркерами ECT(0) и ECT(1) для протокола TCP. Протоколам и отправителям, которым требуется единственный маркер ECT, следует использовать ECT(0)⁶.

+-----+-----+
| Поле  ECN |
+-----+-----+
  ECT   CE     [устаревшие] обозначения битов ECN в RFC 2481.
   0     0     Not-ECT
   0     1     ECT(1)
   1     0     ECT(0)
   1     1     CE

Рисунок . Поле ECN в заголовке IP.

Маркер not-ECT (00) указывает пакет, в котором не используется ECN. Маркер CE (11) устанавливают маршрутизаторы для индикации перегрузки конечным точкам. Маршрутизаторы, получающие пакеты при отсутствии места в очереди, просто отбрасывают такие пакеты, как это делается без ECN.

Применение двухбитовых маркеров ECT вступает в противоречие с использованием временных полей ECN в заголовках пакетов и маршрутизаторы должны удалять такие флаги при установке маркера CE [SCWA99]. Например, маршрутизатор, удаляющий маркер CE, будет сталкиваться с дополнительными сложностями при попытках восстановления исходного поля и, таким образом, повторное удаление маркера CE будет с большей очевидностью обнаружено конечными точками. Временные поля ECN могут также приводить к проблемам, связанным с тем, что некоторые получатели не будут информировать отправителя о наличии в пакете маркера CE. Мотивация выбора двухбитовых маркеров ECT более детально рассматривается в разделе 20 вместе с обсуждением варианта использования четвёртого маркера ECT (01). Вопросы совместимости с ранними реализациями ECN, которые не понимают маркеров ECT(1), рассматриваются в разделе 11.⁷

В RFC 2481 [RFC2481] поле ECN было разделено на две части — бит ECT и бит CE. Поле ECN, в котором установлен только бит ECT (в соответствии с RFC 2481), эквивалентно маркеру ECT(0), а поле ECN, в котором установлены оба флага ECT и CE, — маркеру CE. Маркер 01 не определён в RFC 2481 и по этой причине следует использовать маркер ECT(0) в тех случаях, когда требуется единственный маркер ECT.

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|           Поле DS, DSCP           | Поле  ECN |
+-----+-----+-----+-----+-----+-----+-----+-----+

    DSCP: код дифференцированного обслуживания
    ECN:  явное уведомление о перегрузке

Рисунок . Поля Differentiated Services и ECN в заголовке IP.

Биты 6 и 7 октета IPv4 TOS обозначены как поле ECN. Октет IPv4 TOS соответствует октету Traffic Class в IPv6, а поле ECN определяется одинаково для обоих случаев. Определения для октета IPv4 TOS [RFC791] и октета IPv6 Traffic Class были отменены определением шестибитового поля DS (Differentiated Services) [RFC2474, RFC2780]. Биты 6 и 7 указаны в [RFC2474], как неиспользуемые (Currently Unused), а в RFC 2780 — как предложенные для экспериментального использования в ECN. В разделе 22 приведена краткая ретроспектива применения октета TOS.

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

При получении поддерживающим ECN транспортным протоколом одного CE-пакета алгоритм контроля перегрузки в конечной системе должен работать в точности так же, как при индикации перегрузки путём отбрасывании одного пакета⁸. Например, для поддерживающей ECN реализации протокола TCP требуется, чтобы отправитель уменьшил вдвое размер окна перегрузки для любого окна данных, в котором произошло отбрасывание пакета или был получен индикатор ECN.

Одной из причин требования идентичной реакции на индикацию перегрузки при получении CE-пакета и отбрасывании пакета является необходимость обеспечения постепенного развёртывания. ECN как в конечных системах, так и в маршрутизаторах. Некоторые маршрутизаторы могут отбрасывать ECN-пакеты⁹ (например, при использовании некоторых правил обнаружения перегрузки в AQM), тогда как другие маршрутизаторы будут устанавливать маркер CE при таких же условиях перегрузки. Подобно этому, маршрутизатор может отбрасывать не поддерживающие ECN пакеты или устанавливать бит CE в ECN-пакетах при одинаковых условиях перегрузки. Разная реакция на индикацию перегрузки путём установки бита CE и отбрасывания пакетов может приводить к различным (неправильным) трактовкам для разных потоков.

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

Маршрутизаторам¹⁰ следует устанавливать маркер CE в ECN-пакетах только в тех случаях, когда маршрутизатор должен был бы отбросить пакет для индикации перегрузки конечным узлам. Когда буфер ещё не заполнен, но маршрутизатор уже приготовился к отбрасыванию пакетов для уведомления конечных узлов о перегрузке, этому маршрутизатору следует сначала проверить наличие маркера ECT в заголовке IP. Если маркер установлен, вместо отбрасывания пакетов маршрутизатор может помещать маркер CE в заголовок IP.

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

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

Рассмотренная выше ситуация, когда установка CE используется взамен отбрасывания пакетов, применяется по умолчанию ко всем Differentiated Service PHB¹¹ [RFC 2475]. Спецификации для PHB могут более детально указывать, как совместимые реализации должны выбирать между отбрасыванием пакетов и установкой CE, но такая детализация не требуется. Для маршрутизатора недопустима установка CE вместо отбрасывания пакета, когда это отбрасывание обусловлено причинами, отличными от подступающей перегрузки или желания указать конечным узлам на начинающуюся перегрузку (например, граничный узел diffserv может быть настроен на безусловное отбрасывание некоторых классов трафика на входе в домен).

Предполагается, что маршрутизаторы будут устанавливать маркер CE при начинающейся перегрузке, определяемой по среднему размеру очереди с использованием алгоритма RED, предложенного в [FJ93, RFC2309]. По имеющимся у авторов сведениям этот вариант является единственным предложением, обсуждаемым IETF, для упреждающего отбрасывания пакетов маршрутизаторами до переполнения буферов. Однако данный документ не пытается задавать тот или иной механизм активного управления очередями, оставляя решение этого вопроса (если он возникнет) за IETF. Хотя использование ECN связано с вопросом о необходимости иметь подходящий механизм активного управления очередями в маршрутизаторах, авторы не настаивают на использовании именно этого механизма. Методы активного управления очередями были разработаны и развёрнуты независимо от ECN с отбрасыванием пакетов для индикации перегрузки ещё до начала использования ECN в архитектуре IP.

5.1. ECN как индикация установившейся перегрузки

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

Например, механизмы индикации перегрузки ATM и Frame Relay обычно определяются без связи со средним размером очереди, как индикатором перегрузки промежуточного узла. Разумно предположить, что такая индикация будет создавать избыточный шум. Реакция отправителя TCP в соответствии с данной спецификацией для ECN не является подходящим вариантом для такого шумного сигнала о перегрузке. Однако, если маршрутизаторы, имеющие интерфейсы в сети ATM, получат способ определения среднего размера очереди для интерфейса и станут использовать этот размер для надёжного обнаружения перегрузки в подсети ATM, они могут использовать уведомления ECN, описанные в данной спецификации.

Мы продолжаем поощрять эксперименты с методами реализации преимуществ ECN на уровне 2 (например, в коммутаторах ATM или Frame Relay). К примеру, используя схемы типа RED (когда пакеты маркируются на основе превышения средним размером очереди заданного порога), устройства канального уровня могут обеспечивать достаточно надёжную индикацию перегрузки. Когда все устройства уровня 2 на пути установят принятый на этом уровне маркер возможной перегрузки (например, бит EFCI для ATM или FECN для Frame Relay) с использованием надёжного детектирования перегрузки, интерфейс маршрутизатора в сеть уровня 2 сможет транслировать такую индикацию в маркеры CE заголовков IP. Мы признаем, что в сегодняшней практике и стандартах такого не наблюдается. Однако продолжение экспериментов в этом направлении может дать информацию, которая позволит найти способ перехода от имеющихся механизмов канального уровня к более надёжной индикации перегрузки с использованием одного бита.

5.2. Отброшенные и повреждённые пакеты

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

Транспортные протоколы, такие как TCP, не обязательно детектируют отбрасывание любых пакетов (в частности, пакетов, содержащих лишь подтверждение ACK), например, TCP не снижает скорость доставки последующих пакетов ACK в ответ на ранее отброшенные пакеты ACK. Любые предложения по расширению ECN на такие пакеты будут приводить к возникновению проблем, таких, как маркировка пакета ACK кодом CE и последующее отбрасывание такого пакета в сети. Мы надеемся, что этот аспект будет исследован специально, поэтому в настоящем документе указывается, что «чистые» пакеты ACK недопустимо использовать для индикации поддержки ECN.

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

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

Пакеты с поддержкой ECN могут иметь установленный флаг DF (не фрагментировать). При сборке фрагментов недопустимо терять индикацию перегрузки. Иными словами, если любой из фрагментов собираемого пакета IP имеет код CE, должны выполняться одно из двух действий, указанных ниже.

• Установка кода CE для собранного пакета. Недопустимо устанавливать этот код, если хотя бы один из собираемых фрагментов имеет код Not-ECT.

• Отбрасывание пакета вместо сборки фрагментов (по любой причине).

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

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

Могут возникать ситуации, когда приведённая выше спецификация сборки фрагментов будет недостаточно точна. Например, при наличии вредоносных или сбойных элементов пути в точке фрагментации или после неё, фрагменты могут содержать смесь кодов ECT(0), ECT(1), Not-ECT. Спецификация сборки фрагментов, приведённая выше, не включает требований для такого случая. В ситуациях, когда требуется более чёткое поведение при сборке фрагментов, спецификации протокола следует вместо этого указывать, что во всех передаваемых протоколом пакетах, способных поддерживать ECN, должен устанавливаться флаг DF.

6. Поддержка в транспортном протоколе

ECN требует поддержки со стороны транспортного протокола в дополнение к функциональности, обеспечиваемой полем ECN в заголовке пакета IP. Транспортный протокол может требовать согласования между конечными точками при организации соединения для проверки поддержки ими ECN, чтобы отправитель мог устанавливать код ECT в передаваемых пакетах. Во-вторых, транспортный протокол должен быть способен соответствующим образом реагировать на получение пакетов CE. Эта реакция может выражаться в форме информирования отправителя данных о полученном пакете CE (например, TCP), отказа получателя от участия в многоуровневой multicast-группе (например, RLM [MJV96]) или в ином виде, обеспечивающем, в конечном итоге, снижение скорости поступления потока данных через перегруженное соединение. Пакеты CE показывают скорее долговременную, чем краткосрочную перегрузку (см. параграф 5.1) и поэтому реакция на получение пакетов CE должна соответствовать продолжающейся перегрузке.

В этом документе рассматривается добавление поддержки ECN только для протокола TCP, а рассмотрение вопросов использования ECN в других транспортных протоколах оставлено для будущих исследований. Для TCP добавление ECN требует поддержки трёх новых функций — согласования между конечными точками в процессе организации соединения для проверки поддержки ECN на обеих сторонах, флага ECN-Echo (ECE) в заголовке TCP для информирования отправителя о получении пакета CE, флага CWR¹³ в заголовке TCP для информирования получателя о снижении размера окна перегрузки. Очевидно, что функциональность, требуемая от других протоколов (в частности, протоколов групповой адресации с гарантиями доставки и без таковых), будет отличаться и определится при стандартизации этих транспортных протоколов в IETF.

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

6.1. TCP

В последующих параграфах подробно рассматривается предложенное использование ECN в TCP. Эти предложения представлены в той же форме, что и в работе [Floyd94]. Предполагается, что TCP на стороне отправителя использует стандартные алгоритмы контроля перегрузки Slow-start, Fast Retransmit и Fast Recovery [RFC2581].

Это предложение задаёт два новых флага в резервном поле заголовка TCP. Механизм TCP для согласования поддержки ECN использует флаг ECE (ECN-Echo) в заголовке TCP (бит 9 в поле Reserved заголовка TCP). Местоположение 6-битового резервного поля заголовка TCP показано на рисунке 3¹⁴ в RFC 793 [RFC793], приведённом здесь для полноты. Данная спецификация поля ECN оставляет 4-битовое резервное поле (биты 4 — 7).

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|               |                       | U | A | P | R | S | F |
| Header Length |        Reserved       | R | C | S | S | Y | I |
|               |                       | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Рисунок . Старое определение байтов 13 и 14 в заголовке TCP.

Чтобы обеспечить получателю TCP возможность определения момента прекращения установки флага ECN-Echo, в заголовок TCP добавлен ещё один флаг — CWR. Для флага CWR выделен бит 8 резервного поля в заголовке TCP.

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|               |               | C | E | U | A | P | R | S | F |
| Header Length |    Reserved   | W | C | R | C | S | S | Y | I |
|               |               | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Рисунок . Новое определение байтов 13 и 14 в заголовке TCP.

Таким образом, ECN использует флаги ECT и CE в заголовке IP () для сигнализации между маршрутизаторами и конечными точками соединений, а также флаги ECN-Echo и CWR в заголовке TCP () для сигнализации между конечными точками TCP. Для соединения TCP типичная последовательность событий в основанной на ECN реакции на перегрузку представлена ниже.

• В передаваемых пакетах устанавливается код ECT для индикации поддержки ECN транспортными элементами.

• Поддерживающий ECN маршрутизатор детектирует приближающуюся перегрузку и видит код ECT в пакете, намеченном для отбрасывания. Вместо отбрасывания пакета маршрутизатор устанавливает код CE в заголовке IP и пересылает пакет.

• Получатель принимает пакет с кодом CE и устанавливает флаг ECN-Echo в следующем пакете TCP ACK, передаваемом отправителю.

• Отправитель получает пакет TCP ACK с флагом ECN-Echo и реагирует на перегрузку как в случае отбрасывания пакета.

• Отправитель устанавливает флаг CWR в заголовке TCP следующего пакета, передаваемого получателю, для подтверждения приёма и реакции на флаг ECN-Echo.

Согласование использования ECN транспортными элементами TCP, а также использование флагов ECN-Echo и CWR более подробно описаны в последующих параграфах.

6.1.1 Инициализация TCP

На этапе организации соединения TCP модули TCP на стороне отправителя и получателя обмениваются информацией о своём намерении использовать ECN. После завершения этого согласования отправитель TCP устанавливает код ECT в заголовке IP пакета данных для указания сетевым устройствам возможности и желания использовать ECN для этого пакета. Этот код показывает маршрутизаторам, что они могут маркировать данный пакет кодом CE, если они хотят использовать такой метод индикации перегрузки. Если соединение TCP не хочет использовать ECN—уведомление для отдельного пакета, передающая сторона TCP устанавливает в качестве кода ECN значение not-ECT, а получатель TCP игнорирует код CE в полученном пакете.

В дальнейшем обсуждении будем обозначать инициирующий соединение хост, как A, а отвечающий — B. Будем называть пакет SYN с флагами ECE и CWR «SYN-пакетом организации ECN¹⁵», а пакет SYN, в котором флаг ECE или CWR сброшен — «пакетом SYN без организации ECN». Аналогично будем называть пакет SYN-ACK с флагом ECE, но без флага CWR «SYN-ACK-пакетом организации ECN¹⁶», а пакет SYN-ACK с другой комбинацией флагов ECE и CWR — пакетом «SYN-ACK без организации ECN».

Прежде, чем соединение TCP сможет использовать ECN, хост A передаёт SYN-пакет организации ECN, а хост B передаёт пакет SYN-ACK с организацией ECN. Для пакета SYN установка обоих флагов ECE и CWR в SYN-пакете с организацией ECN определяется, как индикация поддержки ECN на передающей стороне TCP, а не индикация перегрузки или отклика на неё. Говоря точнее, пакет SYN с организацией ECN показывает, что реализация TCP, передающая пакет SYN, будет принимать участие в ECN, как отправитель и получатель. В качестве получателя она будет отвечать на пакеты данных с кодом CE в заголовке IP установкой флага ECE в исходящих подтверждениях TCP ACK. В качестве отправителя она будет отвечать на входящие пакеты с флагом ECE снижением размера окна перегрузки и установкой флага CWR, когда это следует делать. Пакет SYN с организацией ECN не обязывает отправителя TCP устанавливать код ECT в каком-либо или всех пакетах, которые он может передать. Однако обязанность подобающим образом отвечать на входящие пакеты с кодом CE сохраняется даже в том случае, когда отправитель TCP позднее в сеансе TCP передаёт пакет SYN без установленных флагов ECE и CWR.

Когда хост B передаёт пакет SYN-ACK с организацией ECN, он устанавливает флаг ECE, но не устанавливает флаг CWR. Пакет SYN-ACK с организацией ECN определяется, как индикация того, что узел TCP, передавший пакет SYN-ACK, поддерживает ECN. Как и SYN, пакет SYN-ACK с организацией ECN не обязывает хост TCP устанавливать код ECT в передаваемых пакетах.

Приведённые ниже правила применяются для пакетов организации ECN в соединении TCP, определяемом стандартными правилами организации и разрыва соединений TCP.

• Если хост получил SYN-пакет с организацией ECN, он может передать пакет SYN-ACK с организацией ECN. В остальных случаях передача пакетов SYN-ACK в организацией ECN недопустима.

• Для хоста недопустима установка ECT в пакетах данных, пока этот хост не передал хотя бы один пакет SYN или SYN-ACK с установкой ECN и не получил хотя бы один пакет SYN или SYN-ACK с организацией ECN, не передавая пакетов SYN или SYN-ACK без организации ECN. Если хост получил хотя бы один пакет SYN или SYN-ACK без организации ECN, ему не следует устанавливать ECT в пакетах данных.

• Если хост установил код ECT в пакете данных, он должен корректно устанавливать/сбрасывать флаг CWR в заголовках TCP всех последующих пакетов данного соединения.

• Если хост передал хотя бы один пакет SYN или SYN-ACK с организацией ECN и не получал пакетов SYN или SYN-ACK без организации ECN, тогда этот хост при получении пакетов данных TCP с кодами ECT и CE в заголовке IP должен обрабатывать их, как задано для соединений, поддерживающих ECN.

• Хосту, не желающему использовать ECN в соединении TCP, следует сбрасывать оба флага ECE и CWR во всех пакетах SYN и SYN-ACK без организации ECN, которые он передаёт для индикации своего нежелания. Получатели должны корректно обрабатывать все формы пакетов SYN и SYN-ACK без организации ECN.

• Для хоста недопустимо устанавливать ECT в пакетах SYN или SYN-ACK¹⁷.

Клиент TCP переходит в состояние TIME-WAIT после получения пакета FIN-ACK и потом в состояние CLOSED по истечении тайм-аута. Многие реализации TCP создают в состоянии TIME-WAIT новое соединение, если получают в окне пакет SYN. Когда хост TCP переходит в состояние TIME-WAIT или CLOSED, ему следует игнорировать все прежние данные о согласовании ECN для этого соединения.

6.1.1.1. Промежуточные устройства

ECN добавляет 2 флага (ECN-Echo и CWR) в заголовок TCP () для инициализации. В Internet имеются некорректно работающие межсетевые экраны, устройства балансировки и системы детектирования вторжений, которые отбрасывают SYN-пакеты с организацией ECN или передают в ответ пакет RST, ошибочно воспринимая установленные в заголовке флаги, как сигнатуры сканирования портов для организации атак на службы (DoS). Часть таких устройств идентифицирована и на сайте [FIXES] приведён их список с указанием рекомендуемых производителями исправлений, если они имеются. На сайте [TBIT] перечислены некоторые web-серверы, на которые оказывает влияние такое оборудование. Эти списки могут служить предостережением о наличии описанной проблемы.

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

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

Отметим, что в таких случаях возможен следующий сценарий:

(1) хост A передаёт пакет SYN с организацией ECN;

(2) хост B передаёт пакет SYN/ACK с организацией ECN, который отбрасывается или задерживается;

(3) хост A передаёт пакет SYN без организации ECN;

(4) хост B передаёт пакет SYN/ACK без организации ECN.

Отметим, что в этом случае, следуя описанной выше процедуре, хосты A и B не могут устанавливать бит ECT в пакетах данных. Более того, важным следствием правил организации и использования ECN, приведённых в параграфе 6.1.1, является то, что хосту в таких случаях запрещено принимать пакеты данных с ECT, поскольку это неявно говорит об отсутствии поддержки ECN на другом хосте.

Если не указано иное в Experimental RFC потока документов IETF, промежуточным устройствам не следует отбрасывать пакеты управления TCP и повторно передаваемые пакеты TCP лишь по потому, что поле ECN в заголовке IP не содержит Not-ECT. Исключением из этого правила может быть реакция на атаку, использующую коды ECN, отличные от Not-ECT. Например, в качестве части отклика на атаку может быть приемлемо отбрасывание пакетов TCP SYN с маркировкой ECT с большей вероятностью, нежели пакетов TCP SYN с маркером Not-ECT. Такие исключения с отбрасыванием пакетов управления TCP и повторно передаваемых пакетов TCP в ответ на атаку недопустимо применять при отсутствии атак и следует разрешать лишь в том случае, когда ясно, что использование ECN способствует атаке.¹⁸

6.1.1.2. Отказоустойчивая инициализация TCP с возвратом битов резервного поля

Возникает вопрос, почему для пакетов 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 на приёмной стороне. Передающая сторона TCP в результате не вводится в заблуждение некорректными реализациями TCP, передающими пакеты SYN-ACK с отражением поля Reserved из принятого пакета SYN.

6.1.2. Отправитель TCP

Для соединений TCP, использующих ECN, новые пакеты данных передаются с кодом ECT в заголовке IP. Когда отправителю нужен только один код ECT для всех пакетов, передаваемых в соединении TCP, следует использовать ECT(0). Если отправитель получает пакет ECE 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 получает пакет ECE ACK, передающему TCP следует, в принципе, продолжать уменьшение окна перегрузки вдвое. Однако размер этого окна ограничен снизу значением в 1 MSS. Если передающий модуль TCP будет продолжать передачу, используя окно перегрузки размером 1 MSS, это приведёт к передаче одного пакета за период кругового обхода. Требуется дальнейшее снижение скорости передачи TCP в ответ на получение пакета ECN-Echo при окне перегрузки размером 1 MSS. Мы используем таймер повтора передачи в качестве меры снижения скорости в таких ситуациях, поэтому передающий модуль TCP должен сбрасывать таймер повтора при получении пакета ECN-Echo в случае единичного размера окна перегрузки. Передающий модуль TCP в результате сможет передать новый пакет только после завершения отсчёта таймера повтора.

Когда поддерживающий ECN отправитель TCP снижает по какой-либо причине (тайм-аут повтора, ускоренный повтор — Fast Retransmit или отклик на ECN Notification) размер окна перегрузки, он устанавливает флаг CWR в заголовке TCP первого пакета, передаваемого после сокращения окна. Если пакет данных отбрасывается в сети, передающий модуль TCP будет снова уменьшать окно перегрузки и повторять передачу отброшенного пакета.

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

Когда отправитель TCP готов установить флаг CWR после снижения размера окна перегрузки, ему следует устанавливать этот флаг только в первом передаваемом после сокращения окна пакете данных.

В работе [Floyd94] обсуждается реакция TCP на ECN более подробно. В работе [Floyd98] рассматривается тест с использованием эмулятора ns, который иллюстрирует множество сценариев ECN, включая ECN, за которым следует другой ECN, Fast Retransmit или Retransmit Timeout, Retransmit Timeout или Fast Retransmit, за которым следует ECN, окно перегрузки в один пакет, за которым следует ECN.

TCP следует существующим алгоритмам передачи пакетов данных в ответ на приём пакета ACK, дубликаты подтверждений или тайм-аут повтора [RFC2581]. TCP также следует обычным процедурам увеличения размера окна перегрузки при получении пакетов ACK без флага ECN-Echo [RFC2581].

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.

После того, как получатель 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.

6.1.5. Повторно переданные пакеты TCP

Этот документ указывает, что поддерживающим ECN реализациям TCP недопустимо устанавливать код ECT(0) или ECT(1) в заголовке IP для повторно передаваемых пакетов данных, а получателю данных TCP следует игнорировать поле ECN в прибывающих пакетах данных, которые находятся за пределами текущего окна получателя. Это сделано для обеспечения более эффективной защиты от атак на службы, а также устойчивости к индикации перегрузки ECN в пакетах, которые позднее отбрасываются в сети.

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

Кроме того, атакующий может подменить IP-адрес отправителя TCP и передать пакеты данных с произвольными порядковыми номерами и установленным кодом CE в заголовке IP. При получении такого обманного пакета данных приёмный модуль TCP будет считать, что данные не относятся к текущему окну приёма и возвращать дубликаты подтверждений. Мы определяем пакеты, находящиеся за пределами окна на стороне получателя TCP, как пакеты, лежащие за пределами текущего окна получателя. При получении такого пакета принимающий модуль TCP решает, следует ли считать код CE в заголовке пакета корректной индикацией перегрузки и, следовательно, нужно ли возвращать индикацию ECN-Echo отправителю данных TCP. Если получатель TCP игнорирует код CE в пакете данных за пределами окна, отправитель TCP не получит (возможно легитимной) индикации перегрузки в сети, что приведёт к нарушению сквозного контроля перегрузки. С другой стороны, если получатель данных TCP воспримет индикацию CE из пакетов за пределами окна и покажет перегрузку отправителю данных TCP, вредоносный узел, создавший обманные пакеты, лежащие за пределами окна, сможет успешно атаковать соединение TCP, заставляя отправителя без необходимости снижать (вдвое) размер окна перегрузки. Для предотвращения таких атак на службы мы указываем, что для легитимного отправителя TCP недопустима установка кода ECT в передаваемых повторно пакетах данных, а получателю TCP следует игнорировать код CE в пакетах, лежащих за пределами окна.

Негативным эффектом отказа от установки ECT(0) или ECT(1) в повторно передаваемых пакетах является то, что в результате этого отключается ECN-защита для передаваемых повторно пакетов. Однако для поддерживающих ECN соединений TCP в полностью поддерживающей ECN среде со средним уровнем перегрузки пакеты будут редко отбрасываться в результате перегрузки, поэтому повторно передаваемые пакеты в большинстве случаев не будут теряться. Повторная передача пакета говорит о том, что потери уже наблюдались (в результате повреждения или перегрузки) и ECN все равно не поможет предотвратить возможную потерю.

Отметим, что если маршрутизатор устанавливает код CE для совместимого с ECN пакета данных в соединении TCP, для этого соединения гарантируется получение индикации перегрузки в том же окне данных даже при отбрасывании или нарушении порядка доставки пакетов в сети. Мы рассматриваем здесь два случая — когда пакеты позднее передаются повторно и когда они повторно не передаются. В первом случае при отбрасывании или задержке пакета и повторе передачи этот повтор является результатом использования алгоритма Fast Retransmit или Retransmit Timeout для данного пакета или какого-то из его предшественников в том же окне данных. Поскольку отправитель уже передал пакет повторно, мы знаем, что он уже откликнулся на индикацию перегрузки для какого-то из пакетов в том же окне данных, что и исходный пакет. Таким образом, даже при отбрасывании или задержке первого пакета в сети, если у него был установлен код CE и пакет был потом проигнорирован получателем, как выходящий за пределы окна, это не создаёт проблем, поскольку отправитель уже отреагировал на индикацию перегрузки в этом окне данных. Во втором случае, если пакет никогда не передаётся повторно, такой пакет будет единственной копией соответствующих данных на стороне получателя и, следовательно, попадёт к получателю в пределах окна данных, независимо от задержки или нарушения порядка в сети. В этом случае код CE устанавливается для пакета в сети и будет трактоваться получателем, как корректная индикация перегрузки.

6.1.6. Пробы окна TCP

Когда получатель TCP анонсирует окно нулевого размера, отправитель TCP передаёт зонды для определения возможности увеличения окна на приёмной стороне. Пакеты проб не содержат пользовательских данных за исключением однобайтового порядкового номера. Если зонд отбрасывается в сети, получатель не видит такой потери. Следовательно, отправителю TCP недопустимо устанавливать код ECT или флаг CWR в пробных пакетах²⁰. Однако, благодаря порядковым номерам в пробных пакетах, эти пакеты невозможно просто подменить в DoS-атаке. Следовательно, если пробный пакет приходит с кодом CE, получателю следует реагировать на индикацию ECN.

7. Неподатливость конечных узлов

В этом разделе рассматривается опасность ECN для неподатливых²¹ конечных узлов (т. е., узлов, которые устанавливают код ECT в передаваемых пакетах, но не реагируют на получение пакетов с кодом CE). Мы понимаем, что добавление ECN в архитектуру IP не повышает сколь-нибудь существенно общий уровень уязвимости архитектуры со стороны невосприимчивых потоков.

Даже для сред, не поддерживающих ECN, следует серьёзно рассматривать возможность нарушений, которые могут быть вызваны неподатливыми или невосприимчивыми потоками (т. е. потоками, которые не отвечают на индикацию перегрузки снижением скорости доставки через загруженный канал). Например, конечная точка может «отключить контроль перегрузки», не снижая размер окна перегрузки в ответ на отбрасывание пакетов. Эта проблема важна для современного состояния Internet. Ясно, что в маршрутизаторах нужно реализовать механизмы обнаружения и дифференцированной трактовки пакетов из неподатливых потоков [RFC2309, FF99]. Предполагается также, что такие методы, как сквозное планирование на уровне потока и изоляция потоков друг от друга, дифференцированные услуги или сквозное резервирование, могут устранить некоторые из наиболее разрушительных эффектов от невосприимчивых потоков.

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

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

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

8. Неподатливость в сети

В этом разделе рассматриваются ситуации, когда маршрутизатор (возможно с враждебными целями) меняет какие-либо биты поля ECN. Отметим, что в IPv4 заголовок IP защищён от битовых ошибок контрольной суммой, но такая защита отсутствует в IPv6. Таким образом, для IPv6 поле ECN может быть непреднамеренно изменено в результате битовых ошибок в каналах или маршрутизаторах и такое изменение не будет обнаружено по причине отсутствия контрольной суммы.

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

В двух первых случаях (ложная информация о перегрузке и запрет ECN для отдельного пакета) ситуация не хуже, чем при простом отбрасывании пакета маршрутизатором. С точки зрения системы контроля перегрузки установка кода CE в отсутствии перегрузки неподатливым маршрутизатором будет не хуже, чем неоправданное отбрасывание им пакета. За счёт «удаления» кода ECT в пакете, который позднее будет отброшен в сети, действия маршрутизатора могут привести впоследствии к неоправданному отбрасыванию пакета в сети.

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

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

8.1. Осложнения, связанные с расщеплением пути

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

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

9. Инкапсулированные пакеты

9.1. Пакеты IP, инкапсулированные в IP

Инкапсуляция заголовков пакетов IP в туннели используется во многих случаях, включая IPsec и IP-in-IP [RFC2003]. В этом разделе рассматриваются вопросы, связанные со взаимодействием между ECN и IP, а также описаны два дополнительных решения. Это обсуждение дополняется рассмотрением в RFC 2983 взаимодействия между дифференцированным обслуживанием (DifServ) и различными формами туннелей IP [RFC 2983], а также использования в DifServ оставшихся 6 битов заголовка IP, не занятых ECN ().

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

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

Таким образом, использование ECN с простыми туннелями IP приведёт к тому, что маршрутизаторы будут пытаться сигнализировать о перегрузке с помощью внешнего заголовка, но эта индикация не будет получена в результате отбрасывания поля при декапсуляции на выходе из туннеля. Эта проблема возникает при использовании ECN с IPsec в туннельном режиме и RFC 2481 рекомендует отказаться от использования ECN со старыми простыми туннелями IPsec во избежание упомянутого негативного эффекта и его последствий. По мере распространения ECN простые туннели должны будут измениться для обеспечения передачи поддерживающего ECN трафика. Если трафик ECN передаётся через простой туннель и сталкивается с перегрузкой на поддерживающем ECN маршрутизаторе, это может привести к отбрасыванию последующих пакетов в зависимости от роста среднего размера очередей на перегруженном маршрутизаторе, как было отмечено в разделе 8.

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

В результате возникают два жизнеспособных варианта поведения поддерживающих ECN соединений через туннели IP, включая IPsec:

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

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

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

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

9.1.1. Опции ограниченной и полной функциональности

Опция ограниченной функциональности для инкапсуляции ECN в туннели IP обеспечивается путём установки кода not-ECT во внешнем заголовке, независимо от значения поля ECN во внутреннем заголовке. В этом случае поле ECN внутреннего заголовка не меняется при декапсуляции. Недостатком этого варианта является отсутствие поддержки ECN для части пути, использующей туннелирование IP, даже в тех случаях, когда инкапсулированный пакет (от исходного отправителя TCP) поддерживает ECN. Если инкапсулированный пакет приходит на перегруженный маршрутизатор, который поддерживает ECN, и маршрутизатор принимает решение об отбрасывании или маркировке пакета для индикации перегрузки конечному узлу, маршрутизатору не разрешается устанавливать код CE в заголовке пакета и вместо этого приходится отбрасывать пакет.

Полнофункциональная инкапсуляция ECN использует копирование кода ECN из внутреннего заголовка во внешний, если внутренний заголовок not-ECT или ECT, и установки для внешнего заголовка ECT(0), если код ECN во внутреннем заголовке имеет значение CE. При декапсуляции код CE, если он установлен, копируется из внешнего заголовка во внутренний. В остальных случаях код ECN во внутреннем заголовке остаётся неизменным. Т. е. при полной поддержке ECN процессы инкапсуляции и декапсуляции включают ряд операций. На входе туннеля полнофункциональный вариант устанавливает код ECN во внешнем заголовке. Если код ECN во внутреннем заголовке имеет значение not-ECT или ECT, этот код копируется во внешний заголовок. Если код ECN во внутреннем заголовке имеет значение CE, для кода ECN во внешнем заголовке устанавливается значение ECT(0). При декапсуляции на выходе туннеля полнофункциональный вариант устанавливает код CE во внутреннем заголовке, если этот код был установлен во внешнем. В остальных случаях это поле внутреннего заголовка не меняется.

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

1. Туннель IP должен изменять обработку октета поля DS в конечных точках туннеля IP путём реализации ограниченной или полной функциональности.

2. В дополнение к этому туннель IP может разрешить своим конечным точкам согласование выбора между полной и ограниченной функциональностью для ECN в туннеле.

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

Все туннели IP должны поддерживать опцию ограниченной функциональности и следует поддерживать также полнофункциональную опцию.

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

9.1.2. Изменения для поля ECN внутри туннелей IP

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

• если туннель IP использует полнофункциональную опцию, то код not-ECT следует устанавливать во внешнем заголовке тогда и только тогда, когда он установлен во внутреннем заголовке;

• если туннель использует опцию ограниченной функциональности, во внешнем заголовке следует устанавливать код not-ECT.

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

Рассмотрим случай, когда входная точка туннеля IP не была обновлена в соответствии с требованиями этого документа, а выходная точка обновлена для поддержки ECN. В этом случае туннель IP не настроен явно на полнофункциональную поддержку ECN. Однако поведение входной точки идентично поведению входной точки туннеля с полнофункциональной поддержкой. Если пакет из поддерживающего ECN соединения использует такой туннель, на входе туннеля может быть установлен код ECT во внешнем заголовке. Перегрузка в туннеле может привести к установке поддерживающим ECN маршрутизатором кода CE во внешнем заголовке. Поскольку туннель явно не настроен на поддержку полнофункциональной опции, выходная точка ожидает присутствия во внешнем заголовке кода not-ECT. Когда поддерживающая ECN выходная точка туннеля получает пакет с кодом ECT или CE во внешнем заголовке туннеля, который не настроен на поддержку полнофункциональной опции, этот пакет следует обрабатывать с учётом наличия кода CE. Рекомендуется для туннелей, не настроенных на поддержку полнофункциональной опции, отбрасывать пакет на выходе, если код CE установлен во внешнем заголовке, но отсутствует во внутреннем. Остальные пакеты следует пересылать.

Туннель IP не может обеспечить защиту от удаления индикации перегрузки путём замены кода ECN с CE на ECT. Удаление индикации перегрузки может влиять на сеть и другие потоки так, как невозможно было бы повлиять в отсутствие ECN. Важно отметить, что удалить можно лишь те индикаторы перегрузки, которые были установлены узлами внутри туннеля. Копия поля ECN во внутреннем заголовке сохраняет индикацию перегрузки от узлов, расположенных до входа в туннель (если внутренний заголовок также не был изменён). Если удаление индикации перегрузки связано с риском, превышающим преимущества от контроля перегрузки с помощью ECN, туннель следует настроить на поддержку ограниченной функциональности.

9.2. Туннели IPsec

IPsec поддерживает защищённую связь через потенциально небезопасные компоненты сети, такие как промежуточные маршрутизаторы. Протоколы IPsec поддерживают два режима работы (туннельный и транспортный), которые обеспечивают выполнение широкого спектра требований защиты и работу в различных средах. Заголовок протокола защиты в транспортном режиме помещается между заголовком IP (IPv4 или IPv6) и заголовком протокола вышележащего уровня (например, TCP), следовательно в транспортном режиме обеспечивается сквозная защита (между конечными точками). Туннельный режим IPsec основан на добавлении нового внешнего заголовка IP, который инкапсулирует исходный заголовок и связанный с ним пакет. Заголовки защиты в туннельном режиме вставляются между внешним и внутренним заголовками IP. В отличие от транспортного режима внешний заголовок IP и заголовки защиты туннельного режима могут удаляться и добавляться на промежуточных узлах пути, позволяя шлюзам безопасности защищать уязвимые части соединения без необходимости включения конечных точек в обеспечение защиты. Важным свойством туннельного режима в соответствии с исходной спецификацией является отбрасывание внешнего заголовка на выходе туннеля, в результате чего угрозы, связанные с изменением заголовков IP не распространяются дальше конечной точки туннеля. Дополнительную информацию о IPsec можно найти в [RFC2401].

Протокол IPsec, изначально определённый в [ESP, AH], требует, чтобы поле ECN внутреннего заголовка не менялось при декапсуляции IPsec в выходном узле туннеля — это требование противоречит возможностям полнофункциональной поддержки ECN. В то же время это обеспечивает защиту от враждебного изменения поля ECN с целью организации атак через конечные точки туннелей IPsec, поскольку в конечной точке все изменения теряются.

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

В частности, в туннельном режиме туннель IPsec должен поддерживать опцию ограниченной функциональности, кратко рассмотренную в параграфе 9.1.1, и следует также поддерживать полнофункциональную опцию, описанную в параграфе 9.1.1.

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

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

Протокол IPsec, определённый в [ESP, AH], не включает поля ECN заголовка IP в какие-либо криптографические преобразования (в туннельном режиме внешний заголовок IP не включает поля ECN). Следовательно, изменение поля ECN любым узлом в сети не оказывает влияния на сквозную защиту IPsec, поскольку не позволяет нарушить целостность данных IPsec. В результате этого IPsec не обеспечивает никакой защиты от враждебного изменения поля ECN (например, от атак MITM²³), поскольку такие изменения не оказывают влияния на сквозную защиту IPsec. В некоторых средах возможность изменения поля ECN без воздействия на проверку целостности IPsec позволяет создавать скрытые каналы, для предотвращения такой возможности или снижения полосы скрытого канала для туннеля IPsec следует выбирать режим ограниченной функциональности.

9.2.1. Согласование между конечными точками туннеля

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

• Необязательное поле SAD²⁴, показывающее способность процессов инкапсуляции и декапсуляции туннеля разрешать и запрещать использование ECN во внешнем заголовке IP.

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

• Изменения процессов инкапсуляции и декапсуляции, позволяющие разрешать и запрещать использование ECN во внешнем заголовке IP на основе значения поля SAD. Когда использование ECN во внешнем заголовке IP разрешено, в этом заголовке устанавливается код ECT для поддерживающих ECN соединений и уведомления о перегрузках (код CE) из таких соединений передаются во внутренний заголовок на выходе туннеля.

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

Эти изменения рассмотрены более подробно в трёх следующих параграфах.

9.2.1.1. Поле ECN Tunnel в SAD

Полнофункциональная поддержка ECN добавляет новое поле в SAD (см. [RFC2401]):

ECN Tunnel: разрешён (allowed) или запрещён (forbidden).

Показывает, разрешено ли совместимому с ECN соединению, использующему данную SA в туннельном режиме, получать индикацию ECN для перегрузок, возникающих в туннеле. Значение allowed разрешает уведомления ECN. Значение forbidden запрещает такие уведомления, вынуждая использовать для индикации перегрузки отбрасывание пакетов.

[Опционально. Для реализаций, не поддерживающих этот атрибут в данном поле, следует устанавливать значение forbidden.]

Если этот атрибут реализован, спецификация SA в базе данных SPD²⁵ должна поддерживать соответствующий атрибут и этот атрибут SPD должен быть включён в административный интерфейс SPD (в настоящее время описан в параграфе 4.4.1 [RFC2401]).

9.2.1.2. Атрибут ECN Tunnel в SA

Определён новый атрибут IPsec SA, позволяющий поддерживать согласование использования индикации перегрузки ECN во внешнем заголовке IP для туннелей IPsec (см. [RFC2407]). Этот атрибут является опциональным, поддерживающим его реализациям следует поддерживать также поле SAD, определённое в параграфе 9.2.1.1.

Тип атрибута

Класс	Значение	Тип
ECN Tunnel	10	Basic

Значение атрибута IPsec SA, равное 10, выделено IANA для индикации согласования атрибута ECN Tunnel SA, тип этого атрибута — Basic (см. параграф 4.5 [RFC2407]). Значения класса атрибутов используются при согласовании. Дополнительная информация, включая форматы кодирования и требования по согласованию этого атрибута SA, приведена в [RFC2407, RFC2408, RFC2409].

Значения класса

ECN Tunnel

Определяет возможность использования функциональности ECN с туннельной инкапсуляцией. Значение определяет процессы инкапсуляции и декапсуляции (см. параграф 9.2.1.3).

Резерв 0

Разрешено 1

Запрещено 2

Значения 3 — 61439 зарезервированы IANA, значения 61440 — 65535 выделены для приватного использования.

По умолчанию следует предполагать запрет (2).

ECN Tunnel является новым атрибутом SA и, следовательно, при его использовании могут возникать проблемы непонимания этого атрибута и отказа от предложения его использовать. Для совместимости со старыми версиями новым реализациям следует во всех случаях также предлагать работу без атрибута ECN. RFC 2407 в настоящее время требует от отвечающей стороны отвергать все предложения с неизвестными атрибутами, предполагается, что это требование будет заменено требованием для отвечающего не выбирать предложения или преобразования с неизвестными атрибутами.

9.2.1.3. Изменения в обработке заголовков туннелей IPsec

Для полной поддержки ECN процессы инкапсуляции и декапсуляции для полей IPv4 TOS и IPv6 Traffic Class меняются по сравнению с указанными в [RFC2401], как показано ниже.

Связь внешнего заголовка с внутренним
Поле	Внешний заголовок на инкапсуляторе	Внутренний заголовок на декапсуляторе
IPv4
DS	Копируется из внутреннего заголовка (5)	Не меняется
ECN	Создаётся (7)	Создаётся (8)
IPv6
DS	Копируется из внутреннего заголовка (6)	Не меняется
ECN	Создаётся (7)	Создаётся (8)

(5)(6) Если пакет незамедлительно будет вводиться в домен, для которого значение DSCP во внешнем заголовке неприемлемо, это значение должно быть отображено на приемлемое для домена значение [RFC 2474]. Дополнительная информация по этому вопросу содержится в [RFC 2475].

(7) Если поле ECN Tunnel в записи SAD для данной SA имеет значение allowed (разрешено) и поле ECN во внутреннем заголовке имеет значение, отличное от CE, поле ECN копируется во внешний заголовок. Если поле ECN во внутреннем заголовке имеет значение CE, в поле ECN внешнего заголовка устанавливается значение ECT(0).

(8) Если поле ECN Tunnel в записи SAD для данной SA имеет значение allowed и поле ECN во внутреннем заголовке имеет значение ECT(0) или ECT(1), а поле ECN во внешнем заголовке имеет значение CE, поле ECN из внешнего заголовка копируется во внутренний. В остальных случаях значение поля ECN во внутреннем заголовке не меняется.

(5) и (6) идентичны в соответствии с использованием в [RFC2401], хотя в [RFC2401] они различаются.

Приведённое выше описание применимо к реализациям, поддерживающим поле ECN Tunnel в SAD, такие реализации должны обеспечивать описанную здесь обработку вместо использования обработки октетов IPv4 TOS и IPv6 Traffic Class, описанной в [RFC2401]. Это обеспечивает полнофункциональную поддержку ECN с туннелями IPsec.

Реализации, не поддерживающие поле ECN Tunnel в SAD, должны обеспечивать обработку в предположении, что поле ECN Tunnel в SAD имеет значение forbidden (запрещено) для каждой SA. В этом случае обработка поля ECN сводится к двум операциям:

(7) установить для поля ECN во внешнем заголовке значение not-ECT;

(8) не менять поле ECN во внутреннем заголовке.

Такое поведение обеспечивает ограниченную поддержку ECN с туннелями IPsec.

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

9.2.2. Изменения поля ECN в туннелях IPsec

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

9.2.3. Комментарии к поддержке IPsec

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

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

Во втором комментарии ряд рецензентов отметил, что согласование SA является достаточно сложным и его добавление — нетривиальная задача. Другие предлагали в качестве альтернативы использование ICMP после организации туннеля. Поддержка согласования SA в этом документе указана, как опциональная и останется таковой — разработчики сами принимают решение о реализации этой опции. Авторы надеются, что приведённые здесь аргументы будут полезны в разных ситуациях. Если эти рекомендации не будут использованы на практике, они могут быть удалены на последующих этапах процесса стандартизации. Использование ICMP для согласования ECN после организации туннеля более сложно, нежели расширение согласования атрибутов SA. Некоторые туннели не принимают трафик, адресованный узлу выходной точки туннеля, поэтому пакеты ICMP нужно будет направлять в какой-то иной адрес — они будут «сканироваться» на выходе туннеля и отбрасываться здесь или у конечного получателя. Кроме того, ICMP не обеспечивает гарантированной доставки и поэтому существует возможность отбрасывания пакетов ICMP, для учёта которой потребуется создать дополнительный механизм подтверждений и повторов передачи. Опциональное расширение существующего механизма согласования SA представляется более эффективным решением.

9.3. Пакеты IP, инкапсулированные в пакеты других протоколов

При инкапсуляции пакетов IP в пакеты других протоколов возникают иные вопросы, связанные с ECN. Такие ситуации возникают для MPLS [MPLS], GRE [GRE], L2TP [L2TP] и PPTP [PPTP]. Для этих протоколов не возникает конфликта с ECN — дело в том, что ECN просто не может использоваться внутри туннеля, пока код ECN не может быть включён в заголовок инкапсулирующего протокола. Выполнены начальные разработки по встраиванию ECN в MPLS, а предложения по встраиванию ECN в GRE, L2TP или PPTP будут рассматриваться по мере их появления.

10. Проблемы, создаваемые «карательными» устройствами

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

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

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

11. Оценка ECN

11.1. Работы по оценке использования ECN

В этом разделе рассмотрены некоторые работы в которых проводится оценка использования ECN. На Web-странице ECN [ECN] приведены ссылки на работы по ECN и реализации ECN.

В работе [Floyd94] рассмотрены преимущества и недостатки, связанные с добавлением ECN в архитектуру TCP/IP. Как показано в основанном на модели сравнении, одним из преимуществ ECN является избавление от ненужного отбрасывания пакетов для краткосрочных и чувствительных к задержкам соединений TCP. Вторым преимуществом является предотвращение некоторых ненужных повторов передачи по тайм-аутам TCP. В этой статье подробно обсуждается интеграция ECN с механизмами контроля перегрузки TCP. К отмеченным в статье возможным недостаткам ECN относится то, что неподатливые соединения TCP могут ложно анонсировать себя, как поддерживающие ECN, а также возможность отбрасывания в сети пакетов TCP ACK, содержащих сообщения ECN-Echo. Первый из этих недостатков обсуждается в приложении к данному документу, а второй снимается путём добавления флага CWR в заголовок TCP.

Экспериментальные оценки ECN проведены в [RFC2884, K98] и сделано заключение о том, что ECN TCP обеспечивает умеренное повышение производительности по сравнению с TCP без использования ECN, потоки ECN TCP не нарушают работу потоков без поддержки ECN и ECN TCP обеспечивает отказоустойчивость для случаев перегрузки в обоих направлениях и наличия на пути множества перегруженных маршрутизаторов. Эксперименты со множеством коротких соединений для передачи web-трафика показали, что для большинства коротких соединений в результате использования ECN время передачи значительно сокращалось.

11.2. Обсуждение ECN nonce²⁶

Использование двух кодов ECT — ECT(0) и ECT(1) — может обеспечивать однобитовый маркер ECN nonce в заголовках пакетов [SCWA99]. Основной целью введения такой маркировки является предоставление отправителю возможности обнаружения фактов удаления кода CE элементами сети на пути и проверки корректности информирования со стороны получателя о приёме пакетов с кодом CE, требуемого транспортным протоколом. В этом параграфе обсуждаются вопросы совместимости с реализациями IP ECN в маршрутизаторах, соответствующих RFC 2481, которые поддерживают только один код ECT. Мы полагаем, что расширяющееся развёртывание реализаций ECN, понимающих код ECT(1), не будет вызывать каких-либо проблем. Отсутствие таких проблем очевидно для случаев, когда поддержка ECT(1) в маршрутизаторах реализуется до того, как этот код начинают использовать конечные узлы.

11.2.1. Поэтапное развёртывание ECT(1) в маршрутизаторах

ECN имеет статус экспериментального стандарта с января 1999 и уже имеются реализации ECN в маршрутизаторах, которые не понимают кода ECT(1). При стандартизации использования ECT(1) для TCP или других транспортных протоколов это может привести к тому, что отправители данных будут использовать код ECT(1), а некоторые перегруженные маршрутизаторы на пути доставки пакетов не будут понимать этот код.

Если транспортный протокол позволяет, отправитель данных может совсем не использовать код ECT(1) и передавать все поддерживающие ECN пакеты с кодом ECT(0). Если поддерживающий ECN отправитель использует ECT(1), а перегруженный маршрутизатор на пути передачи не понимает код ECT(1), этот маршрутизатор будет маркировать некоторые пакеты с кодом ECT(0) и отбрасывать некоторые пакеты с кодом ECT(1) для индикации перегрузки. Поскольку протокол TCP должен реагировать как на маркировку, так и на отбрасывание пакетов, при отбрасывании пакетов, которые могли бы быть промаркированы, не возникает каких-либо существенных проблем в сети и такое отбрасывание совместимо в общей моделью работы ECN, позволяющей маршрутизаторам самостоятельно принимать решение об отбрасывании или маркировке пакетов (см. раздел 5).

12. Список требуемых изменений для IP и TCP

В этом документе определено использование для ECN двух битов заголовка IP. Код not-ECT показывает, что транспортный протокол будет игнорировать код CE. Этот код является принятым по умолчанию значением ECN. Коды ECT показывают, что транспортный протокол хочет и может участвовать в работе ECN.

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

Для поддержки ECN в протокол TCP требуется внести три изменения — это фаза организации соединения и два новых флага в заголовке TCP. Флаг ECN-Echo используется получателем данных для информирования отправителя о получении пакета CE. Флаг сокращения окна перегрузки (CWR) используется отправителем для информирования получателя о снижении размера окна.

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

В туннелях для ECN определяются две опции.

1. Опция ограниченной функциональности без использования ECN внутри туннеля IP путём установки в поле ECN значения not-ECT и сохранения внутреннего заголовка при декапсуляции.

2. Полнофункциональная опция, когда в поле ECN внешнего заголовка может использоваться код not-ECT или один из кодов ECT в зависимости от значения поля ECN во внутреннем заголовке. При декапсуляции код CE копируется во внутренний заголовок, если этот код присутствует во внешнем заголовке, а во внутреннем установлен один из кодов ECT.

Для туннелей IPsec в этом документе также определён необязательный атрибут защищённой связи (SA), управляющий согласованием использования ECN в туннеле IPsec и необязательное поле SAD для индикации возможности использования ECN в туннельном режиме для SA. Требуемые для использования ECN изменения туннелей IPsec вносят изменения в документ RFC 2401 [RFC2401], определяющий архитектуру IPsec и задающий некоторые аспекты реализации. Новый атрибут IPsec SA дополняет атрибуты, определённые в параграфе 4.5 [RFC2407].

Этот документ отменяет действие RFC 2481 «A Proposal to add Explicit Congestion Notification (ECN) to IP²⁷», который определял ECN в качестве экспериментального протокола для сообщества Internet. В оставшейся части этого параграфа описаны связи настоящего документа с его предшественником.

RFC 2481 включает краткое обсуждение использования ECN с инкапсулированными пакетами, где отмечено, что спецификация IPsec на тот момент (январь 1999) говорит о невозможности безопасного использования ECN через туннели IPsec. В RFC 2481 также описаны изменения, которые нужно было внести в спецификации туннелей IPsec для обеспечения совместимости с ECN.

В этом документе учтены работы, выполненные с момента публикации RFC 2481. Во-первых, подробно описаны изменения для туннелей IPsec и влияние ECN на безопасность (разделы 18 и 19). Во-вторых, рассмотрение туннелей IPsec расширено для всех туннелей IP. Поскольку старые туннели IP не совместимы с потоками, использующими ECN, развёртывание ECN в сети Internet оказывало сильное давление на процессы обновления старых реализаций туннелей до совместимых с ECN версий на основе полной или ограниченной функциональности.

В этом документе не рассматриваются вопросы использования ECN в туннелях других протоколов (не IP), таких как MPLS, GRE, L2TP, PPTP. В настоящее время предварительные документы по включению поддержки ECN в MPLS находятся в стадии разработки.

В-третьих, после публикации RFC2481 были описаны процедуры ECN для повторно передаваемых пакетов данных, когда код ECT при повторной передаче устанавливать не следует. Мотивом отказа от использования кодов при повторе передачи послужило желание предотвратить возможные атаки на службы (DoS) для существующих соединений TCP. Некоторые ранние реализации TCP с поддержкой ECN могут не соответствовать (новым) требованиям по отказу от установки кода ECT в повторно передаваемых пакетах. Мы полагаем, что на практике это не вызовет существенных проблем.

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

Этот документ также включает спецификацию кода ECT(1), который может использоваться протоколом TCP, как часть реализации ECN nonce.²⁸

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

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

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

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

В подготовку этого документа внесло свой вклад много людей, включая тех, кто не участвовал в создании документа непосредственно. Мы хотим явно поблагодарить Kenjiro Cho за предложения по механизмам TCP для согласования поддержки ECN, 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 за обсуждение многих вопросов.

Обмен информацией по электронной почте со многими людьми, включая Dax Kelson, Alexey Kuznetsov, Jamal Hadi-Salim и Venkat Venkatsubra, помог в решении вопросов, связанных с несовместимым оборудованием в сети Internet, которое не реагирует на пакеты TCP SYN с установленными флагами ECE и CWR. Мы благодарим Mark Handley, Jitentra Padhye и других за обсуждение вопросов инициализации TCP.

Обсуждение вопросов взаимодействия ECN и туннелей IP было прочно связано и дискуссиями и документами рабочей группы Differentiated Services. Мы благодарим Tabassum Bint Haque из Dhaka, Bangladesh за отклики по туннелям IP. Мы также благодарны Derrell Piper и Kero Tivinen за предложенные изменения RFC 2407, позволившие повысить уровень применимости согласования атрибута SA при использовании ECN с туннелями.

Мы благодарим David Wetherall, David Ely и Neil Spring за их предложения по ECN. Благодарим также Stefan Savage за обсуждение этой тематики. Мы признательны Bob Briscoe и Jon Crowcroft за поднятый вопрос о фрагментации IP, дополнительную семантику четвёртого кода ECN и обсуждение других тем. Мы благодарны Richard Wendland за отклики по нескольким затронутым в документе вопросам.

Мы также благодарим IESG и, в частности, руководителей направления Transport за их отклики и усилия по стандартизации ECN.

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

[AH] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[ECN] «The ECN Web Page», URL «http://www.aciri.org/floyd/ecn.html«.²⁹

[ESP] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload», RFC 2406, November 1998.

[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL «http://gtf.org/garzik/ecn/«.

[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.

[Floyd94] Floyd, S., «TCP and Explicit Congestion Notification», ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23.

[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.

[FF99] Floyd, S., and Fall, K., «Promoting the Use of End-to-End Congestion Control in the Internet», IEEE/ACM Transactions on Networking, August 1999.

[FRED] Lin, D., and Morris, R., «Dynamics of Random Early Detection», SIGCOMM ’97, September 1997.

[GRE] Hanks, S., Li, T., Farinacci, D. and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 1701, October 1994.

[Jacobson88] V. Jacobson, «Congestion Avoidance and Control», Proc. ACM SIGCOMM ’88, pp. 314-329.

[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«.

[K98] Krishnan, H., «Analyzing Explicit Congestion Notification (ECN) benefits for TCP», Master’s thesis, UCLA, 1998. Цитируется лишь в качестве благодарности.

[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, «Layer Two Tunneling Protocol «L2TP»», RFC 2661, August 1999.

[MJV96] S. McCanne, V. Jacobson, and M. Vetterli, «Receiver-driven Layered Multicast», SIGCOMM ’96, August 1996, pp. 117-130.

[MPLS] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M. and J. McManus, Requirements for Traffic Engineering Over MPLS, RFC 2702, September 1999.

[PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, «Point-to-Point Tunneling Protocol (PPTP)», RFC 2637, July 1999.

[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 1141, January 1990.

[RFC1349] Almquist, P., «Type of Service in the Internet Protocol Suite», RFC 1349, July 1992.

[RFC1455] Eastlake, D., «Physical Link Security Type of Service», RFC 1455, May 1993.

[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 1701, October 1994.

[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, «Generic Routing Encapsulation over IPv4 networks», RFC 1702, October 1994.

[RFC2003] Perkins, C., «IP Encapsulation within IP», RFC 2003, October 1996.

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

[RFC2309] Braden, B., et al., «Recommendations on Queue Management and Congestion Avoidance in the Internet», RFC 2309, April 1998.

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

[RFC2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, November 1998.

[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, November 1998.

[RFC2409] Harkins D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

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

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[RFC2481] Ramakrishnan K. and S. Floyd, «A Proposal to add Explicit Congestion Notification (ECN) to IP», RFC 2481, January 1999.

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

[RFC2884] Hadi Salim, J. and U. Ahmed, «Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks», RFC 2884, July 2000.

[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[RFC2780] Bradner S. and V. Paxson, «IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers», BCP 37, RFC 2780, March 2000.

[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.

[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.

[TBIT] Jitendra Padhye and Sally Floyd, «Identifying the TCP Behavior of Web Servers», ICSI TR-01-002, February 2001. URL «http://www.aciri.org/tbit/«.

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

Вопросы безопасности рассматриваются в разделах 7, 8, 18 и 19.

17. Пересчёт контрольной суммы в заголовке 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

Похожее изменение контрольной суммы IPv4 может выполняться при изменении поля ECN с ECT(1) на CE (с 01 на 11).

18. Возможные изменения поля ECN в сети

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

18.1. Возможные изменения заголовка IP

18.1.1. Удаление индикатора перегрузки

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

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

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

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

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

Последним из трёх возможных изменений является замена кода CE кодом not-ECT, которая одновременно удаляет индикацию перегрузки и запрещает использование ECN.

Удаление индикации перегрузки даёт эффект только в том случае, когда пакет впоследствии не будет промаркирован заново или отброшен маршрутизатором нисходящего потока. Если код CE заменяется кодом ECT, пакет сохраняет совместимость с ECN и может быть снова промаркирован или отброшен маршрутизатором нисходящего потока для индикации перегрузки. Если код CE меняется на not-ECT, пакет утрачивает совместимость с ECN и может быть отброшен, но не может быть промаркирован для индикации перегрузки.

18.1.2. Ложная информация о перегрузке

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

18.1.3. Запрет поддержки ECN

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

18.1.4. Ложная индикация поддержки ECN

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

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

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

18.2. Информация, передаваемая в транспортном заголовке

Для протокола TCP поддерживающий ECN получатель может информировать партнёра TCP о своей поддержке ECN на уровне протокола TCP, помещая эту информацию в заголовок TCP на этапе организации соединения. В этом документе не рассматриваются угрозы, связанные с возможностью изменения заголовка транспортного уровня в сети. Отметим, что при использовании IPsec заголовок транспортного уровня защищён как в туннельном, так и в транспортном режиме [ESP, AH].

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

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

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

18.3. Расщеплённые пути

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

Разделим пакеты потока на две группы — A и B, предположив, что злоумышленнику доступны только пакеты группы A. Предположим, что враждебное воздействие выражается в нарушении сквозного контроля перегрузки на пути, по которому проходят пакеты группы A, путём ложной индикации поддержки ECN для восходящего направления, на котором наблюдается перегрузка, или путём удаления индикации перегрузки в нисходящем направлении. Предположим также, что имеется устройство мониторинга, которое видит пакеты обеих групп и будет «карать» пакеты групп, если суммарный поток, доступный устройству, не реагирует должным образом на индикацию перегрузки. Другим важным моментом (полагаем, что это достаточно очевидно) является то, что устройство мониторинга до использования «карательных» мер по отношению к потоку A и B будет сначала отбрасывать пакеты вместо установки в них кода CE, а также будет отбрасывать прибывающие пакеты, в которых уже установлен код CE. Если конечные узлы на практике используют сквозной контроль перегрузки, они будут видеть все индикаторы перегрузки, которые видны устройству мониторинга, и будут должным образом реагировать на перегрузку. Таким образом, устройство мониторинга успешно обеспечивает индикацию для потока на начальном этапе.

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

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

19. Влияние нарушения сквозного контроля перегрузки

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

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

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

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

19.1. Влияние на сеть и конкурирующие пути

Код CE в поле ECN используется лишь маршрутизаторами для индикации перегрузки в период «умеренной» перегрузки. Поддерживающим ECN маршрутизаторам в периоды существенных перегрузок следует отбрасывать пакеты, а не маркировать их даже в тех случаях, когда в очередях маршрутизатора ещё имеется место. Например, маршрутизаторам, использующим активное управление очередями на основе RED, следует отбрасывать пакеты вместо их маркировки, если средний размер очередей превышает верхний порог для очередей RED.

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

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

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

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

Вернёмся к примеру, описанному в параграфе 18.1.1, где установленный в пакете код CE удалялся: {11 -> 10 или 11-> 01}. Последствием этого для перегруженного маршрутизатора восходящего направления, который установил код CE, является то, что эта индикация не достигнет конечного узла данного потока. Отправитель (даже из числа полностью кооперированных и не враждебных) в результате отсутствия индикации может продолжать увеличение скорости передачи (для TCP путём расширения окна перегрузки). Поток может получить более высокую пропускную способность на перегруженном маршрутизаторе по сравнению с другими потоками, особенно при отсутствии на маршрутизаторе механизмов реализации политики или независимого распределения очередей по потокам. Рассмотрим поведение других потоков (особенно, кооперированных), которые не подверглись нарушению сквозного контроля перегрузки. Ясно, что эти потоки снизят свою нагрузку на данный маршрутизатор (например, за счёт сокращения окна), отдавая преимущества нарушенному потоку. Таким образом утрачивается беспристрастность. Как обсуждалось выше, эта пристрастность может быть кратковременной (поскольку перегруженная очередь находится в режиме маркировки пакетов), осциллирующей (очередь переключается между режимами маркировки и отбрасывания) или более сдержанной, но постоянной (поскольку очередь никогда не переключается в режим отбрасывания пакетов).

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

19.2. Влияние на нарушенный поток

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

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

Одной из форм нарушения сквозного контроля перегрузки является ложная индикация поддержки ECN путём установки кода ECT. Установка ложного кода CE будет оказывать влияние на перегруженные маршрутизаторы нисходящего направления. Однако, как было указано в параграфе 9.1.2, если код ECT меняется в туннеле IP, это может быть обнаружено на выходе туннеля, поскольку внутренний заголовок не будет изменён.

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

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

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

19.3. Не связанные с ECN методы нарушения сквозного контроля перегрузки

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

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

20. Обоснование для маркеров ECT

20.1. Обоснование для кодов 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, функционально эквивалентен потоку, в котором выключен контроль перегрузки, как обсуждалось ранее в этом документе.

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

20.2. Обоснование для двух кодов ECT

Основной причиной использования двух кодов ECT является необходимость поддержки однобитовых сигналов ECN nonce. Эти сигналы позволяют разработать для отправителя механизмы вероятностной проверки того, что элементы сети не удаляют код CE, а получатели данных корректно уведомляют отправителя о получении пакетов с кодом CE.

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

Выделение четвёртого кода ECN — ECT(1) преследовало иные цели. Для ясности эти цели кратко перечислены ниже.

Одной из целей может быть использование отправителем четвёртого кода ECN для индикации дополнительной семантики ECN. Однако для такой сигнализации нам представляется более целесообразным использование кодов дифференцированного обслуживания в поле DS.

Второй возможной целью является использование четвёртого кода ECN для предоставления маршрутизаторам двух разных кодов перегрузки — CE(0) и CE(1) для слабого и сильной перегрузки, соответственно. Это может быть полезно в некоторых случаях, однако такое требование не представляется целесообразным. Если внести это требование, сложность постепенного развёртывания существенно возрастёт по сравнению со случаем использования одного кода.

Третьим неформально предложенным вариантом использования четвёртого кода ECN является его применение в некоторых формах контроля перегрузки для групповых приложений на основе процедур случайного дублирования маркированных пакетов в маршрутизаторах. Некоторые из предложенных процедур дублирования multicast-пакетов на маршрутизаторах основаны на новом коде ECN, который (1) переносит информацию о перегрузке в восходящем направлении от точки дублирования, промаркировавшей пакет этим кодом, и (2) может детектировать перегрузку в нисходящем направлении от точки дублирования. ECT(1) можно использовать для этой цели, поскольку этот код отличается от ECT(0) и заменяется кодом CE при маркировке ECN в ответ на перегрузку или начало перегрузки. Описание этой расширенной версии использования ECN для контроля перегрузки в групповых приложениях выходит за рамки документа, как и процедуры дублирования групповых пакетов, совместимые с ECN, или обработка поля ECN получателями группового трафика во всех случаях (независимо от процедур дублирования multicast-пакетов).

Спецификация изменения туннелей IP для ECN в этом документе предполагает, что единственным изменением, которое вносится в поле ECN внешнего заголовка IP между конечными точками туннеля, является установка кода CE для индикации перегрузки. Это не согласуется с предложениями по использованию ECT(1) процедурами дублирования multicast-пакетов, рассмотренными в предыдущем параграфе, и такие процедуры не следует развёртывать до разрешения противоречия между процедурами дублирования и туннелями IP с полной функциональностью ECN. Взамен может использоваться ограниченная функциональность ECN, хотя на практике многие протоколы туннелирования (включая IPsec) не будут корректно работать при дублировании группового трафика в туннеле.

21. Зачем использовать два бита в заголовке 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-сессии.

Другой, рассмотренный выше вопрос (и рекомендация) касается того, что транспортному протоколу (в частности, TCP) не следует маркировать чистые пакеты ACK и пакеты, передаваемые повторно, как поддерживающие ECN. Чистый пакет ACK из неподдерживающего ECN транспорта может быть отброшен без воздействия на транспорт с точки зрения контроля перегрузки (поскольку подтверждения кумулятивны). Поддерживающий ECN транспорт реагирует на код CE в чистом пакете ACK снижением размера окна перегрузки и такое поведение является проигрышным по сравнению с транспортом без поддержки ECN. По этой причине (и по описанным выше причинам в части повторно передаваемых пакетов), желательно устанавливать код ECT независимо для каждого пакета.

Ещё одним преимуществом двухбитового кода является повышенная отказоустойчивость. Наиболее критический момент, описанный в разделе 8, заключается в том, что по умолчанию следует указывать не поддерживающий ECN транспорт. В двухбитовом варианте для реализации этого требования достаточно просто устанавливать по умолчанию код not-ECT. В однобитовом варианте для выполнения этого требования следует устанавливать код CE или ECT. Этот вариант менее понятен и возможно более открыт для некорректных реализаций на конечных узлах или маршрутизаторах.

Хотя в целом 1-битовая реализация вполне допустима, она имеет ряд существенных недостатков по сравнению с двухбитовым вариантом. Во-первых, функциональность однобитового варианта существенно ограничена в плане трактовки пакетов с кодом CE на втором перегруженном маршрутизаторе. Во-вторых, однобитовый вариант требует передачи дополнительной информации в заголовке транспортного уровня пакетов из поддерживающего ECN потока (функциональность двухбитового варианта просто переносится на транспортный уровень) или понимания со стороны отправителей поддерживающих ECN потоков того, что получатели должны быть способны a-priori определить какие пакеты поддерживают ECN, а какие не поддерживают. В-третьих, однобитовая реализация потенциально более открыта для ошибок со стороны некорректных реализаций, которые могут по умолчанию устанавливать неверное значение бита ECN. Мы полагаем, что перечисленные ограничения обеспечивают достаточные основания использования дополнительного бита в заголовке IP для кодов ECT.

22. Ретроспектива использования октета IPv4 TOS

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PRECEDENCE    |       TOS       |  0  |  0  |
+-----+-----+-----+-----+-----+-----+-----+-----+

RFC 791 [RFC791] определяет октет ToS³¹ в заголовке 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                   |
+-----+-----+-----+-----+-----+-----+-----+-----+

RFC 1122 включает биты 6 и 7 в поле ToS, не обсуждая конкретного их использования (см. рисунок выше).

Октет ToS заголовка IPv4 был заново определён в RFC 1349 [RFC1349], как показано ниже.

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PRECEDENCE    |       TOS             | MBZ |
+-----+-----+-----+-----+-----+-----+-----+-----+

Бит 6 поля TOS был определён в RFC 1349, как «Minimize Monetary Cost³²». В дополнение к полям Precedence и TOS было определено поле MBZ³³, которое в настоящее время не используется. В RFC 1349 отмечено, что отправитель дейтаграмм устанавливает в поле MBZ нулевое значение, если не используется экспериментальных протоколов с иной трактовкой этого бита.

RFC 1455 [RFC 1455] определяет экспериментальный стандарт, использующий все четыре бита поля TOS для запроса гарантированного уровня защиты канала.

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|               DSCP                |    CU     |
+-----+-----+-----+-----+-----+-----+-----+-----+

Документы RFC 1349 и RFC 1455 были отменены RFC 2474 «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers³⁴» [RFC2474], в котором биты 6 и 7 поля DS были указаны, как неиспользуемые (CU³⁵). В RFC 2780 [RFC2780] содержится спецификация ECN для экспериментального использования двухбитового поля CU. RFC 2780 обновляет определение поля DS, оставляя в нем лишь первых шесть битов, которые трактуются, как коды дифференцированного обслуживания (DSCP³⁶). Формат поля показан на рисунке выше.

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

До RFC 2474, маршрутизаторам не разрешалось менять биты в полях DSCP и ECN пересылаемых пакетов и, следовательно, маршрутизаторы, соответствующие только требованиям RFC до 2474, не оказывают влияния на ECN. Для конечных узлов бит 7 (второй бит ECN) должен передаваться с нулевым значением всеми реализациями, совместимыми только с RFC до 2474. Такие узлы могут передавать в бите 6 (первый бит ECN) единицу для указания необходимости экономной передачи (Minimize Monetary Cost) в соответствии с RFC 1349 или экспериментами, разрешёнными RFC 1455, однако оба эти варианта не получили широкого распространения. Помехи, которые могут создавать некорректно работающие маршрутизаторы, включают удаление кода CE для поддерживающих ECN пакетов, которые поступили на маршрутизатор с установленным флагом CE, и установку кода CE при отсутствии перегрузок. Эти вопросы рассмотрены в разделе .

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

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

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

23.1. Байт IPv4 TOS и октет IPv6 Traffic Class

Коды для поля ECN в заголовке IP задаются по процедуре Standards Action данным RFC в соответствии с RFC 2780.

Когда этот документ будет опубликован в качестве RFC, агентству IANA следует создать новый реестр IPv4 TOS Byte and IPv6 Traffic Class Octet³⁷ с пространством имён IPv4 TOS Byte и IPv6 Traffic Class Octet.

Описание: регистрация идентична для IPv4 и IPv6.

Биты 0-5: см. реестр кодов поля Differentiated Services (http://www.iana.org/assignments/dscp-registry)

Биты 6-7: поле ECN.

Значение	Ключевое слово и описание	Источник
00	Not-ECT (не поддерживающий ECN транспорт)	[RFC 3168]
01	ECT(1) (совместимый с ECN транспорт (1))	[RFC 3168]
10	ECT(0) (совместимый с ECN транспорт (0))	[RFC 3168]
11	CE (Наблюдается перегрузка)	[RFC 3168]

23.2. Флаги заголовка TCP

Коды для флагов CWR и ECE в заголовке TCP задаются по процедуре Standards Action в данном RFC, в соответствии с RFC 2780.

При публикации этого документа в качестве RFC агентству IANA следует создать новый реестр TCP Header Flags с пространством имён TCP Header Flags (Флаги заголовка TCP).

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|               |                       | U | A | P | R | S | F |
| Header Length |        Reserved       | R | C | S | S | Y | I |
|               |                       | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Заголовок TCP включает 6-битовое резервное поле, определённое в RFC 793, в байтах 13 и 14, как показано на рисунке выше. Остальные шесть битов управления определены в RFC 793.

RFC 3168 определяет два из шести битов резервного (Reserved) поля для ECN, как показано на рисунке.

  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|               |               | C | E | U | A | P | R | S | F |
| Header Length |    Reserved   | W | C | R | C | S | S | Y | I |
|               |               | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Флаги заголовка TCP

Бит	Имя	Источник
8	CWR (Congestion Window Reduced)	[RFC 3168]
9	ECE (ECN-Echo)	[RFC 3168]

23.3. Атрибуты IPSEC Security Association

Агентство IANA выделило значение атрибута IPSEC Security Association = 10 для ECN Tunnel, как описано в параграфе 9.2.1.2 по запросу David Black в ноябре 1999. В настоящее время агентство IANA сменило ссылку (Reference) для этого выделения с David Black на данный RFC.

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

K. K. Ramakrishnan

TeraOptic Networks, Inc.

Phone: +1 (408) 666-8650

EMail: kk@teraoptic.com

Sally Floyd

ACIRI

Phone: +1 (510) 666-2989

EMail: floyd@aciri.org

URL: http://www.aciri.org/floyd/

David L. Black

EMC Corporation

42 South St.

Hopkinton, MA 01748

Phone: +1 (508) 435-1000 x75140

EMail: black_david@emc.com

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2001). Все права защищены.

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

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

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

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

Финансирование функций RFC Editor обеспечено Internet Society.

Заменен RFC 5424.

Network Working Group                                   R. Droms, Editor
Request for Comments: 3118                                 Cisco Systems
Category: Standards Track                             W. Arbaugh, Editor
                                                  University of Maryland
                                                               June 2001

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

Authentication for DHCP Messages

PDF

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

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

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

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

Аннотация

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

1. Введение

Протокол DHCP [1] передает конфигурационные параметры стека протоколов от централизованно администрируемых серверов хостам TCP/IP. Среди этих параметров присутствуют адреса IP. Сервер DHCP можно настроить на динамическое выделение адресов из пула, что позволяет избавиться от этапа ручной настройки хостов TCP/IP.

Некоторые сетевые администраторы могут захотеть проверки подлинности источника и содержимого сообщений DHCP. Например, клиенты могут быть подвержены DoS²-атакам с использованием обманных серверов DHCP или могут быть некорректно настроены в результате непреднамеренного запуска сервера DHCP. Сетевые администраторы могут пожелать ограничить выделение адресов, предоставляя их лишь уполномоченным хостам, для предотвращения DoS-атак во «враждебных» средах, где физическая среда не имеет достаточной защиты, таких как беспроводные сети или студенческие общежития.

В этом документе определен метод, который может обеспечить проверку подлинности объектов и сообщений. Текущий протокол объединяет исходный механизм аутентификации Schiller-Huitema-Droms с отложенной аутентификацией, предложенной Bill Arbaugh.

1.1 Модель угроз DHCP

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

Специфичной для клиентов DHCP атакой является организация «мошеннического» сервера с целью предоставить клиентам некорректную конфигурацию. Мотивом этого может служить организация MITM³— или DoS-атаки.

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

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

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

1.2 Цели разработки

Ниже перечислены в порядке важности цели, которые послужили разработке протокола аутентификации.

1. Устранение угроз, отмеченных в параграфе 1.1.

2. Сохранение в неизменном виде текущего протокола.

3. Ограничение числа состояний, требуемых от сервера.

4. Ограничение сложности, которая порождает ошибки при разработке и реализации.

1.3 Уровни требований

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

1.4 Терминология DHCP

DHCP client — клиент DHCP

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

DHCP server — сервер DHCP

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

2. Формат аутентификационной опции

На рисунке показан формат опции DHCP для проверки подлинности.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |  Protocol     |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 бита)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Опция имеет код 90, а поле размера учитывает поля Protocol, RDM, Algorithm, Replay Detection и Authentication Information.

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

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

Поле Replay Detection относится к RDM, а поле Authentication Information — к используемому протоколу.

Поле RDM⁴ указывает тип детектирования повторного использования, используемого Replay Detection.

Если RDM = 0x00, поле Replay Detection должно содержать монотонно возрастающее значение счетчика. Применение таких счетчиков, как время суток (например, метка времени в формате NTP [4]) может снизить риск атак с воспроизведением. Этот метод должен поддерживаться всеми протоколами.

3. Взаимодействие с ретрансляторами

Поскольку ретранслятор DHCP может менять значения полей giaddr и hops в сообщении DHCP, для этих двух полей при расчете хэш-функции для заголовка сообщения должно приниматься значение 0. Кроме того, ретрансляторы DHCP могут добавлять свою информационную опцию 82 [7] в качестве последней опции сообщения серверу. Если сервер видит опцию 82 в принятом сообщении, он должен рассчитывать хэш-функцию без учета этой опции, не изменяя порядка других опций. Всякий раз, когда сервер возвращает ретранслятору опцию 82, он должен пропускать эту опцию при расчете хэш-функции для сообщения.

4. Маркер конфигурации

Если Protocol = 0, поле Authentication Information содержит простой конфигурационный маркер, показанный на рисунке.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0| Replay Detection (64 бита)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   |-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

Обсуждение.

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

5. Отложенная аутентификация

Если Protocol = 1, сообщение использует механизм отложенной аутентификации. В этом случае клиент запрашивает проверку подлинности в своем сообщении DHCPDISCOVER, а сервер отвечает сообщением DHCPOFFER и данными аутентификации. Эти данные содержат одноразовое значение (nonce), создаваемое источником как код аутентификации сообщения (MAC⁵) для проверки подлинности сообщения и объекта.

Этот документ задает использование конкретного метода на основе протокола HMAC [3] с хэш-функцией MD5 [2].

5.1 Вопросы управления

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

5.2 Формат

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

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 бита)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |
   +-+-+-+-+-+-+-+-+

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

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 бита)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. | Secret ID (32 бита)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | secret id cont| HMAC-MD5 (128 битов) ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Replay Detection

В соответствии с полем RDM.

K

Значение общего секрета для отправителя и получателя сообщения. Каждый секрет имеет уникальный идентификатор (secret ID).

secret ID

Уникальный идентификатор секретного значения, использованного при создании MAC для этого сообщения.

HMAC-MD5

Функция генерации кода MAC [3, 2].

Отправитель рассчитывает MAC используя алгоритм генерации HMAC [3] и хэш-функцию MD5 [2]. Все сообщение DHCP (исключения рассмотрены ниже), включая заголовок DHCP и поле опций служит входными данными функции расчета HMAC-MD5. Поле secret ID должно содержать идентификатор секрета, используемого для генерации MAC.

Обсуждение.

Algorithm=1 задает использование HMAC-MD5. Другие методы (например, HMAC-SHA) будут описаны в отдельном протоколе.

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

5.3 Проверка сообщения

Для проверки входящего сообщения получатель сначала проверяет приемлемость значения поля Replay Detection в соответствии с методом детектирования, заданным полем RDM. Затем получатель рассчитывает MAC, как описано в [3]. При расчете MAC получатель должен установить 0 в поле MAC аутентификационной опции, а поскольку ретрансляторы DHCP могут менять значения полей giaddr и hops в сообщении DHCP, в этих полях при расчете также должны быть установлены нулевые значения. Если рассчитанное значение MAC отличается от принятого в аутентификационной опции, получатель должен отбросить сообщение DHCP.

В разделе 3 представлена дополнительная информация по части обработки сообщений с опцией 82 (ретрансляторы).

5.4 Использование ключа

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

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

5.5 Поведение клиентов

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

5.5.1 Состояние INIT

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

1. Клиент должен включить опцию запроса аутентификации в свое сообщение DHCPDISCOVER вместе с опцией идентификации клиента [6] для однозначного представления себя серверу.

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

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

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

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

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

4. Если клиент проверил подлинность воспринятого сообщения DHCPOFFER, он должен проверить сообщение DHCPACK от сервера. Клиент должен отбросить DHCPACK, если сообщение не прошло проверку и может записать это событие в системный журнал. Если сообщение DHCPACK не прошло проверку, клиент должен восстановить состояние INIT и вернуться к п. 1. Клиент может запомнить сервер, чье сообщение DHCPACK не прошло проверку и отбрасывать последующие сообщения от него.

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

5.5.2 Состояние INIT-REBOOT

В состоянии INIT-REBOOT клиент должен применять секрет, использованный в его сообщении DHCPREQUEST, чтобы получить свою текущую конфигурацию для создания аутентификационных данных, помещаемых в сообщение DHCPREQUEST. Клиент может выбрать восприятие неаутентифицированных сообщений DHCPACK/DHCPNAK, если не было получено аутентифицированных сообщений. Клиент должен обрабатывать прием (или отсутствие) сообщений DHCPACK/DHCPNAK в соответствии с параграфом 3.2 в [1].

5.5.3 Состояние RENEWING

В состоянии RENEWING клиент применяет секрет, который он использовал в исходном сообщении DHCPREQUEST, получить свою текущую конфигурацию для создания аутентификационных данных, помещаемых в сообщение DHCPREQUEST. Если клиент не получил сообщения DHCPACK или ни одно из таких сообщений не прошло проверку, клиент ведет себя как при отсутствии сообщений DHCPACK, описанном в параграфе 4.4.5 спецификации DHCP [1].

5.5.4 Состояние REBINDING

В состоянии REBINDING клиент применяет секрет, который он использовал в исходном сообщении DHCPREQUEST, получить свою текущую конфигурацию для создания аутентификационных данных, помещаемых в сообщение DHCPREQUEST. Если клиент не получил сообщения DHCPACK или ни одно из таких сообщений не прошло проверку, клиент ведет себя как при отсутствии сообщений DHCPACK, описанном в параграфе 4.4.5 спецификации DHCP [1].

5.5.5 Сообщение DHCPINFORM

Поскольку клиент уже имеет некую конфигурационную информацию, он может иметь с сервером общий секрет K. Поэтому клиенту следует использовать запрос аутентификации как в сообщении DHCPDISCOVER при наличии общего секрета. Клиент должен трактовать все полученные сообщения DHCPACK, как указано для сообщений DHCPOFFER в параграфе 5.5.1.

5.5.6 Сообщение DHCPRELEASE

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

5.6 Поведение сервера

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

5.6.1 Общие вопросы

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

• Определить подходящий секрет и его идентификатор для использования с клиентом, с которым сервер раньше мог не взаимодействовать.

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

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

Обсуждение.

Аутентифицированное сообщение DHCPREQUEST от клиента в состоянии INIT-REBOOT может быть проверено только сервером, использующим тот же секрет, который применялся в его сообщении DHCPOFFER. Другие серверы будут отбрасывать такие сообщения DHCPREQUEST. Поэтому только сервер, использующий секрет, выбранный клиентом, сможет определить, что предложенная им конфигурационная информация не была выбрана и предложенный адрес можно вернуть в пул доступных адресов на сервере. Серверы, которые не могут проверить сообщение DHCPREQUEST, в конечном итоге вернут предложенные адреса в свои пулы доступных адресов, как описано в параграфе 3.1 спецификации DHCP[1].

5.6.2 После приема сообщения DHCPDISCOVER

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

5.6.3 После приема сообщения DHCPREQUEST

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

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

5.6.4 После приема сообщения DHCPINFORM

Сервер может воспринимать неаутентифицированные или только аутентифицированные сообщения DHCPINFORM в соответствии со своей локальной политикой.

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

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

В разделе 2 определена новая опция DHCP — Authentication Option с кодом 90.

Этот документ задает три новых пространства имен, связанных с Authentication Option, которые создаются и поддерживаются IANA — Protocol, Algorithm и RDM.

Начальными значениями для пространства имен Protocol служат 0 (конфигурационный маркер, раздел 4) и 1 (отложенная аутентификация, раздел 5). Дополнительные значения Protocol будут выделяться по процедуре IETF Consensus в соответствии с RFC 2434 [8].

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

Для протокола конфигурационных маркеров поле Algorithm должно иметь значение 0. Для протокола отложенной аутентификации значение Algorithm = 1 выделено для функции генерации HMAC-MD5, как указано в разделе 5. Дополнительные значения в пространстве имен алгоритмов для Algorithm = 1 будут выделяться по процедуре IETF Consensus в соответствии с RFC 2434.

Начальное значение 0 из пространства имен RDM выделено для использования монотонно возрастающих значений, как указано в разделе 2. Дополнительные значения из пространства имен RDM будут выделяться по процедуре IETF Consensus в соответствии с RFC 2434.

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

[1] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

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

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

[4] Mills, D., «Network Time Protocol (Version 3)», RFC 1305, March 1992.

[5] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», RFC 2219, March 1997.

[6] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[7] Patrick, M., «DHCP Relay Agent Information Option», RFC 3046, January 2001.

[8] Narten, T. and H. Alvestrand, «Guidelines for Writing and IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

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

Jeff Schiller и Christian Huitema разработали исходный вариант этого протокола проверки подлинности для терминального зала BOF на конференции IETF в Далласе в декабре 1995 г. Один из редакторов (Droms) расшифровал заметки с того обсуждения, которые послужили основой для этого документа. Редакторы высоко ценят терпение Jeff и Christian при рассмотрении этого документа и ранних черновиков.

Механизм отложенной аутентификации, используемый в разделе 5, принадлежит Bill Arbaugh. Модель угроз и требования параграфов 1.1 и 1.2 взяты из предложения Bill по протоколу согласования. Участники промежуточного совещания рабочей группы DHC в июне 1998 г., включая Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Rabil и Arun Kapur разработали модель угроз и рассмотрели несколько дополнительных вариантов.

Метод защиты от воспроизведения принадлежит Vipul Gupta.

С благодарностью отмечается вклад Bill Sommerfield.

Спасибо также John Wilkins, Ran Atkinson, Shawn Mamros и Thomas Narten за рецензирование ранних версий документа.

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

В документе описаны механизмы аутентификации и проверки для протокола DHCP.

9.1 Уязвимости протокола

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

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

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

9.2 Ограничения протокола

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

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

10. Адреса редакторов

Ralph Droms

Cisco Systems

300 Apollo Drive

Chelmsford, MA 01824

Phone: (978) 244-4733

EMail: rdroms@cisco.com

Bill Arbaugh

Department of Computer Science

University of Maryland

A.V. Williams Building

College Park, MD 20742

Phone: (301) 405-2774

EMail: waa@cs.umd.edu

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

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

nmalykh@gmail.com

Приложение A — метод управления ключами

Чтобы избавиться от централизованного управления списком случайных ключей, предположим, что K для каждого клиента создается из пары (идентификатор клиента [6], маска подсети — например, 192.168.1.0), которая должна быть уникальна для каждого клиента. Т. е. K = MAC(MK, unique-id), где MK — секретный первичный ключ, а MAC — необратимая хэш-функция с ключом, такая как HMAC-MD5.

Не зная MK, клиент без полномочий не сможет создать свой ключ K. Сервер может быстро проверить входящее сообщение от нового клиента путем регенерации K из идентификатора клиента. Для известных клиентов сервер может выбрать динамическое восстановление клиентского ключа K из client-id в сообщении DHCP или заранее рассчитать и кэшировать все K.

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

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

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

Copyright (C) The Internet Society (2001). Все права защищены.

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

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

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

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

Финансирование функций RFC Editor обеспечено Internet Society.

---

Network Working Group                                    H. Balakrishnan
Request for Comments: 3124                                       MIT LCS
Category: Standards Track                                      S. Seshan
                                                                     CMU
                                                               June 2001

The Congestion Manager

Диспетчер контроля перегрузок

PDF

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

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

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

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

Аннотация

В документе описан менеджер контроля перегрузок (Congestion Manager или CM) — модуль конечной системы, который:

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

2. обеспечивает приложениям лёгкую адаптацию к перегрузкам в сети.

1. Соглашения и термины

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

STREAM — поток

Группа пакетов с одинаковыми IP-адресами отправителя и получателя, типом обслуживания IP (TOS), транспортным протоколом, и номерами транспортных портов у отправителя и получателя.

MACROFLOW — макропоток

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

APPLICATION — приложение

Любой программный модуль, использующий CM, включая пользовательские приложения, такие как Web-серверы и серверы аудио-видео, а также встроенные в ядро протоколы, такие как TCP [Postel81], использующие CM для контроля перегрузок.

WELL-BEHAVED APPLICATION — приложение с корректным поведением

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

PATH MAXIMUM TRANSMISSION UNIT (PMTU) — максимальный блок передаваемых по пути данных

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

CONGESTION WINDOW (cwnd) — окно перегрузки

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

OUTSTANDING WINDOW (ownd) — окно оставшегося

Число байтов, которые были переданы отправителем, но для них ещё нет сведений о приёме получателем или потере в сети.

INITIAL WINDOW (IW) — начальное окно

Размер окна перегрузки у отправителя в начале макропотока.

DATA TYPE SYNTAX — синтаксис типа данных

Используется обозначение u64 для 64-битовых чисел без знака, u32 для 32-битовых чисел без знака, u16 для 16-битовых чисел без знака, u8 для 8-битовых чисел без знака, i32 для 32-битовых чисел со знаком, i16 для 16-битовых чисел со знаком и float для значений IEEE с плавающей точкой. Тип void указывает, что от вызова не ожидается возврата значения. Для указателей применяется обозначение * в соответствии с синтаксисом языка C.

Следует подчеркнуть, что все описанные в документе функции API являются «абстрактными» вызовами и соответствующие CM реализации могут отличаться в деталях.

2. Введение

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

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

Системы могут использовать CM и в этом случае они должны следовать данной спецификации.

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

1. Приложения ведут себя корректно, имеют свою независимую нумерацию байтов и пакетов и применяют CM API для обновления внутреннего состояния в CM.

2. Сети работают по принципу best-effort без дискриминации и резервирования. В частности, не рассматриваются ситуации, где разные потоки между одной парой проходят по путям с разными характеристиками.

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

1. Эффективное мультиплексирование. В Internet все чаще возникают ситуации, когда отправители индивидуальных (unicast) данных (например, Web-серверы) передают получателям разнотипные данные — от доставки потокового содержимого без гарантий в реальном масштабе времени до гарантированной доставки Web-страниц и приложений (applet). В результате множество логически различающихся потоков проходят по одному пути между отправителем и получателем. Для сохранения стабильности Internet каждый из таких потоков должен включать протоколы управления, безопасно проверяющие наличие свободной пропускной способности и реагирующие на перегрузку. К сожалению эти одновременные потоки обычно конкурируют в части доступа к ресурсам сети вместо их эффективного совместного использования. Кроме того, они не узнают один от другого состояния сети. Даже при реализации в каждом потоке независимого контроля перегрузки (например, в группе соединений TCP, реализующих алгоритмы [Jacobson88, Allman99]), совокупность потоков обычно будет более агрессивной при перегрузке, нежели одно соединение TCP со стандартным для TCP контролем и предотвращением перегрузок [Balakrishnan98].

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

Модель CM основана на недавних работах по совместному использованию блока управления TCP [Touch97], интегрированному контролю перегрузок в TCP (TCP-Int) [Balakrishnan98] и сессиям TCP [Padmanabhan98]. В [Touch97] отстаивается идея совместного использования состояния в блоке управления TCP для краткосрочного повышения производительности транспорта и описано совместное использование блока группой соединений TCP. В работах [Balakrishnan98], [Padmanabhan98], [Eggert00] описано несколько экспериментов по количественной оценке преимуществ совместного использования сведений о перегрузке, включая повышение стабильности при перегрузке и лучшее восстановление потерь. Интеграция восстановления потерь в одновременных соединениях существенно повышает производительность, поскольку потери в соединении можно обнаружить по получению и подтверждению более поздних данных в другом соединении. Модель CM расширяет эти идеи двумя важными способами: (i) контроль перегрузок в потоках, не относящихся к TCP, которые получают все большее распространение и зачастую не включают должного контроля перегрузок, и (ii) наличие API для приложений, позволяющего адаптировать их передачи к текущим условиям в сети. Расширенное обсуждение мотивов разработки и архитектуры CM, API и алгоритмов приведено в работе [Balakrishnan99], а описание реализации и влияния на производительность — в [Andersen00].

Разработанная архитектура протокола на конечном узле показана на рисунке 1. CM помогает обеспечить стабильность сети, реализуя стабильные алгоритмы предотвращения и контроля перегрузок, которые дружественны к TCP [Mahdavi98], на основе алгоритмов, описанных в [Allman99]. Однако в модели не предпринимается попыток обеспечить корректное поведение при перегрузке всех приложений (но не исключается наличие средств применения правил на хосте, выполняющем эту задачу). Хотя применение правил на конечном хосте может включать использование CM, сеть должна быть защищена от компрометации CM и средств применения правил на конечном хосте, а для этого требуется оборудования маршрутизатора [Floyd99a]. В данном документе этот вопрос не рассматривается.

Ключевыми компонентами модели CM являются (i) API, (ii) контроллер перегрузок и (iii) планировщик. Включение API (частично) обусловлено требованиями кадрирования на прикладном уровне (application-level framing или ALF) [Clark90], как описано в разделе 3. CM (раздел 4) включает контроллер перегрузок (параграф 4.1) и планировщик для организации передачи данных одновременных потоков в одном макропотоке (параграф 4.2). Контроллер перегрузок регулирует суммарную скорость передачи от отправителя к получателю на основе оценки перегрузок в сети, получая обратную связь о предшествующих передачах от самих приложений через API. Планировщик распределяет доступную пропускную способность между потоками в каждом макропотоке и уведомляет приложения о возможности передачи данных. В этом документе рассматриваются приложения с корректным поведением, а в будущем будет описан протокол и форматы заголовков для работы с приложениями, не обеспечивающими обратной связи с CM.

|--------| |--------| |--------| |--------|       |--------------|
|  HTTP  | |  FTP   | |  RTP 1 | |  RTP 2 |       |              |
|--------| |--------| |--------| |--------|       |              |
    |          |         |  ^       |  ^          |              |
    |          |         |  |       |  |          |  Планировщик |
    |          |         |  |       |  |  |---|   |              |
    |          |         |  |-------|--+->|   |   |              |
    |          |         |          |     |   |<--|              |
    v          v         v          v     |   |   |--------------|
|--------| |--------|  |-------------|    |   |           ^
|  TCP 1 | |  TCP 2 |  |    UDP 1    |    | A |           |
|--------| |--------|  |-------------|    |   |           |
   ^   |      ^   |              |        |   |   |--------------|
   |   |      |   |              |        | P |-->|              |
   |   |      |   |              |        |   |   |              |
   |---|------+---|--------------|------->|   |   |  Контроллер  |
       |          |              |        | I |   |              |
       v          v              v        |   |   |  перегрузки  |
  |-----------------------------------|   |   |   |              |
  |               IP                  |-->|   |   |              |
  |-----------------------------------|   |   |   |--------------|
                                          |---|

Рисунок .

3. CM API

По традиции IETF не рассматривает интерфейсы прикладных программ (Application Programming Interface или API) как стандарты. Однако считается важным собрать требования к CM API и алгоритму CM в одном согласованном документе. В последующих параграфах, посвящённых CM API, используются термины должно, следует и т. п., но эти термины применяются в контексте CM API. Раздел не относится к реализациям контроля перегрузок в целом и связан лишь с реализациями, предоставляющими CM API.

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

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

При создании приложением нового потока некоторая информация передаётся в CM через вызов cm_open(stream_info). В настоящее время stream_info включает (i) IP-адрес источника, (ii) порт источника, (iii) IP-адрес получателя, (iv) порт получателя и (v) номер протокола IP.

3.1 Поддержка состояний

Open

Все приложения перед использованием CM API должны вызывать функцию cm_open(stream_info), которая возвращает дескриптор cm_streamid, используемый приложением при всех последующих вызовах CM API для этого потока. Возврат cm_streamid = -1 говорит об отказе cm_open() и невозможности использовать CM.

Во всех последующих вызовах CM для потока используется значение cm_streamid, возвращённое cm_open().

Close

При завершением потока приложению следует вызывать функцию cm_close(cm_streamid) для информирования CM о завершении потока.

Размер пакетов

Вызов cm_mtu(cm_streamid) возвращает значение PMTU на пути между отправителем и получателем. Внутри эти сведения следует получать через определение MTU для пути [Mogul90]. Значение можно задать статически при отсутствии механизма для его определения.

3.2 Передача данных

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

1. Передача на основе обратного вызова (callback). API для такой передачи предоставляет потоку самостоятельно выбирать, что передавать в данный момент. Для этого CM не буферизует данных, а предоставляет потоку возможность адаптироваться к неожиданным изменениям в сети в последний момент. Это позволяет потоку «выталкивать» и перепаковывать данные, узнав о любом изменении скорости, что было бы сложно сделать при буферизации данных. В CM должен быть реализован вызов cm_request(i32 cm_streamid) для потоков, желающих передавать данные таким способом. Через некоторое время, в зависимости от скорости, CM должен выполнить обратный вызов с помощью cmapp_send(), что позволяет потоку передать до PMTU байтов. API с обратными вызовами рекомендуется для потоков на основе ALF. Следует отметить, что cm_request() не принимает в качестве аргумента числа байтов или блоков размером MTU, каждый вызов cm_request() является неявным запросом на отправку до PMTU байтов. CM может предоставлять дополнительный интерфейс cm_request(int k). Обратный вызов cmapp_send для такого запроса даёт право на передачу до k сегментов размером PMTU. В параграфе 3.3 рассматривается продолжительность действия такого права, а в параграфе 4.2 описано планирование запросов и выполнение обратных вызовов.

2. Синхронная передача. Упомянутый выше API на основе обратных вызовов позволяет использовать класс потоков ALF, являющихся «асинхронными». Асинхронный отправитель не передаёт данные периодически на основе часов, а делает это по событиям, таким как чтение файла или получение кадров. Существует много потков, являющихся «синхронными» отправителями и передающих данные по своим внутренним таймерам (например, отправители звукового потока с постоянной скоростью выборки). Хотя обратные вызовы CM можно настроить на периодические прерывания для таких передатчиков, цикл передачи таких приложений меньше пострадает при использовании своей периодичности на основе внутренних таймеров. Кроме того, выражение потоком периодичности и гранулярности обратных вызовов усложнит CM API. Поэтому CM должен экспортировать интерфейс API, позволяющий информировать потоки об изменении скорости с помощью обратного вызова cmapp_update(u64 newrate, u32 srtt, u32 rttdev), где newrate указывает новую скорость (бит/сек), srtt — текущее сглаженное время кругового обхода (мксек), rttdev — сглаженное линейное отклонение при оценке времени кругового обхода, рассчитанное по алгоритму TCP [Paxson00]. Значение newrate сообщает рассчитанную мгновенную скорость, например, по отношению cwnd к srtt, поделённому на долю пропускной способности, выделенную потоку.

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

   Во избежание ненужных обратных вызовов cmapp_update(), которые приложение просто будет игнорировать, CM должен поддерживать функцию cm_thresh(float rate_downthresh, float rate_upthresh, float rtt_downthresh, float rtt_upthresh), которую поток может использовать на любом этапе своего существования. В ответ диспетчеру CM следует использовать обратный вызов только при снижении скорости не менее, чем в (rate_downthresh * lastrate) раз или росте более, чем в (rate_upthresh * lastrate) раз, где lastrate — последняя скорость, сообщённая потоку, или при изменении времени кругового обхода в соответствии с заданными предварительно порогами. Эти сведения служат рекомендациями CM в части вызова cmapp_update() даже при невыполнении указанных условий.

В CM должна быть реализована функция cm_query(i32 cm_streamid, u64* rate, u32* srtt, u32* rttdev), позволяющая приложению запросить текущее состояние CM. При этом параметр rate указывает текущую оценку скорости (бит/сек), srtt — текущую сглаженную оценку времени кругового обхода (мксек), а rttdev — среднее линейное отклонение. Если у CM нет действительных оценок для макропотока, в параметрах rate, srtt, rttdev указываются отрицательные значения.

Отметим, что поток может использовать одновременно оба указанных выше API передачи. В частности, знание установившейся скорости полезно как для асинхронных потоков, так и для синхронных. Например, асинхронный Web-сервер, распространяющий изображения по протоколу TCP, может использовать cmapp_send() для планирования передачи и cmapp_update() для решения вопроса о выдаче изображений с высоким или низким разрешением. Описанная в параграфе 5.1.1 реализация TCP с использованием CM показывает преимущество API обратного вызова cm_request() для TCP.

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

3.3 Уведомления от приложений

При получении потоком обратной связи от приёмников он должен вызвать функцию cm_update(i32 cm_streamid, u32 nrecd, u32 nlost, u8 lossmode, i32 rtt) для передачи CM таких сведений, как потери из-за перегрузки, успешный приём, тип потерь (там-аут, ECN¹ [Ramakrishnan99] и т. п.) и выборки времени кругового обхода. Параметр nrecd указывает число успешно полученных приёмником байтов с момента последнего вызова cm_update call, а nlost² — число потерянных за тот же интервал времени байтов. Значение rtt указывает время кругового обхода измеренное в процессе передачи указанных байтов. При отсутствии у приложения действительной выборки rtt следует указывать rtt = -1. Параметр lossmode указывает способ обнаружения потерь и должен указываться вектором битов, соответствующих CM_NO_FEEDBACK, CM_LOSS_FEEDBACK, CM_EXPLICIT_CONGESTION и CM_NO_CONGESTION. CM_NO_FEEDBACK говорит, что приложение не получило обратной связи от приёмника для остающихся данных и сообщает об этом CM. Например, при возникновании тайм-аута TCP это значение уведомит об этом CM. CM_LOSS_FEEDBACK указывает, что приложение столкнулось с потерями, которые, на его взгляд, связаны с перегрузкой но потеряны были не все остающиеся данные. Например, потеря сегмента TCP, обнаруженная по дубликату (селективного) подтверждения или иным методом, относится к этой категории. CM_EXPLICIT_CONGESTION указывает, что получатель отразил (echo) явное уведомление о перегрузке. CM_NO_CONGESTION говорит об отсутствии связанных с перегрузкой потерь. Отметим, что при потерях, не связанных с перегрузкой на других каналах (путях) приложению следует информировать CM о потерях установкой бита CM_NO_CONGESTION.

Функция cm_notify(i32 cm_streamid, u32 nsent) должна вызываться при передаче данных с хоста (например, в выходной процедуре IP) для информирования CM об отправке nsent байтов в данный поток. Это позволяет CM обновить свою оценку числа остающихся байтов для макропотока и потока.

Право cmapp_send(), предоставленное CM приложению, действительно лишь в течение времени, равного большему из значений интервала кругового обхода и зависящего от реализации порога, переданного как аргумент обратного вызова cmapp_send(). Приложению недопустимо передавать данные на основе вызова cmapp_send() по истечении этого времени. Если же приложение решит не передавать данных после этого вызова, ему следует вызвать cm_notify(stream_info, 0), чтобы позволить CM разрешать передачу данных другим потокам этого макропотока. Контроллер перегрузок CM должен быть устойчив к приложениям, забывающим корректно вызывать cm_notify(stream_info, 0), а также приложениям, завершающим работу аварийно или исчезающим после вызова cm_request().

3.4 Запросы

Если приложения хотят узнать доступную пропускную способность и время кругового обхода по потокам, они могут воспользоваться вызовом CM cm_query(i32 cm_streamid, i64* rate, i32* srtt, i32* rttdev), который возвращает нужные значения. Если у CM нет действительных оценок для макропотока, указываются отрицательные значения для rate, srtt и rttdev.

3.5 Гранулярность обобществления

Одним из решений, которые нужно принимать CM, является гранулярность организации макропотока — выбор потоков, включаемых в него и обобществляющих сведения о перегрузках. API предоставляет две функции, позволяющие приложениям решить, какие потоки следует включать в один макропоток. Функция cm_getmacroflow(i32 cm_streamid) возвращает уникальный идентификатор макропотока (i32), а cm_setmacroflow(i32 cm_macroflowid, i32 cm_streamid) относит поток cm_streamid к макропотоку cm_macroflowid. Если при вызове cm_setmacroflow() передано значение cm_macroflowid = -1, создаётся новый макропоток, идентификатор которого возвращается вызывающей стороне. Каждый вызов cm_setmacroflow() переопределяет для потока макропоток, к которому он относится (при наличии).

По умолчанию предполагается агрегирование по IP-адресу получателя, т. е. все потоки на один адрес агрегируются в один макропоток. В некоторых случаях такое агрегирование будет неоптимально даже в сетях best-effort. Например, если группа получателей находится за шлюзом NAT, отправитель будет видеть для всех один адрес получателя. Если эти узлы за NAT фактически подключены через разные узкие места (bottleneck), работа некоторых из них может ухудшиться в результате. Такие узлы можно обнаружить путём оценки задержки и потерь, но конкретные механизмы такой оценки выходят за рамки этого документа. Вызовы cm_getmacroflow() и cm_setmacroflow() позволяют изменить принятое по умолчанию поведение.

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

4. Устройство CM

В этом разделе описываются внутренние компоненты CM — контроллер перегрузок (Congestion Controller) и планировщик (Scheduler) с чётко определёнными абстрактными интерфейсами, которые они экспортируют.

4.1 Контроллер перегрузок

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

Контроллер перегрузок должен реализовать дружественный к TCP (TCP-friendly) [Mahdavi98] алгоритм контроля перегрузок. Несколько макропотоков могут (зачастую, будут) использовать один алгоритм контроля перегрузок, но каждый макропоток поддерживает своё состояние для сети, используемой его потоками.

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

void query(u64 *rate, u32 *srtt, u32 *rttdev)

Возвращает оценку скорости (бит/сек) и сглаженное время кругового обхода (мксек) для макропотока.

void notify(u32 nsent)

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

void update(u32 nsent, u32 nrecd, u32 rtt, u32 lossmode)

Эта функция вызывается всякий раз, когда любой из потоков CM, связанных с макропотоком, видит, что данные были получены приёмником или потеряны в пути. Параметр nrecd указывает число байтов, достигших получателя, nsent — сумму числа пришедших к получателю и потерянных в сети байтов, rtt указывает оценку времени кругового обхода (мксек) в процессе передачи, а lossmode служит индикатором способа обнаружения потерь (параграф 3.3).

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

4.2 Планировщик

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

void schedule(u32 num_bytes)

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

float query_share(i32 cm_streamid)

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

void notify(i32 cm_streamid, u32 nsent)

Служит для уведомления модуля планирования о каждой отправке данных приложением CM. Параметр nsent указывает число переданных приложением байтов.

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

5. Примеры

5.1 Примеры приложений

В этом разделе описаны три возможных варианта примерения CM API приложениями — два асинхронных (отправитель TCP и сокеты UDP с контролем перегрузки) и одно синхронное (потоковых звуковой сервер). Более подробно эти приложения, а также оптимизация реализаций CM для эффективной работы описаны в [Andersen00].

Все приложения, использующие CM, должны обеспечивать отклики от получателя. Например, источник должен периодически (обычно 1 или 2 раза за интервал кругового обхода) определять, сколько его пакетов прибыло к получателю. Когда источник получает такую обратную связь, он должен вызывать функцию cm_update() для передачи CM новых сведений. Это ведёт к обновлению диспетчером CM значения ownd и может приводить к смене CM своих оценок и вызову cmapp_update() для потоков макропотока.

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

5.1.1 TCP

Реализации TCP с поддержкой CM следует использовать функцию cmapp_send() API обратных вызовов. TCP определяет, какие данные следует передать, лишь после получения подтверждения или завершения отсчёта таймера. Нужен жёсткий контроль над передачей новых данных и повтором передачи.

Когда TCP подключается к удалённому хосту или принимает соединение, выполняется вызов cm_open() для привязки соединения TCP к cm_streamid. После организации соединения CM используется для контроля передачи исходящих данных. CM избавляет от необходимости отслеживания и реагирования на перегрузку в TCP, поскольку CM и его API передачи обеспечивают корректное поведение при перегрузке. Восстановлением потерь по-прежнему занимается TCP на основе ускоренного повтора передачи, восстановления и тайм-аутов. Кроме того, в TCP вносятся изменения для сасооценки окна остающихся данных (tcp_ownd). При каждой передаче сегментов данных путём вызова cmapp_send() TCP обновляет значение tcp_ownd. Переменная ownd обновляется также после каждого вызова cm_update(). TCP также подсчитывает число остающихся сегментов (pkt_cnt). В любой момент TCP может рассчитать средний размер пакета (avg_pkt_size) как tcp_ownd/pkt_cnt. Значение avg_pkt_size используется в TCP при оценке объёма оставшихся данных. Отметим, что это не требуется при использовании в соединении опции SACK, поскольку сведения доступны явно.

Изменения в выходных процедурах TCP указаны ниже.

1. Исключаются все проверки окна перегрузки (cwnd).

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

3. Если по входящим данным или таймерам фиксируеются потери, данные для повторной передачи помещаются в очередь и вызывается функция cm_request() для потока.

4. В выходной процедуре TCP устанавливается обратный вызов cmapp_send(). При наличии в очереди данных для повторной передачи выполняется повтор отправки, иначе процедура вывода отправляет новые данные в объёме, разрешенном для соединения. Функция cmapp_send() никогда не передаёт более одного сегмента на вызов. Эта процедура организует другие расчёты для вывода, такие как создание заголовка и опций.

Выходная процедура IP на хосте вызывает cm_notify(), когда пакеты фактически переданы наружу. Поскольку она не знает cm_streamid для пакета, он указывается аргументом stream_info (содержимое stream_info указано в разделе 3). Поскольку cm_notify() сооьщает размер данных IP (payload), TCP отслеживает общий размер заголовка и учитывает эти обновления.

Изменения во входных процедурах TCP указаны ниже.

1. Оценка RTT выполняется как обычно по временным меткам или алгоритму Karn. Значение rtt передаётся CM через вызов cm_update.

2. Все обновления cwnd порога замедленного старта (ssthresh) исключаются.

3. При поступлении подтверждения для новых данных TCP рассчитывает значение in_flight (размер находящихся в сети данных) как snd_max-ack-1 (MAX Sequence Sent — Current Ack — 1), после чего вызывает cm_update(streamid, tcp_ownd — in_flight, 0, CM_NO_CONGESTION, rtt).

4. При получении дубликата подтверждения TCP проверяет свой счётчик дубликатов (dup_acks) для определения действия. Если dup_acks < 3, TCP не делает ничего. При dup_acks == 3 предполагается, что пакет был потерян и генерации дубликата потверждения вызвана прибытием не менее 3 пакетов. Поэтому вызывается функция cm_update(streamid, 4 * avg_pkt_size, 3 * avg_pkt_size, CM_LOSS_FEEDBACK, rtt). Средний размер пакета используется потому, что подтверждения не указывают точно размер прибывших к получателю данных. Большинство реализаций TCP считают дубликат ACK индикацией прибытия к получателю полного MSS. После приёма нового ACK такие реализации отправителя TCP могут повторить синхронизацию с получателем TCP. CM API не предоставляет TCP механизма передачи сведений о ресинхронизации, поэтому TCP может лишь сделать вывод о поступлении avg_pkt_size данных из приёма каждого дубликата подтверждения. TCP помещает потерянный сегмент в очередь повторной передачи и вызывает cm_request(). При dup_acks > 3 TCP предполагает, что пакет прибыл к получателю и вызвал отправку подтверждения. В результате вызывается функция cm_update(streamid, avg_pkt_size, avg_pkt_size, CM_NO_CONGESTION, rtt).

5. При получении частичного подтверждения (не превышающего наибольший сегмент переданный на момент потери, как указано в [Floyd99b]) TCP считает, что пакет был потерян, а переданный повторно пакет пришел к получателю. Поэтому вызывается функция calls cm_update(streamid, 2 * avg_pkt_size, avg_pkt_size, CM_NO_CONGESTION, rtt). Использование CM_NO_CONGESTION обусловлено тем, что период потерь уже указан. Потерянный сегмент помещается в очередь повторной передачи и вызывается функция cm_request().

По завершении отсчёта таймера повторной передачи TCP отправитель считает, что пакет был потерян и вызывает функцию cm_update(streamid, avg_pkt_size, 0, CM_NO_FEEDBACK, 0) для обозначения отсутствия отклика получателя и «ухода одного сегмента из трубы». Потерянный сегмент сегмент помещается в очередь повторной передачи и вызывается функция cm_request().

5.1.2 UDP с контролем перегрузок

UDP с контролем перегрузки — это полезное применение CM, описываемое здесь в контексте сокетов Berkeley [Stevens94]. Они обеспечивают функциональность стандартных сокетов Berkeley UDP, но вместо незамедлительной передачи пакетов из очереди ядра нижележащим уровням для отправки реализация буферизованного сокета вызывает функцию API, экспортируемую CM внутри ядра и получает обратный вызов от CM. При создании сокета CM UDP он связывается с определенным потоком, а позднее при добавлении данных в очередь пакетов вызывается функция cm_request() для связанного с сокетом потока. При планировании CM передачи в этом потоке вызывается функция udp_ccappsend() в модуле UDP, которая передаёт из очереди пакетов MTU данных и планирует передачу любых остающихся в очереди пакетов. Реализации CM UDP API не следует требовать дополнительных копий данных и следует поддерживать все стандартные опции UDP. Изменение имеющихся приложений для использования UDP с контролем перегрузок требует реализации новой опции сокетов. Для корректной работы отправитель должен получать сведения о перегрузке. Это можно сделать двумя путями — (i) отклики от принимающего приложения UDP с обратной связью для отправителя или (ii) обратная связи от приёмного модуля UDP к отправителю UDP. Отметим, что второй вариант требует изменений в сетевом стеке получателя, а отправитель UDP не может узнать о поддержке этого без явного согласования.

5.1.3 Звуковой сервер

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

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

5.2 Пример модуля контроля перегрузок

Для иллюстрации обязанностей модуля контроля перегрузок ниже описаны некоторые действия простого модуля контроля перегрузок в стиле TCP, реализующего аддитивное увеличение и мультипликатовной снижение (Additive Increase Multiplicative Decrease congestion control или AIMD_CC):

query()

AIMD_CC возвращает текущее окно перегрузки (cwnd), делённое на сглаженное значение rtt (srtt) в качестве оценки пропускной способности. Сглаженная оценка rtt возвращается как srtt.

notify()

AIMD_CC добавляет число переданных байтов к окну остающихся данных (ownd).

update()

AIMD_CC вычитает nsent из ownd. Если значение rtt отлично от 0, AIMD_CC обновляет srtt, используя расчёт TCP srtt. Если обновление говорит о потере данных, AIMD_CC устанавливает для cwnd значение 1 MTU при loss_mode = CM_NO_FEEDBACK и cwnd/2 (не менее 1 MTU) при loss_mode = CM_LOSS_FEEDBACK или CM_EXPLICIT_CONGESTION. AIMD_CC также устанавливает для внутренней переменной ssthresh значение cwnd/2. Если потерь не возникает, AIMD_CC имитирует замедленный старт TCP и линейный рост. Значение cwnd увеличивается на nsent, когда cwnd < ssthresh (ограничено максимум ssthresh-cwnd) и на nsent * MTU/cwnd при cwnd > ssthresh.

Когда cwnd и ownd обновляются и указывают возможность передачи по меньшей мере MTU данных, AIMD_CC вызывает CM для планирования передачи.

5.3 Пример модуля планировщика

Для пояснения обязанностей планировщика ниже описаны некоторые действия простого модуля планирования с круговым обходом (round robin scheduler, RR_sched).

schedule()

RR_sched планирует число потоков, с которыми можно работать в режиме перебора по кругу.

query_share()

RR_sched возвращает значение 1/(число потоков в макропотоке).

notify()

RR_sched не делает ничего. На планирование с перебором по кругу не влияет размер переданных данных.

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

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

В [Touch97] рассмотрен ряд проблем безопасности, возникающих при обобществлении сведений о перегрузках. Дополнительная уязвимость, не отмеченная в [Touch97], возникает из-за доступа приложений через CM API к управлению общим состоянием перегрузки, влияющему на другие приложения на том же компьютере. Например, плохо спроектированное, скомпрометированное или вредоносное приложение UDP может злоупотреблять вызовом cm_update() для создания препятствий другим потокам макропотока.

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

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

[Andersen00] Balakrishnan, H., System Support for Bandwidth Management and Content Adaptation in Internet Applications, Proc. 4th Symp. on Operating Systems Design and Implementation, San Diego, CA, October 2000. Available from http://nms.lcs.mit.edu/papers/cm-osdi2000.html³

[Balakrishnan98] Balakrishnan, H., Padmanabhan, V., Seshan, S., Stemm, M., and Katz, R., «TCP Behavior of a Busy Web Server: Analysis and Improvements,» Proc. IEEE INFOCOM, San Francisco, CA, March 1998.

[Balakrishnan99] Balakrishnan, H., Rahul, H., and Seshan, S., «An Integrated Congestion Management Architecture for Internet Hosts,» Proc. ACM SIGCOMM, Cambridge, MA, September 1999.

[Bradner96] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, October 1996.

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

[Clark90] Clark, D. and Tennenhouse, D., «Architectural Consideration for a New Generation of Protocols», Proc. ACM SIGCOMM, Philadelphia, PA, September 1990.

[Eggert00] Eggert, L., Heidemann, J., and Touch, J., «Effects of Ensemble TCP,» ACM Computer Comm. Review, January 2000.

[Floyd99a] Floyd, S. and Fall, K.,» Promoting the Use of End-to-End Congestion Control in the Internet,» IEEE/ACM Trans. on Networking, 7(4), August 1999, pp. 458-472.

[Floyd99b] Floyd, S. and T. Henderson,»The New Reno Modification to TCP’s Fast Recovery Algorithm,» RFC 2582, April 1999.

[Jacobson88] Jacobson, V., «Congestion Avoidance and Control,» Proc. ACM SIGCOMM, Stanford, CA, August 1988.

[Mahdavi98] Mahdavi, J. and Floyd, S., «The TCP Friendly Website,» http://www.psc.edu/networking/tcp_friendly.html

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

[Padmanabhan98] Padmanabhan, V., «Addressing the Challenges of Web Data Transport,» PhD thesis, Univ. of California, Berkeley, December 1998.

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

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

[Ramakrishnan99] Ramakrishnan, K. and Floyd, S., «A Proposal to Add Explicit Congestion Notification (ECN) to IP,» RFC 2481, January 1999.

[Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1. Addison-Wesley, Reading, MA, 1994.

[Touch97] Touch, J., «TCP Control Block Interdependence», RFC 2140, April 1997.

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

Спасибо David Andersen, Deepak Bansal и Dorothy Curtis за их работу по проектированию и реализации CM. Спасибо Vern Paxson за подробные комментарии, отклики и терпение, а также Sally Floyd, Mark Handley, Steven McCanne за полезные отклики по архитектуре CM. Allison Mankin и Joe Touch предоставили ценные замечания к черновым вариантам документа.

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

Hari Balakrishnan

Laboratory for Computer Science

200 Technology Square

Massachusetts Institute of Technology

Cambridge, MA 02139

EMail: hari@lcs.mit.edu

Web: http://nms.lcs.mit.edu/~hari/

Srinivasan Seshan

School of Computer Science

Carnegie Mellon University

5000 Forbes Ave.

Pittsburgh, PA 15213

EMail: srini@cmu.edu

Web: http://www.cs.cmu.edu/~srini/

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

Copyright (C) The Internet Society (2001). Все права защищены.

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

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

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

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

Финансирование функций RFC Editor обеспечено Internet Society.

---

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

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

nmalykh@protokols.ru

---

Network Working Group                                           A. Conta
Request for Comments: 3122                        Transwitch Corporation
Category: Standards Track                                      June 2001

Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification

Расширения IPv6 ND для реверсного обнаружения

PDF

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

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

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

Copyright (C) The Internet Society (2001). Все права защищены.

Аннотация

Этот документ описывает расширение IPv6 Neighbor Discovery, позволяющее узлу определить и анонсировать адрес IPv6, соответствующий данному адресу канального уровня. Эти расширения названы реверсным обнаружением соседей (Inverse Neighbor Discovery или IND). Протокол IND был разработан для сетей Frame Relay, но может применяться в других сетях с походим поведением.

1. Введение

Этот документ определяет расширение протокола обнаружения соседей IPv6 (Neighbor Discovery или ND) [IPv6-IND], названное реверсным обнаружением соседей IPv6 (Inverse Neighbor Discovery или IND). IND позволяет узлу по адресу канального уровня подключённого напрямую узла узнать его адрес IPv6. Узел, применяющий IND, передаёт запросы и получает анонсы для одного или нескольких адресов IPv6, соответствующих заданному адресу канального уровня.

Протокол IND разработан для сетей Frame Relay, но применим и в других сетях с похожим поведением.

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

Имеется много сходств и различий между описанными здесь механизмами и механизмами протокола Inverse ARP для IPv4 [INV-ARP] или заменяющих его документах.

2. Сообщения IND

2.1. IND Solicitation

Узел передаёт сообщение IND Solicitation для запроса адреса IPv6, соответствующего адресу канального уровня целевого узла, а также для указания тому своего адреса на канальном уровне. Поскольку адрес IPv6 удалённого узла неизвестен, IND Solicitation передаётся по групповому адресу IPv6 all-nodes [IPv6], [IPv6-FR], [ENCAPS], однако на канальном уровне IND Solicitation передаётся целевому узлу напрямую по адресу канального уровня.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

Поля IP

Source Address

Адрес IPv6 передающего сообщение интерфейса.

Destination Address

Групповой адрес IPv6 all-nodes, указываемый со областью действия на канале, т. е. FF02::1.

Hop Limit

255

Authentication Header

При наличии защищённой связи (Security Association или SA) для IP AH между отправителем и получателем отправителю следует включать этот заголовок.

Поля ICMP

Type

141

Code

0

Checksum

Контрольная сумма ICMP, см. [ICMPv6].

Reserved

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

Требуемые опции

Отправитель должен указать приведённые ниже опции в сообщении Solicitation.

Source Link-Layer Address

Адрес отправителя на канальном уровне.

Target Link-Layer Address

Адрес целевого узла на канальном уровне.

Другие действительные опции

Отправитель может указать в сообщении Solicitation перечисленные ниже опции.

Source Address List

Список из одного или нескольких адресов IPv6 для интерфейса, указанного полем Source Link-Layer Address. Опция определена в разделе 3.

MTU

Настроенное для канала значение MTU [IPv6-ND].

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

2.2. IND Advertisement

Узел передаёт анонсы IND Advertisement в ответ на запрос IND Solicitation.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

Поля IP

Source Address

Адрес IPv6 передающего сообщение интерфейса.

Destination Address

Значение Source Address из вызвавшего отклик сообщения IDN Solicitation.

Hop Limit

255

Authentication Header

При наличии защищённой связи (Security Association или SA) для IP AH между отправителем и получателем отправителю следует включать этот заголовок.

Поля ICMP

Type

142

Code

0

Checksum

Контрольная сумма ICMP, см. [ICMPv6].

Reserved

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

Требуемые опции

Отправитель должен указать приведённые ниже опции в сообщении Advertisement.

Source Link-Layer Address

Адрес отправителя IND Advertisement на канальном уровне.

Target Link-Layer Address

Адрес на канальном уровне узла, который который передал запрос IND Solicitation.

Target Address List

Список из одного или нескольких адресов IPv6 для интерфейса, указанного полем Target Link-Layer Address в сообщении IND Solicitation, вызвавшем анонс. Опция определена в разделе 3.

Другие действительные опции

Отправитель может указать в сообщении Advertisement указанную ниже опцию.

MTU

Настроенное для канала значение MTU [IPv6-ND].

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

3. Формат опций IND

Сообщения IND включают опции ND [IPv6-ND], а также свои опции Source Address List и Target Address List.

3.1 Списки адресов

Опции Source Address List и Target Address List используют формат TLV (тип, размер, значение, см. параграф 4.6 в [IPv6-ND] с показанными на рисунке полями.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      -       -       -        +
|                          Reserved                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                        IPv6 Address                           +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                        IPv6 Address                           +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~
|
+-+-+-+-+...

Type

9 для Source Address List;

10 для Target Address List.

Примечание. Значения Option Type следует назначать из семейства IPv6 ND.

Length

Размер опции (включая поля Type, Length, Reserved) в 8-октетных блоках. Минимальное значение Length составляет 3 (один адрес IPv6).

Reserved

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

IPv6 Addresses

Один или несколько адресов IPv6 для интерфейса.

Source Address List содержит список адресов IPv6 для интерфейса, указанного полем Source Link-Layer Address, Target Address List — для интерфейса, указанного Target Link-Layer Address. Число адресов в списке (n) определяется по размеру опции как

      n = (Length - 1)/2

Поле Source Address List должно помещаться в одно сообщение IND Solicitation, поэтому список может быть неполным. Для полного списка адресов IPv6 узлу следует полагаться на сообщение IND Advertisement.

В поле Target Address List следует указывать полный список адресов интерфейса, указанного полем Target Link-Layer Address. Если список не помещается в одно сообщение IND Advertisement, после него следует передать ещё 1 или несколько анонсов IND Advertisement с теми же полями. В опцию Target Address List второго и последующих анонсов следует включать продолжение списка адресов IPv6 для интерфейса, указанного Target Link-Layer Address, которые не поместились в предыдущий анонс.

Примечание 1. Действие механизма IND ограничено обнаружением адресов IPv6, т. е. предоставлением сведений о сопоставлении адресов. Поэтому протокол не содержит положений и правил использования узлом адресов, возвращённых в сообщении IND. Более того, из списков протокол не исключает каких-либо типов адресов IPv6. Например, при наличии адресов, заданных вручную и автоматически, включая временные, индивидуальные, групповые и т. п., из списка не следует исключать ни одного адреса.

Примечание 2. Реализации недопустимо передавать в списке дубликаты адресов IPv6.

4. Протокол IND

Работа IND очень похожа на ND [IPv6-ND] — запрашивающий целевой адрес IP узел передаёт запрос через свой интерфейс, целевой узел отвечает анонсом с требуемыми сведениями. Полученная информация может быть сохранена в кэше ND [IPv6-ND] или адресных структурах IPv6, которые могут быть связаны с интерфейсом.

4.1. Обработка на передающем узле

Запрашивающий узел форматирует сообщение IND Solicitation, как указано в параграфе 2.1, инкапсулирует пакет для канального уровня и передаёт его напрямую целевому узлу. Хотя в качестве IP-адреса получателя указан групповой адрес all-nodes, сообщение передаётся лишь целевому узлу. Значимыми полями для протокола IND являются Source Address, Source Link-Layer Address, Target Link-Layer Address и MTU. Последнее поле может служить для установки оптимального значения MTU на канале.

В ожидании отклика отправителю следует повторять сообщение IND Solicitation с интервалом приблизительно RetransTimer (по завершении отсчёта) [IPv6-ND] даже при отсутствии другого трафика к соседу. Повторы должны ограничиваться по скорости — не более одного для соседа в каждом интервале RetransTimer.

Отсутствие ответа IND Advertisement после отправки MAX_MULTICAST_SOLICIT [IPv6-ND] запросов считается отказом. Если отправка Solicitation требовалась вышележащим уровнем, модуль отправителя должен уведомить вышележащий уровень об ошибке, используя подходящий механизм (например, код завершения процедуры).

4.2. Обработка на приёмном узле

4.2.1. Обработка IND Solicitation

Для каждого IND Solicitation принявшему запрос узлу следует создать подходящий отклик IND Advertisement, используя адреса отправителя и цели на канальном уровне, а также адрес отправителя IPv6 из IND Solicitation.

Если узел обновляет кэш ND с использованием сведений из сообщений IND, получателю IND Solicitation следует поместить адреса отправитель (IPv6 и канальный) в свой кэш ND [IPv6-ND] как для запросов ND.

Поскольку узлы IPv6 могут иметь несколько адресов IPv6 на интерфейсе, отвечающему на IND Solicitation узлу следует возвращать в опции Target Address List список адресов IPv6, соответствующих интерфейсу, указанному полем Target Link-Layer Address в запросе. Список должен не иметь дубликатов адресов.

4.2.2. Обработка IND Advertisement

Если узел обновляет кэш ND сведениями из сообщений IND, получателю IND Advertisement следует поместить адреса отправителя (IPv6 из опции Target Addresses List и канальный) из анонса IND Advertisement в свой кэш ND [IPv6-ND] как для анонсов ND.

4.3. Проверка сообщений

4.3.1. Проверка IND Solicitation

Узел должен отбрасывать без уведомления отправителя любые сообщения IND Solicitation, для которых не выполняются все приведённые ниже условия.

• Поле IP Hop Limit имеет значение 255, т. е. пакет не передавался через маршрутизаторы.

• При наличии заголовка IP AH аутентификация прошла успешно.

• Значение ICMP Checksum действительно.

• ICMP Code = 0.

• Размер ICMP (выводится из размера IP) не менее 24 октетов.

• Должна присутствовать обязательная опция Target Link-Layer Address.

• Должна присутствовать обязательная опция Source Link-Layer Address.

• Все включённые опции имеют размер больше 0.

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

Содержимое любых опций ND [IPv6-ND], которые не заданы для использования в IND Solicitation, должны игнорироваться с продолжением обычной обработки пакета. Кроме обязательных опций в сообщении может присутствовать лишь опция MTU.

Запрос IND Solicitation, прошедший проверку, называется действительным запросом (valid solicitation).

4.3.2. Проверка IND Advertisement

Узел должен отбрасывать без уведомления отправителя любые сообщения IND Advertisement, для которых не выполняются все приведённые ниже условия.

• Поле IP Hop Limit имеет значение 255, т. е. пакет не передавался через маршрутизаторы.

• При наличии заголовка IP AH аутентификация прошла успешно.

• Значение ICMP Checksum действительно.

• ICMP Code = 0.

• Размер ICMP (выводится из размера IP) не менее 48 октетов.

• Присутствует опция Source Link-Layer Address.

• Присутствует опция Target Link-Layer Address.

• Присутствует опция Target Address List.

• Размер опции Target Address List не менее 3.

• Все включённые опции имеют размер больше 0.

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

Содержимое любых опций ND [IPv6-ND], которые не заданы для использования в IND Solicitation, должны игнорироваться с продолжением обычной обработки пакета. Кроме обязательных опций в сообщении может присутствовать лишь опция MTU.

Анонс IND Advertisement, прошедший проверку, называется действительным анонсом (valid advertisement).

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

При использовании на виртуальных каналах «точка-точка», как в сетях Frame Relay, сообщения IND менее чувствительны к атакам с подменой со стороны узлов на канале, чем в случае широковещательных соединений.

Как и ND, протокол снижает раскрытие потоков для узлов вне канала в отсутствие аутентификации, игнорируя пакеты IND от размещённых вне канала отправителей. Поле Hop Limit во всех полученных пакетах имеет максимально допустимое значение 255. Поскольку маршрутизаторы декрементируют Hop Limit во всех пересылаемых пакетах, значение Hop Limit = 255 говорит о получении пакета от соседа.

Обмен пакетами протокола IND можно аутентифицировать с помощью IP AH [IPSEC-Auth]. Узлу следует включать заголовок AH при передаче пакетов IND, если имеется защищённая связь с адресатом для применения IP AH. Защищённую связь можно настроить вручную или с помощью того или иного протокола обмена ключами. Полученные в пакетах IND заголовки AH должны проверяться на корректность и при отказе пакеты должны отбрасываться.

При использовании с Frame Relay на приёмном узле после обработки IPSec должна выполняться специальная предварительная обработка Frame Relay для сообщений ND Solicitation с опцией Source Link-Layer Address, содержащей DLCI.

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

Вопросы конфиденциальности рассмотрены в документах IP Security Architecture и IP Encapsulating Security Payload [IPSEC], [IPSEC-ESP].

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

В IANA запрошено выделение двух новых типов ICMPv6, описанных в параграфах 2.1 и 2.2. Значения выбраны из числа информационных типов, как определено в параграфе 2.1 RFC 2463. Для этих типов не определены коды ICMPv6 (кроме 0), будущие назначения возможны по процедуре Standards Action, как указано в RFC 2434.

В IANA также запрошено выделение двух новых типов ICMPv6 Neighbor Discovery Option, как указано в параграфе 3.1. Внешнего обзора для них не потребовалось.

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

Спасибо Steve Deering, Thomas Narten, Erik Nordmark за обсуждение идеи IND, Thomas Narten, Erik Nordmark, а также Dan Harrington, Milan Merhar, Barbara Fox, Martin Mueller, Peter Tam за внимательное рецензирование.

Следует отметить, что часть текста спецификации заимствована из IPv6 Neighbor Discovery [IPv6-ND].

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

[IPv6] Deering, S. and R. Hinden, «Internet Protocol Version 6 Specification», RFC 2460¹, December 1998.

[IPv6-ND] Narten, T., Nordmark, E. and W. Simpson «Neighbor Discovery for IP Version 6 (IPv6)», RFC 2461², December 1998.

[ICMPv6] Conta, A., and S. Deering «Internet Control Message Protocol for the Internet Protocol Version 6», RFC 2463³, December 1998.

[IPv6-FR] Conta, A., Malis, A. and M. Mueller, «Transmission of IPv6 Packets over Frame Relay Networks», RFC 2590, May 1999. December 1997.

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

[IPSEC-Auth] Atkinson, R. and S. Kent, «IP Authentication Header», RFC 2402⁵, December 1998.

[IPSEC-ESP] Atkinson, R. and S. Kent, «IP Encapsulating Security Protocol (ESP)», RFC 2406⁶, November 1998.

[ASSIGN] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 1700⁷, March 1994.

[ENCAPS] Brown, C. and A. Malis, «Multiprotocol Interconnect over Frame Relay», RFC 2427, November 1998.

[INV-ARP] Bradley, T., Brown, C. and A. Malis «Inverse Address Resolution Protocol», RFC 2390, August 1998.

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

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

Alex Conta

Transwitch Corporation

3 Enterprise Drive

Shelton, CT 06484

Phone: +1-203-929-8810

EMail: aconta@txc.com

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

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

nmalykh@protokols.ru

Приложение A. IND в сетях Frame Relay

В этом приложении рассмотрены потребности применения IND в сетях Frame Relay, которые выходят за пределы базовых вопросов, рассмотренных в предыдущих параграфах.

A.1. Введение

Протокол IND применим к узлам Frame Relay. Постоянные (PVC) и коммутируемые (SVC) канала Frame Relay указываются идентификаторами DLCI (Data Link Connection Identifier). Каждый идентификатор DLCI определяет для узла Frame Relay одно виртуальное соединение через распределенную сеть (wide area network или WAN). Обычно DLCI имеют локальную значимость.

С помощью конкретных сигнальных сообщений сеть Frame Relay может анонсировать узлу новый виртуальный канал с соответствующим DLCI. Значение DLCI указывает узлу виртуальный канал и может служить эквивалентом адреса удалённого узла на канальном уровне, позволяя узлу идентифицировать канальный уровень на другой стороне виртуального канала. В примере на рисунке 1 узел A (локальный) указывает виртуальный канал к узлу B (удалённый) с помощью DLCI = 30. Однако сигнальное сообщение не содержит сведений о DLCI, используемом удаленным узлом для указания виртуального устройства локальному узлу, которое может служить эквивалентом адреса на канальном уровне. На рисунке 1 узел B (удалённый) может указать узлу A виртуальное устройство с помощью DLCI = 62.

                   ~~~~~~~~~~~                Удаленный
                  {           }               узел
+-----+ DLCI     {             }         DLCI+-----+
|  A  |-30------{--+----+----+--}---------62-|  B  |
+-----+          {             }             +-----+
Локальный         {           } Облако сети
узел               ~~~~~~~~~~~  Frame Relay

Рисунок 1.

Кроме того, передаваемое на канальном уровне сообщение не зависит от протокола IPv6 и не включает адресов IPv6. Протокол IND также позволяет узлу Frame Relay обнаруживать эквивалент локального адреса канального уровня, т. е. идентификатор, с помощью которого удалённый узел может указать его и, что более важно, определить адреса IPv6 на другой стороне виртуального канала, указанного удаленным адресом канального уровня.

Протокол IPv6 IND позволяет узлу Frame Relay динамически определять DLCI, по которому удалённый узел идентифицирует виртуальный канал, а также узнать адреса IPv6 узла на удалённой стороне виртуального канала.

A.2. Сообщения IND

A.2.1. IND Solicitation

Отправитель IND Solicitation не знает адрес IPv6 удалённого узла, но знает эквивалент его канального адреса. IND Solicitation передаются по групповому адресу IPv6 all-nodes [IPv6], [IPv6-FR], [ENCAPS], однако на канальном уровне сообщение передаётся целевому узлу напрямую по известному значению DLCI. Поля сообщения показаны ниже.

Source Link-Layer Address

Для передающего узла Frame Relay поле Source Link-Layer Address содержит эквивалент адреса канального уровня, по которому удалённый узел идентифицирует отправителя сообщения. Если отправителю известно это значение, его следует включить в поле, в противном случае поле следует оставить пустым. При наличии этой информации она может служить для отладки сети. Независимо от заполнения этого поля отправителем перед любой обработкой IND получатель сообщения заменяет это поле сведениями из заголовка Frame Relay (поле DLCI) в соответствии с форматом, заданным в [IPv6-FR].

Target Link-Layer Address

Передающий узел Frame Relay указывает в поле Target Link-Layer Address значение, эквивалентное адресу целевого узла на канальном уровне. Этим значением является DLCI виртуального канала VC к целевому узлу в формате, заданном [IPv6-FR].

Для иллюстрации создания сообщения IND Solicitation узлом Frame Relay рассмотрим узел A (рисунок 1), передающий IND Solicitation узлу B.

На узле A (отправитель IND Solicitation)

Source Link-Layer Address

DLCI=неизвестно (переписывается получателем).

Target Link-Layer Address

DLCI=30.

На узле B (получатель IND IND Solicitation)

Source Link-Layer Address

DLCI=62 (заполняется получателем).

Target Link-Layer Address

DLCI=30.

Примечание. Для Frame Relay приведённые выше адреса используют формат Q.922 (DLCI) с 10 (по умолчанию) или 23 значащими битами [IPv6-FR]. Размер опции (адрес канального уровня) указывается в 8-октетных блоках, поэтому DLCI извлекается из 8 байтов на основе поля EA (бит 0) второго, третьего и четвёртого октета (EA = 1). Поля C/R, FECN, BECN, DE в адресе Q.922 не имеют значения для IND и устанавливаются в 0 [IPv6-FR].

MTU

В опции MTU указывается значение MTU для виртуального канала, заданного известным DLCI [IPv6-FR].

A.2.2. IND Advertisement

Узел Frame Relay передаёт IND Advertisement в ответ на сообщение IND Solicitation. Поля сообщения указаны ниже.

Source Link-Layer Address

Для Frame Relay это поле копируется из поля Target Link-Layer Address в IND Solicitation в формате DLCI [IPv6-FR].

Target Link-Layer Address

Для Frame Relay это поле копируется из поля Source Link-Layer Address в IND Solicitation в формате DLCI [IPv6-FR].

Например, если узел B (рисунок 1) отвечает на IND Solicitation от узла A анонсом IND Advertisement, поля будут иметь вид, показанный ниже.

На узле B (отправитель анонса):

Source Link-Layer Address

DLCI=30 (Target в Solicitation).

Target Link-Layer Address

DLCI=62 (Source в Solicitation).

На узле A (получатель анонса от B).

Source Link-Layer Address

DLCI=30 (Target в Solicitation).

Target Link-Layer Address

DLCI=62 (Source в Solicitation).

Target Address List

Список адресов IPv6 на интерфейсе, указанном полем Target Link-Layer Address в IND Solicitation, вызвавшем анонс.

MTU

Значение MTU, заданное для канала (виртуального устройства) [IPv6-ND].

Примечание. В случае сетей Frame Relay сообщения IND передаются в виртуальный канал. При разрыве такого канала участники получают соответствующее сигнальное сообщения, которое распространяется на вышележащие уровни, включая IPv6.

A.3. Протокол IND

В этом параграфе описаны специфические для сетей Frame Relay аспекты IND.

A.3.1. Обработка на передающем узле

Запрашивающий узел Frame Relay форматирует сообщение IND Solicitation в соответствии с параграфом 2.1, инкапсулирует пакет для канального уровня Frame Relay [IPv6-FR] и передаёт его целевому узлу Frame Relay. Хотя IP-адресом получателя является групповой адрес IPv6 all-nodes, сообщение передаётся лишь целевому узлу Frame Relay, известному по виртуальному каналу.

A.3.2. Обработка на приёмном узле

A.3.2.1. Обработка сообщений IND Solicitation

Перед обработкой сообщения узел Frame Relay заменяет поле Source Link-Layer Address имеющимся значением DLCI из заголовка кадра Frame Relay с сообщением. Значение DLCI форматируется в соответствии с полем Source Link-Layer Address [IPv6-FR]. Это требуется для корректной интерпретации полей при последующей обработке сообщения IND Solicitation.

Для узла Frame Relay значение MTU из запроса можно использовать для установки в MTU у получателя более оптимального значения, если оно не задано при настройке конфигурации интерфейса.

A.3.2.2. Обработка сообщений IND Advertisement

Узел Frame Relay, получивший IND Advertisement, может поместить сопоставление адресов отправителя на канальном уровне и IPv6 из анонса IND Advertisement в свой кэш ND [IPv6-ND], как это делается для ND Advertisement.

Затем получатель IND Advertisement может сохранить Target Link-Layer Address из сообщения как значение DLCI удалённого узла на другой стороне VC. Это значение DLCI эквивалентно адресу канального уровня, по которому удалённый узел идентифицирует получателя.

Если получатель IND Advertisement имеет пул адресов IPv6 и реализация позволяет, он может «спарить» локальный адрес IPv6 с конкретным адресом IPv6 из полученного списка для последующих коммуникаций через VC. Более конкретно, спаривание следует выполнять для адресов IPv6 из одной подсети (общий префикс).

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

Copyright (C) The Internet Society (2001). Все права защищены.

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

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

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

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

Финансирование функций RFC Editor обеспечено Internet Society.

---

Заменен RFC 8277.

Network Working Group                             J. Klensin, Editor
Request for Comments: 2821                         AT&T Laboratories
Obsoletes: 821, 974, 1869                                 April 2001
Updates: 1123
Category: Standards Track

Протокол SMTP

Simple Mail Transfer Protocol

PDF

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

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

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

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

Аннотация

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

• исходная спецификация SMTP (Simple Mail Transfer Protocol) — RFC 821 [30];
• требования к системе доменных имен и ее использованию для передачи электронной почты — RFC 1035 [22] и RFC 974 [27];
• пояснения и вопросы применимости RFC 1123 [2];
• Механизмы SMTP Extension [19].

Данный документ отменяет действие RFC 821 и RFC 974, а также обновляет RFC 1123 (замена материалов, связанных с передачей электронной почты в RFC 1123). Однако спецификация RFC 821 содержит некоторые возможности, которые недостаточно использовались в Internet середины 1990-х голов и (в приложениях) некоторые дополнительные транспортные модели. Эти разделы опущены в целях упрощения и сокращения спецификации. Интересующиеся читатели могут обратиться к RFC 821.

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

Хотя протокол SMTP был разработан для транспортировки и доставки электронной почты, данная спецификация содержит сведения, имеющие важное значение для протоколов «распределения» почты POP [3, 26] и IMAP [6]. Дополнительное рассмотрение вопросов доставки почты в ящики адресатов приводится в RFC 2476 [15].

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

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

Оглавление

1. Введение

Задачей протокола SMTP (Simple Mail Transfer Protocol – простой протокол передачи электронной почты) является надежная и эффективная доставка сообщений электронной почты.

Протокол SMTP не связан с конкретными подсистемами передачи и требует только надежных каналов передачи потока данных с сохранением порядка. Хотя этот документ обсуждает вопросы доставки применительно к протоколу TCP, возможно использование иного транспорта. Некоторые из альтернативных вариантов рассмотрены в приложениях к RFC 821.

Важной особенностью SMTP является возможность доставки почты через сети, обычно называемые SMTP mail relaying (см. параграф 3.8). Сеть состоит из доступных один другому по протоколу TCP хостов сети Internet, хостов TCP/IP Intranet-сетей, находящихся за брандмауэрами, и хостов в других средах LAN или WAN, использующих на транспортном уровне протоколы, отличные от TCP. Используя SMTP, процесс может передавать почту другому процессу в той же или какой-то иной сети с помощью relay-процессов или шлюзов, доступных из обеих сетей.

Таким путем почтовые сообщения можно передавать через множество промежуточных трансляторов (relay) или шлюзов на пути между отправителем и конечным адресатом. Для определения следующего «промежуточного получателя²» (next-hop) на пути к адресату используется механизм Mail eXchanger (MX) системы доменных имен (DNS) [22, 27], рассмотренный в главе 5.

2. Модель SMTP

2.1 Базовая структура

                   +----------+                +----------+
+-------------+    |          |                |          |
|Пользователь |<-->|          |Команды/отклики |          |
+-------------+    |  Клиент  |     SMTP       |  Сервер  |
+-------------+    |   SMTP   |<-------------->|   SMTP   |    +--------+
|  Файловая   |<-->|          |   и почта      |          |<-->|Файловая|
|  система    |    |          |                |          |    |система |
+-------------+    +----------+                +----------+    +--------+
                   Клиент SMTP                 Сервер SMTP

Устройство протокола SMTP показано на рисунке.

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

Способ предоставления почтовых сообщений клиенту SMTP и определения клиентом доменного имени, куда следует адресовать сообщение, является локальной задачей и не рассматривается в спецификации. В некоторых случаях доменные имена преобразуются или определяются клиентом SMTP, который и будет определять конечного адресата почты. В других случаях, когда клиенты SMTP связаны с реализациями протоколов POP [3, 26] или IMAP [6] или когда клиент SMTP находится в изолированной транспортной среде, доменное имя будет определять промежуточного получателя, через которого транслируется вся почта. Клиенты SMTP, которые передают весь трафик, независимо от домена адресата, связанного с конкретным сообщением, или не поддерживают очередей для повтора попыток передачи сообщений при неудаче, могут соответствовать данной спецификации, но не обеспечивать всех возможностей. Предполагается, что полнофункциональные реализации SMTP, включая трансляторы, которые используются неполными системами и их получателями, будут поддерживать очереди, повторы и альтернативную адресацию, рассматриваемые в данном документе.

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

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

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

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

Сервер обеспечивает отклик на каждую полученную команду – отклик может показывать восприятие команды (в таких случаях ожидаются дополнительные команды), а также содержать сообщение о временной или постоянной ошибке. Команды, задающие отправителя или получателей, могут включать поддерживаемые сервером SMTP расширения, описанные в параграфе 2.2. Диалог между клиентом и сервером осуществляется поэтапно (команда – отклик – команда …), хотя можно использовать по взаимному согласию конвейерную обработку [13].

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

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

Обычно промежуточные хосты определяются по записям DNS MX, а не путем явного задания маршрута отправителем (см. раздел 5 и приложения C, F.2).

2.2 Модель расширений

2.2.1 Базовые вопросы

В рамках программы, начатой в 1990, приблизительно через 10 лет после выпуска RFC 821, протокол был обновлен за счет добавления модели «расширения услуг»⁵, позволяющей клиентам и серверам согласовать использование общих функций, выходящих за пределы исходной спецификации SMTP. Механизм расширения SMTP определяет способ согласования расширенных возможностей клиента и сервера SMTP; сервер может информировать клиента о поддерживаемых расширениях.

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

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

• команда EHLO взамен прежней команды HELO;
• реестр расширений сервиса SMTP;
• дополнительные параметры команд MAIL и RCPT;
• возможность замены команд, определенных в данном протоколе (таких, как DATA) при передаче символов, отличных от ASCII [33].

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

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

2.2.2 Определение и регистрация расширений

Реестр расширенных служб SMTP поддерживается агентством IANA. С каждым расширением связано соответствующее ключевое значение EHLO. Каждая дополнительная служба, регистрируемая IANA, должна быть определена на основе стандартного протокола или одобренного IESG экспериментального протокола. Определение должно включать:

• текстовое имя расширенного сервиса SMTP;
• ключевое значение EHLO связанное с этим расширением;
• синтаксис и возможные значения параметров, связанных с ключевым значением EHLO;
• все дополнительные команды SMTP, связанные с расширением (такие команды обычно используются, но не являются обязательными, как и ключевое значение EHLO);
• все новые параметры расширения, связанные с командами MAIL или RCPT;
• описание воздействия поддержки расширения на поведение клиентов и серверов SMTP;

• размер увеличения максимальной длины команд MAIL и/или RCPT сверх заданного настоящим стандартом.

Кроме того, все ключевые значения EHLO, начинающиеся с X или x, указывающие на локальные расширения сервиса SMTP, используются только на основе двухсторонних соглашений. Ключевые слова, начинающиеся с X (независимо от регистра) недопустимо использовать в регистрируемых расширениях сервиса. И наоборот, ключевые значения, представляемые в отклике EHLO, который не начинается с X, должны соответствовать стандарту, проекту стандарта или одобренному IESG экспериментальному расширению SMTP, зарегистрированному IANA. Для соответствующих требованиям стандарта серверов недопустимо предлагать начинающиеся с отличных от X символов расширения сервиса, если они не зарегистрированы.

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

2.3 Терминология

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

1. MUST — необходимо

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

2. MUST NOT — недопустимо

Эта фраза или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

3. SHOULD — следует

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

4. SHOULD NOT — не следует

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

5. MAY — возможно

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

2.3.1 Объекты электронной почты

Протокол SMTP обеспечивает транспортировку объектов электронной почты. Каждый объект состоит из конверта (envelope) и содержимого.

Конверт SMTP передается как серия протокольных элементов SMTP (см. главу 3). Конверт содержит адрес отправителя (по которому должны возвращаться отчеты об ошибках) и один или более адресов получателей, а также дополнительную информацию для расширенных служб. В силу исторических причин возможно использование вариаций адреса получателя в команде RCPT TO для задания альтернативных режимов доставки типа непосредственного отображения; использование таких вариаций в настоящее время осуждается (см. параграф F.6).

Содержимое SMTP передается в виде протокольного элемента SMTP DATA и состоит из двух частей – заголовков и тела. Если содержимое соответствует другим современным стандартам, заголовок формирует набор пар «поле – значение», структурированных в соответствии со спецификацией формата сообщений [32]; тело сообщения, при наличии в нем структуры, соответствует спецификации MIME [12]. Содержимое является текстовым по своей природе и выражается с использованием набора символов US-ASCII [1]. Хотя расширения SMTP (типа 8BITMIME [20]) могут обходить это ограничение для содержимого, заголовки всегда должны кодироваться с использованием набора символов US-ASCII. Расширение MIME [23] определяет алгоритм представления в заголовках символов, не входящих в US-ASCII, с использованием комбинаций символов набора US-ASCII.

2.3.2 Отправители и получатели

В RFC 821 два хоста, принимающие участие в транзакции SMTP, были описаны как SMTP-sender (отправитель) и SMTP-receiver (получатель). В настоящей спецификации используются иные термины, отражающие сложившуюся практику — SMTP client (иногда просто client) и SMTP server (или просто server) для отправителя и получателя, соответственно. Поскольку в режиме трансляции один хост может выступать в качестве клиента и сервера, продолжается использование терминов «получатель» (receiver) и «отправитель» (sender).

2.3.3 Почтовые агенты и хранилища

В данной спецификации используется современная терминология, устоявшаяся с момента публикации RFC 821. В частности, клиенты и серверы SMTP обеспечивают почтовый транспортный сервис и называются «агентами доставки почты» — АДП (Mail Transfer Agent или MTA). Пользовательские почтовые агенты – ППА (Mail User Agent, MUA или UA) выступают в качестве исходных отправителей и конечных получателей почтовых сообщений. На стороне отправителя ППА может собирать почту от пользователя для передачи ее АДП; агент АДП на стороне получателя передает почту ППА (по крайней мере, передает этому агенту ответственность за доставку почты; например, помещая ее в «почтовое хранилище» — message store). Однако, хотя эти термины достаточно точно выражают суть и применимы к другим средам, границы между ППА (MUA) и АДП (MTA) определены недостаточно четко. Следовательно, читатель должен внимательно относиться к терминологии.

2.3.4 Хост

В рамках данной спецификации термин «хост» обозначает компьютерную систему, подключенную к Internet (или, в некоторых случаях, к частной сети TCP/IP) и поддерживающую протокол SMTP. Хосты обозначаются именами (см. 2.5); обозначение числовыми адресами не рекомендуется использовать.

2.3.5 Домен

Домен (доменное имя) состоит из одной или нескольких разделенных точками компонент. В контексте SMTP эти компоненты (метки в терминах DNS [22]) могут содержать только последовательности букв⁷, цифр, дефиса (-) и знака подчеркивания (_) из набора символов ASCII [1]. Доменные имена используются для обозначения хостов и других объектов иерархии доменных имен. Например, доменное имя может указывать на псевдоним (метка CNAME RR) или метку записи MX (Mail exchanger), которая будет использоваться для доставки почты вместо представленного имени хоста. Дополнительные сведения о доменных именах можно найти в работе [22] и разделе 5 данной спецификации.

Доменное имя, как описано в данном документе и работе [22], представляет собой полное имя (fully-qualified domain name или FQDN). Доменные имена, не являющиеся FQDN, есть ни что иное, как локальные псевдонимы. В транзакциях SMTP появление локальных псевдонимов недопустимо.

2.3.6 Буфер и таблица состояния

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

2.3.7 Строки

Команды SMTP и (если расширение сервиса не задает иного) данные сообщений передаются как строки (line). Строка состоит из некоторого (возможно, нулевого) числа символов данных и завершается символами ASCII для возврата каретки (CR — 0Dh) и перевода строки (LF — 0Ah). Последовательность завершения строки в этом документе будет обозначаться <CRLF>. Для реализаций, соответствующих требованиям данной спецификации, недопустимо принимать или генерировать в качестве завершения строки любые другие символы или последовательности символов. Серверы могут вносить ограничения на длину строк (см. параграф 4.5.3).

В дополнение отметим, что использование в тексте отдельных символов CR или LF (не в комбинации <CRLF>) имеет долгую историю проблем в реализациях почтовых систем и приложениях, работающих с электронной почтой. Для клиентов SMTP недопустима передача этих символов за исключением тех случаев, когда комбинация символов служит для завершения строки, а в этом случае должна применяться только стандартная последовательность <CRLF>.

2.3.8 Отправитель, система доставки, транслятор, шлюз

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

Шлюзами (gateway) SMTP называют системы, получающие почту от клиентов из одной транспортной среды и передающие ее серверу другой среды. Различия в протоколах и семантике сообщения по разные стороны шлюза могут потребовать преобразования, которое не может быть выполнено трансляторами SMTP. В контексте данной спецификации межсетевые экраны (firewall), переписывающие адреса, следует рассматривать как шлюзы, даже если по обе стороны экрана используется среда SMTP (см. [11]).

2.3.9 Содержимое сообщения и почтовые данные

Термины «содержимое сообщения» (message content) и «почтовые данные (mail data) в этом документе являются взаимозаменяемыми и служат для обозначения информации, передаваемой после восприятия команды DATA до завершения передачи. Содержимое сообщения включает заголовки и (возможно структурированное) тело сообщения. Спецификация MIME [12] обеспечивает стандартные механизмы структурирования тела сообщений.

2.3.10 Почтовый ящик и адрес

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

2.3.11 Отклик

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

2.4 Общие синтаксические принципы и модель транзакции

Команды и отклики SMTP подчиняются жестким синтаксическим правилам. Все команды начинаются с «командного глагола» (command verb), а все отклики – с 3-значного цифрового кода. В некоторых командах и откликах за командой или кодом должны следовать аргументы. Некоторые команды не принимают аргументов (после команды), а за некоторыми кодами откликов может следовать произвольный текст. Во всех случаях присутствия текста он отделяется от команды или кода символом пробела. Полные описания команд и откликов приведены в разделе 4.

Регистр символов в командах и значениях аргументов не имеет значения (т. е., TO: и to: в команде RCPT не различаются), однако это правило имеет исключения для локальной части названия почтового ящика (расширения SMTP могут явно указывать чувствительные к регистру символов элементы). Команды, значения аргументов (кроме локальной части имени почтового ящика) и свободный текст могут содержать произвольную комбинацию символов верхнего и нижнего регистра. Для локальной части имен почтовых ящиков регистр символов должен приниматься во внимание. Следовательно, реализации SMTP должны пытаться сохранить регистр символов в локальной части имени почтового ящика. В частности, для некоторых хостов пользователь smith может отличаться от пользователя Smith. Однако использование чувствительных к регистру локальных частей в именах почтовых ящиков снижает уровень интероперабельности – следует избегать такого применения локальных имен.

Некоторые серверы SMTP в нарушение данной спецификации (и RFC 821) требуют от клиентов представления команд в верхнем регистре. В реализациях могут приниматься меры для представления команд в соответствии с требованиями таких серверов.

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

Синтаксис каждой команды рассматривается ниже вместе с описаниями команд. Общие элементы и параметры рассмотрены в параграфе 4.1.2.

Команды и отклики состоят из символов ASCII [1]. Когда транспортный сервис обеспечивает 8-битовый (байты или октеты) канал передачи, каждый 7-битовый символ передается с выравниванием по правому краю (старший бит октета имеет нулевое значение). Стандартный сервис SMTP обеспечивает поддержку только 7-битовых символов. Клиенту-отправителю SMTP, который не смог согласовать подходящее расширение с сервером, недопустимо передавать сообщения, содержащие информацию в старших битах октетов. Если в нарушение этого правила такое сообщение передается, принимающий сервер SMTP может сбросить старший бит или отвергнуть сообщение как некорректное. В общем случае транслятору SMTP следует предполагать, что содержимое принятого сообщения корректно и, в предположении что конверт позволяет это сделать, транслировать сообщение без проверки его содержимого. Конечно, если содержимое некорректно и путь передачи не может его воспринять, такое решение может привести к доставке конечному адресату искаженного сообщения. Системы доставки SMTP могут отвергать (возвращать — bounce) такие сообщения, не доставляя их. Никаким передающим системам SMTP не дозволяется передавать envelope-команды, содержащие символы, не включенные в набор US-ASCII; принимающим системам следует отвергать такие команды, используя стандартный отклик 500 syntax error — invalid character.

Клиент может запросить у сервера передачу 8-битового содержимого сообщений с использованием расширенных возможностей SMTP, прежде всего 8BITMIME [20]. Серверам SMTP следует поддерживать режим 8BITMIME. Однако это недопустимо трактовать, как разрешение на неограниченную передачу 8-битовых символов. Для отправителя недопустимо запрашивать режим 8BITMIME при передачи данных, где в качестве старшего бита не используется соответствующий формат MIME с подходящим транспортным кодирование; серверы могут отвергать такие сообщения.

Используемая в этом документе металингвистическая нотация соответствует нотации Augmented BNF, принятой в документах других почтовых систем Internet. Читателям, которые незнакомы с этим синтаксисом, следует прочесть спецификацию ABNF [8]. Для ясности термины метаязыка, используемые в тексте, обозначены угловыми скобками (например, <CRLF>).

3. Обзор процедур SMTP

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

3.1 Инициирование сеанса

Сеанс SMTP инициируется, когда клиент соединяется с сервером и сервер отвечает соответствующим сообщением.

Реализация сервера SMTP может включать идентификацию своих программ и сведения об их версии в отклик подтверждения соединения после кода 220, на практике эта информация позволяет упросить поиск и решение проблем. Реализации серверов могут включать возможность запрета передачи данных о программе и ее версии в целях безопасности. Хотя некоторые системы указывают свои контактные адреса для связанных с почтой проблем, это не может служить заменой поддержки требуемого стандартом адреса postmaster (см. параграф 4.5.1).

Протокол SMTP позволяет серверу формально отвергать транзакцию, не запрещая изначальные соединения: код 554 может возвращаться в открывающем сообщении взамен кода 220. Сервер, использующий такой вариант, должен по-прежнему ждать, пока клиент передаст команду QUIT (см. параграф 4.1.1.10) перед закрытием соединения, а на любую мешающую команду следует возвращать отклик 503 bad sequence of commands (некорректная последовательность команд). Поскольку попытка организации SMTP-соединения с такими системами может приводить к ошибке, серверу, возвращающему код 554, следует передавать вместе с кодом информацию, которая позволит передающей системе понять причину ошибки.

3.2 Инициирование клиента

После того, как сервер передал приглашающее сообщение и клиент получил его, последний обычно передает серверу команду EHLO, идентифицирующую клиента. А дополнение к открытию сеанса использование EHLO показывает, что клиент способен работать с расширенным сервисом и запрашивает у сервера список поддерживаемых расширений. Старые системы SMTP, неспособные поддерживать расширения сервиса и современные клиенты, которым не требуется расширенный сервис с инициируемом почтовом сеансе, могут использовать HELO взамен EHLO. Для серверов недопустимо возвращать расширенные отклики в стиле EHLO на команду HELO. Для конкретной попытки соединения, если сервер возвращает отклик command not recognized (команда не распознана) на EHLO, клиенту следует начать процесс заново и передать команду HELO.

Хост, передающий команду EHLO, идентифицирует в ней себя; команду можно интерпретировать как «Hello, I am <domain>» (Привет, я домен …), а для случая EHLO – «and I support service extension requests» (и я поддерживаю расширения …).

3.3 Почтовые транзакции

Почтовая транзакция SMTP состоит из трех этапов. Началом транзакции служит команда MAIL, дающая идентификацию отправителя (в общем случае команда MAIL может быть введена только при отсутствии незавершенных почтовых транзакций; см. параграф 4.1.4.). После этого следует одна или несколько команд RCPT, указывающих получателей сообщения. Последний этап транзакции начинается командой DATA, которая инициирует передачу почтовых данных и завершается индикатором end of mail, который также подтверждает транзакцию.

1. Первым шагом почтовой транзакции является команда MAIL.

MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

Эта команда говорит получателю SMTP о начале новой почтовой транзакции и сбрасывает все таблицы состояний и буферы, включая любые данные получателя или почтовые данные. Часть <reverse-path> (обратный путь) первого или единственного аргумента команды содержит название почтового ящика отправителя (между скобками < и >), которое может использоваться для передачи отчетов об ошибках (см. параграф 4.2). Восприняв команду, сервер SMTP возвращает отклик 250 OK. Если указанный почтовый ящик по каким-то причинам неприемлем, сервер должен возвратить отклик, показывающий временной тип отказа – постоянная (т. е., повторится при повторе команды клиентом) или временная (т. е., адрес клиента может быть принят при следующем вызове) ошибка. Несмотря на очевидность этого требования, существуют обстоятельства, при которых возможность восприятия обратного пути невозможно определить, пока не будет получен по крайней мере один прямой путь (в команде RCPT). В таких случаях сервер может воспринять обратный путь (отклик 250) и сообщить о возникновении проблем после получения и проверки прямых путей. Обычно это делается с помощью откликов 550 или 553.

Исторически <reverse-path> может содержать больше данных, нежели просто имя почтового ящика, но современным системам не следует использовать маршрутизацию почты отправителем — source routing (см. Приложение C).

Дополнительные параметры <mail-parameters> связываются с согласованным расширением сервиса SMTP (см. 2.2).

2. Вторым этапом транзакции является команда RCPT.

RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

Первый или единственный аргумент этой команды включает прямой путь forward-path (обычно имя почтового ящика и домена, обязательно заключенные в скобки <>), идентифицирующий получателя. Восприняв команду, сервер SMTP возвращает отклик 250 OK и сохраняет прямой путь. Если известно, что почта не может быть доставлена адресату, сервер SMTP возвращает отклик 550, обычно сопровождаемый строкой типа «no such user — » с именем почтового ящика, для которого невозможна доставка (возможны также другие обстоятельства и коды возврата).

Параметр <forward-path> может содержать не только адрес получателя. Исторически <forward-path> может включать маршрут (source routing) к получателю в виде списка промежуточных хостов, однако современным клиентам SMTP не рекомендуется использовать маршрутизацию почты отправителем (см. Приложение C). Сервер должен быть готов к восприятию списка source route в прямом пути, но рекомендуется игнорировать эти маршруты и можно отклонять предлагаемую таким маршрутом трансляцию. Подобно этому, сервер может отказаться от приема почты, предназначенной для других хостов или систем. Эти ограничения делают сервер бесполезным в качестве транслятора для клиентов, не полностью поддерживающих функциональность SMTP. Следовательно, для клиентов с ограниченными возможностями недопустимо предполагать, что любой SMTP-сервер в Internet можно использовать для обработки (трансляции) почты. Если команда RCPT принята без предшествующей команды MAIL, сервер должен возвращать отклик 503 «Bad sequence of commands⁸«. Дополнительные параметры <rcpt-parameters> связываются с согласованным расширением сервиса SMTP (см. параграф 2.2).

3. Третьим этапом транзакции является обработка команды DATA (или ее аналога для расширенного сервиса).

DATA <CRLF>

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

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

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

Если команды MAIL и RCPT не были введены или были отвергнуты, сервер может возвращать отклик command out of sequence (503) или no valid recipients (554 – нет корректных получателей) в ответ на команду DATA. При получении одного из таких откликов (или любого отклика 5yz) для клиента недопустима передача данных серверу (точнее, передача данных недопустима, пока не будет получен отклик 354).

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

Однако на практике некоторые серверы не проверяют адресата после приема текста сообщения. Таким серверам следует трактовать отказ для одного или нескольких получателей как «отказ обусловленный другим отказом» (subsequent failure) и возвращать почтовое сообщение, как указано в главе 6. Использование отклика 550 mailbox not found (или его эквивалента) после восприятия данных делает для клиента сложной или невозможной диагностику причины отказа.

При использовании формата RFC 822 [7, 32] почтовые данные включают элементы заголовка, такие как Date, Subject, To, Cc, From. Серверам SMTP не рекомендуется отвергать сообщения на основе дефектов в заголовках RFC 822 и MIME [12] или в теле сообщения. В частности, недопустимо отвергать сообщения, в которых число полей Resent не соответствует или Resent-to появляется без Resent-from и/или Resent-date.

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

3.4 Пересылка для коррекции и обновления адресов

Поддержка пересылки чаще всего требуется для консолидации адресов и упрощения адресации в сети предприятия (или применительно к такой сети) и реже для случаев изменения адресов. Пересылка без уведомления отправителя (Silent forwarding) в целях обеспечения безопасности или сокрытия внутренней структуры весьма распространена сегодня в Internet.

В обоих перечисленных случаях приходится решать вопрос сокрытия (в некоторых случаях – безопасности) информации – следует ли показывать отправителю данные о пересылке почты. Это может быть особо важным, когда конечный адресат просто недоступен для отправителя. Следовательно, механизм пересылки, описанный в параграфе 3.2 RFC 821 и особенно строки откликов 251 (скорректированный получатель) и 551 на команду RCPT должны осторожно оцениваться при разработке и, когда это возможно, при настройке конфигурации системы.

В частности:

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

Или:

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

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

3.5 Команды для отлаживания адресов

3.5.1 Обзор

Протокол SMTP обеспечивает команды для проверки имен пользователей или получения содержимого списков рассылок. Такие операции осуществляются с помощью команд VRFY и EXPN, которые получают текстовые строки в качестве аргументов. Реализациям следует поддерживать команды VRFY и EXPN (особенности использования этих команд рассмотрены в параграфах 3.5.2 и 7.3).

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

User Name <local-part@domain>
local-part@domain

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

553 User ambiguous

или

553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>

или

553-Ambiguous; Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>

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

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

На некоторых хостах различия между списками рассылок и псевдонимами выражены весьма слабо, поскольку оба типа записей могут сохраняться в единой структуре данных и возможны списки рассылок, содержащие единственный адрес. Если дается запрос на применение команды VRFY к списку рассылок, позитивный отклик может быть возвращен, если направленное по адресу списка сообщение может быть доставлено кому-либо из списка, в остальных случаях следует возвращать сообщение об ошибке (например, отклик 550 That is a mailing list, not a User⁹ или 252 Unable to verify members of mailing list¹⁰). Если делается запрос имени пользователя из списка, сервер может давать позитивный отклик, содержащий список из одного имени, или сообщение об ошибке (например, 550 That is a user name, not a mailing list¹¹).

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

Термин User name (имя пользователя) является недостаточно четким и должен использоваться осмотрительно. Реализации команд VRFY и EXPN должны, по крайней мере, распознавать локальные почтовые ящики, как имена пользователей. Однако в сети Internet зачастую один хост обслуживает почту для множества доменов и хостам (особенно тем, которые работают с разными доменами) следует обеспечивать такую функциональность и воспринимать форму local-part@domain, как имя пользователя; хосты также могут распознавать, как имена пользователей, строки других типов.

Случай получения имен почтовых ящиков из списка рассылок требует многострочных откликов типа приведенного ниже (C – клиент, S – сервер; прим. перев.):

C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>

или

C: EXPN Executive-Washroom-List
S: 550 Access Denied to You.

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

3.5.2 Нормальные отклики VRFY

Когда возвращается нормальный код (2yz или 551) в результате запроса VRFY или EXPN, отклик обычно включает имя почтового ящика, т. е., должна присутствовать запись вида <local-part@domain>, где domain является полным доменным именем (FQDN). В ситуациях, исключающих нарушение требований данной спецификации, может возвращаться текстовая строка произвольной формы. Для облегчения анализа и разделения имени почтового ящика и данных человека (или компании) адрес следует выводить в угловых скобках. При возврате адресов (а не произвольной текстовой строки) команды EXPN и VRFY должны возвращать только корректные значения доменной части адреса, которые можно использовать в команде RCPT. Следовательно, если адрес может передаваться программе или другой системе, должно указываться имя почтового ящика, используемого для доступа к адресату. Возврат путей (явные маршруты source route) для команд VRFY и EXPN недопустим.

Реализациям серверов следует поддерживать обе команды VRFY и EXPN. В целях безопасности может обеспечиваться локальная возможность отключить любую из этих команд (или обе) с помощью конфигурационных параметров. Когда эти команды поддерживаются, не требуется обеспечивать их работу через трансляторы, если трансляция разрешена. Поскольку обе эти команды были необязательными в спецификации RFC 821, они должны быть указаны как расширения сервиса в отклике EHLO (если команды поддерживаются).

3.5.3 Значения откликов при успешном завершении VRFY или EXPN

Для серверов недопустим возврат откликов 250 на команды VRFY и EXPN, пока адрес реально не проверен. В частности, для сервера недопустимо возвращать код 250, если его действия ограничились проверкой корректности синтаксиса. В таких случаях следует возвращать код 502 (команда не реализована) или 500 (синтаксическая ошибка, команда не распознана). Как было указано, реализация (в смысле проверки адресов и возврата информации) команд VRFY и EXPN настоятельно рекомендуется. Следовательно, реализации, возвращающие код 500 или 502 для команды VRFY не являются полностью совместимыми с данной спецификацией.

Существуют ситуации, когда адрес представляется корректным, но не может быть проверен в реальном масштабе времени (в частности, когда сервер используется при обмене почтой для другого сервера или домена). «Видимая корректность» (Apparent validity) в таких случаях будет включать, по крайней мере, проверку синтаксиса и может также включать проверку возможности трансляции для указанного адреса. В таких случаях следует возвращать код 252. Эти ситуации связаны с вопросами проверки RCPT, рассмотренными в параграфе 2.1. Аналогично ситуации, описанной в 3.4, коды 251 и 551 могут использоваться для команд VRFY и EXPN, чтобы показать адреса, которые распознаны, но почта для них будет пересылаться или отвергаться. Реализациям в общем случае следует быть более жесткими в вопросах проверки адресов для случая VRFY, нежели для команды RCPT, даже если это будет занимать немного больше времени.

3.5.4 Семантика и использование EXPN

Команда EXPN зачастую очень полезна для отладки и поиска проблем, связанных со списками рассылок и псевдонимами ко множеству адресов (multiple-target-address alias). Некоторые системы пытаются использовать поиск отправителя в списке рассылки для предотвращения дубликатов. Распространение системы псевдонимов с почтой в Internet для хостов (обычно записи MX и CNAME на серверах DNS), почтовых ящиков (различные типы локальных псевдонимов хоста) и в различных proxy-системах делает почти невозможной стратегию согласованного использования псевдонимов и почтовым системам не следует пытаться решить эту задачу.

3.6 Домены

При использовании доменных имен в SMTP допускаются только преобразуемые (resolvable), полные доменные имена (FQDN). Иными словами, допустимы имена, которые включены в записи MX RR или A RR (см. главу 5), а также имена, указанные в записях CNAME RR серверов имен (DNS). Недопустимо использование локальных имен и неполных доменных имен. Однако существуют два исключения из правил FQDN:

• Доменное имя в команде EHLO должно быть основным именем хоста (primary host name – доменное имя, включенное в запись A RR) или, если хост не имеет имени, — «дословным» адресом в соответствии с 4.1.1.1.
• Зарезервированное имя почтового ящика postmaster может использоваться в команде RCPT без указания домена (см. параграф 4.1.1.3) и должно восприниматься сервером.

3.7 Трансляция

В общем случае доступность записей MX в DNS [22, 27] избавляет от необходимости использования явно заданных маршрутов в почтовой системе Internet. С явной маршрутизацией почты связано множество проблем, делающих такое использование совершенно нежелательным. Клиентам SMTP не следует генерировать явные маршруты source route за исключением особых ситуаций. Серверы SMTP могут отказывать в трансляции или не воспринимать сообщения с указанным отправителем маршрутом. Обнаружив маршрутную информацию, сервер SMTP может игнорировать ее и просто переслать почту конечному адресату, указанному в последнем элементе заданного маршрута, — серверам следует поступать именно так. Встречаются случаи некорректного использования имен адресатов, отсутствующих в записях DNS с использованием преобразования имен на промежуточных хостах, указанных в маршруте source route. При исключении (игнорировании) заданного отправителем маршрута в таких случаях возникают проблемы. Это одна из нескольких причин, по которым для клиентов SMTP недопустима генерация некорректных маршрутов source route или путей, зависящих от последовательного преобразования имен.

Когда маршруты source route не используются, процесс, описанный в RFC 821 для конструирования обратного пути из прямого, неприменим и обратный путь во время доставки будет просто адресом, указанным в команде MAIL.

Транслирующий сервер SMTP обычно определяется из записи MX и не является системой окончательной доставки почты. Такой сервер может принимать или отвергать трансляцию почты аналогично восприятию или отказу для почты локальных пользователей. Если сервер принял трансляцию, от становится клиентом SMTP, организуя канал передачи следующему серверу SMTP, указанному в DNS (в соответствии с правилами, описанными в разделе 5), и передает ему почту. Если сервер отвергает трансляцию почты для какого-либо адреса, ему следует возвращать отклик 550.

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

Важно отметить, что записи MX могут указывать на серверы SMTP, которые действуют как шлюзы в другие среды, а не только выполняют трансляцию и окончательный прием почты (см. параграф 3.8 и раздел 5).

Если сервер SMTP принял на себя задачу трансляции почты и позднее обнаружил, что получатель указан некорректно или почту невозможно доставить по тем или иным причинам, этот сервер должен создать уведомление о невозможности доставки почты и переслать его отправителю недоставленного сообщения, указанному в обратном пути. Для уведомления следует (по возможности) использовать стандартные форматы (см., например [24, 25]).

Это уведомление должно передаваться сервером SMTP с хоста-транслятора или хоста, который обнаружил невозможность доставки. Естественно, что для серверов SMTP недопустима отправка уведомлений о невозможности доставки уведомлений¹². Одним из способов предотвращения петель при передаче сообщений об ошибках является использование пустой строки обратного пути в команде MAIL при передаче уведомления. При передаче такого сообщения строка обратного пути должна быть пустой – null (см. параграф 4.5.5). Команда MAIL с пустым обратным путем имеет вид:

MAILFROM:<>

Как указано в параграфе 6.4, транслятору SMTP не нужно проверять и обрабатывать заголовки и тело транслируемых сообщений, а также недопустимо предпринимать какие-либо любые действия по отношению к сообщению, за исключением добавления к заголовку строки «Received:» (см. параграф 4.4) и (необязательной) попытки обнаружения петель в почтовой системе (см. 6.2).

3.8 Почтовые шлюзы

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

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

3.8.1 Поля заголовка при использовании шлюзов

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

Другие почтовые системы при передаче сообщений в Internet часто используют подмножество заголовков RFC 822 или обеспечивает похожую функциональность с использованием другого синтаксиса, но некоторые из таких почтовых систем не имеют эквивалента конвертов SMTP. Следовательно, когда сообщение покидает почтовую среду Internet, может потребоваться включение информации из конверта SMTP в заголовок сообщения. Возможным решением будет создание новых полей заголовка для передачи информации из конверта (например, X-SMTP-MAIL: и X-SMTP-RCPT:). Однако такое решение потребует изменения почтовых программ в чужой среде и может привести к разглашению частной информации (см. параграф 7.2).

3.8.2 Строки Received при использовании шлюзов

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

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

Шлюзу следует указывать среду и протокол в поле via строки Received, создаваемый шлюзом.

3.8.3 Адресация при использовании шлюзов

Со стороны Internet шлюзу следует воспринимать все корректные форматы адресов в командах SMTP и заголовках RFC 822, а также все корректные сообщения RFC 822. Генерируемые шлюзом адреса и заголовки должны соответствовать применимым стандартам Internet (включая данную спецификацию и RFC 822). Шлюзы подчиняются тем же правилам обработки маршрутов source route, которые описаны в параграфе 3.3 для других систем SMTP.

3.8.4 Другие поля заголовков при использовании шлюзов

Шлюз должен обеспечивать соответствие требованиям Internet всех полей заголовков в сообщениях, передаваемых в почтовую среду Internet. В частности, все адреса в полях From:, To:, Cc: и т. п. должны преобразовываться (если нужно) в соответствии с синтаксисом RFC 822, должны указывать только полные доменные имена и должны быть эффективны и полезны для передачи откликов. Алгоритму, используемому для преобразования почты Internet в другие форматы, следует обеспечивать доставку сообщений об ошибках из чужой почтовой среды по пути возврата из конверта SMTP, а не отправителю, указанному в поле From: (или других полях) заголовка RFC 822.

3.8.5 Конверты при работе со шлюзами

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

3.9 Разрыв сеансов и соединений

Соединение SMTP разрывается при получении от клиента команды QUIT. Сервер возвращает в ответ на эту команду позитивный отклик и закрывает соединение.

Для серверов SMTP недопустимо преднамеренно закрывать соединения за исключением следующих ситуаций:

• После получения команды QUIT и отклика на нее с кодом 221.

• После определения необходимости отключения (shut down) сервиса SMTP и возврата кода 421. Такой отклик может выдаваться после получения сервером любой команды или (при необходимости) асинхронно (независимо от команд) в предположении, что клиент будет получать отклик после ввода следующей команды.

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

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

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

3.10 Почтовые списки и псевдонимы

Хостам SMTP следует поддерживать как псевдонимы, так и списки для преобразования адресов при групповой рассылке сообщений. Когда сообщение доставляется или пересылается по каждому адресу из списка, адрес возврата в конверте (MAIL FROM:) должен заменяться на адрес администратора списка. Однако в таких случаях заголовок сообщения [32] должен сохраняться неизменным; в частности, не должно меняться поле From.

Одним из важных свойств почтовой системы является механизм доставки одного сообщения множеству адресатов за счет преобразования (expanding или exploding) псевдо-адреса в список реальных адресов получателей. Когда сообщение направляется по такому псевдо-адресу (иногда его называют exploder), копия этого сообщения пересылается по каждому адресу из списка. Серверу следует просто использовать адреса из списка, применение эвристики или проверки соответствия для исключения некоторых адресов (например, отправителя исходного сообщения) настоятельно не рекомендуется. Псевдо-адреса называют списками (list, mail list) или псевдонимами (alias) в зависимости от способа получения адресов из списка.

3.10.1 Псевдонимы

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

3.10.2 Списки

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

4. Спецификации SMTP

4.1 Команды SMTP

4.1.1 Семантика и синтаксис команд

Команды SMTP определяют передачу почты и функции почтовой системы, запрашиваемые пользователем. Команды представляют собой текстовые строки, завершающиеся последовательностью <CRLF>. Команда, как таковая, представляет собой строку букв, завершаемую пробелом <SP> (при наличии параметров) или <CRLF>. В целях повышения уровня интероперабельности получатели SMTP должны быть терпимы к пробелам перед завершающей последовательностью <CRLF>. Синтаксис локальной части имени почтового ящика соответствует соглашениям принимающего сайта и синтаксису, описанному в параграфе 4.1.2. Команды SMTP обсуждаются ниже, а рассмотрению откликов посвящен параграф 4.2.

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

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

4.1.1.1 Расширенное приветствие (EHLO) или стандартное приветствие (HELO)

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

Клиентам SMTP следует начинать сессию SMTP с помощью команды EHLO. Если сервер SMTP поддерживает расширенные службы SMTP, он будет передавать позитивный отклик, сообщение об отказе или сообщение об ошибке. Если сервер SMTP (в нарушение данной спецификации) не поддерживает никаких расширений SMTP, он будет генерировать сообщение об ошибке. Старые клиенты SMTP могут (как обсуждалось выше) использовать команду HELO (в соответствии с RFC 821) взамен EHLO, а серверы должны поддерживать команды HELO и давать на них правильный отклик. В любом случае клиент должен использовать команду HELO или EHLO до начала почтовой транзакции.

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

Синтаксис:

ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF

Обычно в ответ на команду EHLO возвращается многострочный отклик, каждая строка которого содержит ключевое слово и может включать один или несколько параметров. В соответствии с требованиями к нормальному синтаксису многострочных откликов ключевые слова следуют после кода 250 и дефиса (для всех строк, кроме последней) или пробела (в последней строке). Ниже приведен пример позитивного отклика с использованием нотации ABNF и символов завершения из [8]:

ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
            / ( "250-" domain [ SP ehlo-greet ] CRLF
             *( "250-" ehlo-line CRLF )
                "250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
           ; строка символов, не содержащая CR или LF
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
             ; дополнительный синтаксис ehlo-params в зависимости от ehlo-keyword
ehlo-param = 1*(%d33-127)
           ; любые символы, включая <SP> и управляющие коды US-ASCII (0-31)

Хотя в команде EHLO можно использовать любую комбинацию строчных и прописных букв, команда всегда должна распознаваться и обрабатываться как EHLO (заглавные буквы) – это просто расширение практики, указанной в RFC 821 и параграфе 2.4.1.

4.1.1.2 Начало транзакции (MAIL)

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

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

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

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

Синтаксис:

"MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF

4.1.1.3 Получатель (RCPT)

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

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

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

Например, почта, полученная транслятором xyz.com и содержащая в конверте команды:

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

обычно будет пересылаться непосредственно на хост d.bar.org с командами в конверте:

MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>

Как указано в Приложении C, хост xyz.com может также транслировать почту через другой хост, используя в конверте команды:

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

или (для трансляции через jkl.org):

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>

Поскольку хосты не обязаны транслировать почту, xyz.com может отвергнуть сообщение при получении команды RCPT, используя отклик 550 (отказ в соответствии с используемыми правилами).

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

Синтаксис:

"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"/Forward-Path) [SP Rcpt-parameters]CRLF

4.1.1.4 Данные (DATA)

Получатель обычно возвращает отклик 354 на команду DATA и после этого трактует дальнейшие строки (символьные последовательности, завершающиеся <CRLF>, как сказано в параграфе 2.3.7), как почтовые данные от отправителя. Эта команда добавляет почтовые данные в конец буфера данных. Данные могут включать любые из 128 символов ASCII, хотя опыт показывает, что использование управляющих символов (кроме SP, HT, CR, LF) может вызывать проблемы, поэтому следует избегать таких символов.

Данные завершаются строкой, содержащей только точку и последовательность завершения строки (в потоке символов это будет <CRLF>.<CRLF>, см. параграф 4.5.2). Отметим, что первая последовательность <CRLF> на самом деле завершает последнюю строку почтовых данных (текста сообщения) или (при отсутствии данных) – командную строку DATA. Недопустимо добавление лишних последовательностей <CRLF>, поскольку это будет приводить к вставке пустой строки в сообщение. Единственным исключением из этого правила является обработка сообщений, переданных исходному отправителю без завершающей последовательности <CRLF> в последней строке; в таких случаях отправляющая сообщение система SMTP должна отвергнуть сообщение как некорректное или добавить <CRLF> в конце, чтобы принимающий сервер SMTP смог зафиксировать условие end of data (конец сообщения).

Использование строк, завершающихся одиночным символом <LF>, как это принято в некоторых UNIX-системах, порождает значительно больше проблем, нежели решает и для серверов SMTP такой подход недопустим, даже во имя повышения отказоустойчивости. В частности, последовательности <LF>.<LF> (перевод строки без возврата каретки) недопустимо трактовать как эквивалент последовательности <CRLF>.<CRLF> для завершения почтовых данных.

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

Когда сервер SMTP воспринимает сообщение для трансляции или окончательной доставки, он помещает трассировочную запись, которую также называют time stamp line (строка с временной меткой) или Received в верхней части почтовых данных. Эта запись показывает хост, передавший сообщение, хост-приемник (сервер), а также дату и время приема сообщения. Транслируемые сообщения могут содержать на финальном этапе множество трассировочных записей. Детальное описание трассировки и синтаксиса записей приводится в параграфе 4.4.

Дополнительную информацию по обработке команд DATA можно найти в параграфе 3.3.

Синтаксис:

"DATA" CRLF

4.1.1.5 Сброс (RSET)

Эта команда служит для прерывания текущей почтовой транзакции. Все сохраненные в буферах данные должны быть отброшены с очисткой буферов и таблиц состояния. Принимающая сторона в ответ на команду RSET должна передать отклик 250 OK без дополнительных аргументов. Команду RSET клиент может вводить в любой момент транзакции. Эта команда является эквивалентом NOOP (не выполняется никаких действий) при введении сразу после EHLO, до первого использования EHLO в данном сеансе, после завершения и подтверждения передачи данных или непосредственно перед командой QUIT. Для серверов SMTP недопустимо закрывать соединение в результате получения команды RSET – для разрыва соединения служит команда QUIT (см. параграф 4.1.1.10).

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

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

Синтаксис:

"RSET" CRLF

4.1.1.6 Проверка (VRFY)

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

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

Синтаксис:

"VRFY" SP String CRLF

4.1.1.7 Преобразование списка (EXPN)

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

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

Синтаксис:

"EXPN" SP String CRLF

4.1.1.8 Справка (HELP)

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

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

Серверам следует поддерживать команду HELP без аргументов и можно поддерживать команду с аргументами.

Синтаксис:

"HELP" [ SP String ] CRLF

4.1.1.9 Пустая операция (NOOP)

Эта команда не влияет на значения параметров и выполнение введенных ранее команд. По команде сервер просто передает отклик OK.

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

Синтаксис:

"NOOP" [ SP String ] CRLF

4.1.1.10 Завершение работы (QUIT)

Получив эту команду сервер должен возвратить отклик и OK закрыть канал передачи.

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

Команда QUIT может быть введена в любой момент.

Синтаксис:

"QUIT" CRLF

4.1.2 Синтаксис аргументов команд

Ниже приведен синтаксис полей аргументов перечисленных выше команд ( по возможности, используется синтаксис, описанный в работе [8]). Некоторые из приведенных ниже вариантов используются только с маршрутами source route, как описано в Приложении C. Обозначения, не определенные здесь (типа ALPHA, DIGIT, SP, CR, LF, CRLF), описаны в работе [8] (глава 6) или [32].

Reverse-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," A-d-l )
     ; отметим, что эта форма, называемая source route, должна приниматься,
     ; ее не следует генерировать и следует игнорировать.
At-domain = "@" domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-127)
   ; любые символы кроме =, SP и управляющих кодов
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
address-literal = "[" IPv4-address-literal /
                      IPv6-address-literal /
                      General-address-literal "]"
   ; См. параграф 4.1.3
Mailbox = Local-part "@" Domain
Local-part = Dot-string / Quoted-string
   ; регистр символов может различаться
Dot-string = Atom *("." Atom)
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
String = Atom / Quoted-string

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

Недопустимо определять почтовые ящики таким образом, чтобы в SMTP требовалось использование символов, не входящих в набор ASCII (октетов с 1 в старшем бите) или управляющих кодов ASCII (десятичные значения 0-31 и 127). Такие символы недопустимо использовать в командах MAIL и RCPT или других командах, содержащих имена почтовых ящиков.

Отметим, что обратный слэш (\) относится к символам квотирования, используемым для индикации буквального (literally) использования следующего символа (взамен обычной интерпретации). Например, запись «Joe\,Smith» соответствует “Joe, Smith”, т. е. Запятая после знака \ трактуется именно как запятая, а не специальный символ.

Для обеспечения интероперабельности и совместимости с DNS в именовании и приложениях (см., например, параграф 2.3.1 базового стандарта DNS — RFC1035 [22]) недопустимо включать в метки доменных имен для клиентов и серверов SMTP никакие символы, кроме букв латиницы, цифр и дефиса. В частности, символ подчеркивания (underscore) использовать нельзя. Серверы SMTP, получающие команды с некорректными символами (при отсутствии других причин для отказа), должны отвергать такие команды с возвратом отклика 501.

4.1.3 «Дословные» адреса

Иногда хост не знает доменного имени и почтовая связь (в частности, передача сообщений об ошибках) блокируется. Для решения этой проблемы в качестве альтернативы доменному имени может использоваться специальная форма адреса (literal address). Для адресов IPv4 эта форма использует десятичное представление байтов IP-адреса с разделением точками. Адреса заключаются в квадратные скобки (например, [123.255.37.2]), которые говорят об использовании адреса IPv4 в десятичном представлении с разделением точками. Для IPv6 и других форм адресации, которые могут быть впоследствии стандартизованы, форма включает стандартизованный тег, идентифицирующий синтаксис адреса, двоеточие (:) и собственно адрес в формате, заданном стандартом IPv6 [17].

В частности, используются следующие варианты:

IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; должен быть опубликован в RFC со статусом Standards-Track и
; зарегистрирован IANA
Snum = 1*3DIGIT ; десятичное целое от 0 до 255
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(":" IPv6-hex)
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" IPv6-hex)]
; :: представляет по крайней мере 2 16-битовых последовательности нулей
; в дополнение к :: может присутствовать не более 6 групп
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
[IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
; :: представляет по крайней мере две 16-битовых последовательности нулей
; в дополнение к :: может присутствовать не более 4 групп и
; IPv4-address-literal 

4.1.4 Порядок команд

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

Сеанс, который будет включать почтовую транзакцию, должен быть сначала инициализирован командой EHLO. Серверам SMTP следует воспринимать без инициализации команды, не использующие почтовых транзакций (например, VRFY или EXPN).

Команда EHLO может вводиться клиентом в действующем сеансе. При первом использовании команды в данной сессии сервер SMTP должен очистить все буферы и сбросить состояние, как при получении команды RSET. Иными словами, последовательность команд RSET — EHLO является избыточной, и малополезна ввиду выполнения ненужных повторяющихся действий.

Если команда EHLO неприемлема для сервера SMTP, он должен возвращать отклик 501, 500 или 502. Сервер SMTP должен сохранять после передачи таких откликов состояние, которое было до получения команды EHLO.

Клиент SMTP должен (по возможности) предоставлять в параметрах команд EHLO первичное доменное имя (не CNAME или MX) своего хоста.. Если это невозможно (например, клиент использует динамический адрес и не имеет явного имени), следует взамен имени использовать «дословный» адрес, предоставляя дополнительную информацию, которая поможет идентифицировать клиента.

Сервер SMTP может проверять соответствие доменного имени в команде EHLO реальному IP-адресу клиента. Однако для сервера недопустимо отвергать сообщение при несоответствии имени и адреса – результаты проверки могут использоваться только для протоколирования и трассировки.

Команды NOOP, HELP, EXPN, VRFY и RSET могут использоваться любой момент на протяжении всего сеанса и даже без предварительной организации сеанса. Серверам SMTP следует нормально обрабатывать эти команды (т. е., не выдавать в ответ отклик 503) даже в тех случаях, когда эти команды используются до получения команды EHLO; клиентам следует открывать сессию с помощью команды EHLO до ввода перечисленных команд.

Если следовать этим правилам, пример из RFC 821, показывающий отклик «550 access denied to you» в ответ на команду EXPN некорректен, если команда EHLO не была введена до EXPN или клиенту не было отказано в обслуживании на основе IP-адреса клиента или по результатам аутентификации или аналогичных механизмов.

Команда MAIL (или устаревшие команды SEND, SOML, SAML) начинает почтовую транзакцию. После начала транзакции последняя включает начальную команду, одну или несколько команд RCPT и команду DATA, вводимые в указанном порядке. Почтовая транзакция прерывается командой RSET (или новой командой EHLO). В сеансе может происходить множество последовательных транзакций или не быть транзакций вообще. Недопустимо передавать команду MAIL (или SEND, SOML, SAML), если почтовая транзакция уже открыта, т. е., эту команду можно передавать только при отсутствии в сеансе продолжающейся почтовой транзакции – предыдущая транзакция должна быть завершена успешным выполнением команды DATA или прервана командой RSET.

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

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

4.1.5 Команды частного использования

Как было сказано в параграфе 2.2.2, команды, начинающиеся с X, могут использоваться в результате двухстороннего соглашения между клиентом (отправитель) и сервером (получатель) SMTP. Предполагается, что сервер SMTP, не распознающий такие команды, будет возвращать отклик 500 Command not recognized. Сервер SMTP с расширенными функциями может перечислить имена, связанные с командами частного использования, в своем отклике на команду EHLO.

Команды, переданные или воспринятые системами SMTP и не начинающиеся с X, должны соответствовать требованиям параграфа 2.2.2.

4.2 Отклики SMTP

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

Отклик SMTP содержит трехзначный номер (передается как три числовых символа), за которым обычно следует строка текста, если в данной спецификации явно не указано иное. Числовые коды предназначены для автоматической обработки откликов, текст – для человека. Цифровой код обеспечивает требуемую информацию и программе-клиенту не требуется просматривать текстовую часть отклика, которую в результате можно просто отбрасывать или передавать пользователю. Имеющиеся исключения из этого правила явно указаны в спецификации. В частности, коды откликов 220, 221, 251, 421 и 551 связаны с текстовыми сообщениями, которые клиентская программа должна разбирать и интерпретировать. В общем случае текст может зависеть от сервера или текущего контекста, т. е., каждый оклик может содержать разный текст. Обсуждение теоретических вопросов генерации откликов приводится в параграфе 4.2.1. Формально отклик определяется как последовательность: трехзначный код, <SP>, строка текста, <CRLF> или многострочный текст (см. параграф 4.2.1). Поскольку (в нарушение данной спецификации) текст иногда не включается в отклик, получившим такой отклик клиентам следует быть готовыми к обработке только числового кода (возможно, после кода в отклик будет помещен символ пробела). Предполагается, что лишь команды EHLO, EXPN и HELP могут возвращать многострочные отклики при нормальных обстоятельствах, однако такие отклики допускаются для всех команд.

В формате ABNF отклик сервера имеет вид:

Greeting = "220 " Domain [ SP text ] CRLF
Reply-line = Reply-code [ SP text ] CRLF

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

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

Клиенты SMTP должны определять свои действия только на основе кода отклика, а не его текста (за исключением «change of address» 251 и 551, а при необходимости и 220, 221, 421). В общем случае клиент должны воспринимать любой текст и отклики без текста (хотя серверам не следует передавать откликов, содержащих только код). Пробел после кода отклика рассматривается как часть текста. По возможности клиенту SMTP следует проверять первую цифру кода отклика (индикация важности).

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

4.2.1 Важность кодов отклика и теоретические вопросы

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

Первая цифра кода может принимать 5 значений:

1yz – позитивный предварительный отклик

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

2yz – позитивный окончательный отклик

Запрошенная операция успешно завершена и могут вводиться новые команды.

3yz – позитивный промежуточный отклик

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

4yz – негативный отклик о временных проблемах

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

5yz — негативный отклик о постоянных проблемах

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

Вторая цифра отклика показывает категорию ошибки:

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

x1z Информация: отклик на запрос информации (например, справка или состояние).

x2z Соединение: отклики, относящиеся к каналу передачи.

x3z Не задан.

x4z Не задан.

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

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

Например, команды типа NOOP, при успешном завершении которых клиент SMTP не получает новой информации, будут возвращать код 250. Отклик 502 возвращается при запросе нереализованной команды, а отклик 504 – для реализованных команд с неподдерживаемыми параметрами.

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

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

Ниже приведен пример многострочного отклика:

123-Первая строка
123-Вторая строка
123-234 Текст, начинающийся с числа
123 Последняя строка

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

4.2.2 Коды откликов (по группам)

500	Syntax error, command unrecognized	Синтаксическая ошибка, команда не распознана (это может говорить о слишком длинной команде).
501	Syntax error in parameters or arguments	Синтаксическая ошибка в параметрах или аргументах.
502	Command not implemented	Команда не реализована (см. параграф 4.2.4).
503	Bad sequence of commands	Некорректный порядок команд.
504	Command parameter not implemented	Параметр команды не реализован.
211	System status, or system help reply	Отклик с системной справкой или состоянием системы.
214	Help message	Информация о работе с сервером или отдельных командах.
220	<domain> Service ready	Служба для указанного домена готова.
221	<domain> Service closing transmission channel	Закрывается канал передачи для указанного домена.
421	<domain> Service not available, closing transmission channel	Для указанного домена обслуживание невозможно и канал связи закрывается. Это может быть откликом на любую команду, если известно, что сервис должен быть отключен.
250	Requested mail action okay, completed	Операция благополучно завершена.
251	User not local; will forward to <forward-path>	Нелокальный пользователь – почта будет пересылаться по прямому пути (см. параграф 3.4).
252	Cannot VRFY user, but will accept message and attempt delivery	Не удается проверить почтовый ящик, но сообщение принято и сервер попытается его доставить (см. параграф 3.5.3).
450	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, занят).
550	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, почтовый ящик не найден, к нему нет доступа или команда отвергнута в соответствии с заданной политикой).
451	Requested action aborted: error in processing	Запрошенная операция прервана в результате ошибки.
551	User not local; please try <forward-path>	Нелокальный пользователь – попытайтесь использовать прямой путь (см. параграф 3.4).
452	Requested action not taken: insufficient system storage	Запрошенная операция не выполнена по причине нехватки пространства (на диске).
552	Requested mail action aborted: exceeded storage allocation	Запрошенная операция прервана по причине превышения выделенного (дискового) пространства.
553	Requested action not taken: mailbox name not allowed	Запрошенная операция не выполнена – недопустимый почтовый ящик (например, синтаксическая ошибка в имени ящика).
354	Start mail input; end with <CRLF>.<CRLF>	Начало ввода данных. Завершение по <CRLF>.<CRLF>.
554	Transaction failed или No SMTP service here	Отказ транзакции или отсутствие поддержки сервиса SMTP (при попытке соединения).

4.2.3 Коды откликов в порядке номеров

211	System status, or system help reply	Отклик с системной справкой или состоянием системы.
214	Help message	Информация о работе с сервером или отдельных командах.
220	<domain> Service ready	Служба для указанного домена готова.
221	<domain> Service closing transmission channel	Закрывается канал передачи для указанного домена.
250	Requested mail action okay, completed	Операция благополучно завершена.
251	User not local; will forward to <forward-path>	Нелокальный пользователь – почта будет пересылаться по прямому пути (см. параграф 3.4).
252	Cannot VRFY user, but will accept message and attempt delivery	Не удается проверить почтовый ящик, но сообщение принято и сервер попытается его доставить (см. параграф 3.5.3).
354	Start mail input; end with <CRLF>.<CRLF>	Начало ввода данных. Завершение по <CRLF>.<CRLF>.
421	<domain> Service not available, closing transmission channel	Для указанного домена обслуживание невозможно и канал связи закрывается. Это может быть откликом на любую команду, если известно, что сервис должен быть отключен.
450	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, занят)
451	Requested action aborted: error in processing	Запрошенная операция прервана в результате ошибки.
452	Requested action not taken: insufficient system storage	Запрошенная операция не выполнена по причине нехватки пространства (на диске).
500	Syntax error, command unrecognized	Синтаксическая ошибка, команда не распознана (это может говорить о слишком длинной команде).
501	Syntax error in parameters or arguments	Синтаксическая ошибка в параметрах или аргументах.
502	Command not implemented	Команда не реализована (см. параграф 4.2.4).
503	Bad sequence of commands	Некорректный порядок команд.
504	Command parameter not implemented	Параметр команды не реализован.
550	Requested mail action not taken: mailbox unavailable	Запрошенная операция невозможна – почтовый ящик недоступен (например, почтовый ящик не найден, к нему нет доступа или команда отвергнута в соответствии с заданной политикой).
551	User not local; please try <forward-path>	Нелокальный пользователь – попытайтесь использовать прямой путь (см. параграф 3.4).
552	Requested mail action aborted: exceeded storage allocation	Запрошенная операция прервана по причине превышения выделенного (дискового) пространства.
553	Requested action not taken: mailbox name not allowed	Запрошенная операция не выполнена – недопустимый почтовый ящик (например, синтаксическая ошибка в имени ящика).
554	Transaction failed или No SMTP service here	Отказ транзакции или отсутствие поддержки сервиса SMTP (при попытке соединения).

4.2.4 Отклик 502

У разработчиков часто возникают вопросы об использовании отклика 502 (Command not implemented – команда не реализована). Код 502 следует использовать в тех случаях, когда сервер SMTP распознал команду, но не умеет ее выполнять. Если команда не распознана, следует возвращать код 500. Для систем SMTP с расширенными функциями в откликах на команду EHLO недопустимо указывать команды, приводящие к отклику 502 или 500.

4.2.5 Коды откликов после DATA и последующих <CRLF>.<CRLF>

Когда сервер SMTP возвращает позитивный отклик (код 2yz) после завершения команды DATA с последовательностью <CRLF>.<CRLF>, этот сервер принимает на себя ответственность за следующие операции:

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

Когда сервер SMTP возвращает отклик о временных проблемах¹⁴ (4yz) после команды DATA с завершающей последовательностью <CRLF>.<CRLF>, недопустимо предпринимать какие-то последующие попытки доставки этого сообщения. Клиент SMTP сохраняет за собой ответственность за доставку этого сообщения и может возвратить его пользователю или снова поставить в очередь на доставку (см. параграф 4.5.4.1).

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

Когда сервер SMTP возвращает информацию о долгосрочных проблемах (код 5yz) после выполнения команды DATA с завершающей последовательностью <CRLF>.<CRLF>, недопустимо предпринимать какие-либо дополнительные попытки доставки сообщения. Как и для случая временных проблем, ответственность за доставку сообщения сохраняется за клиентом SMTP, но клиенту не следует пытаться повторить доставку тому же серверу без просмотра сообщения пользователем и внесения соответствующих изменений.

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

4.3.1 Обзор

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

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

Примечание. Все отклики-приветствия включают официальное имя хоста (FQDN), на котором работает сервер, в качестве первого слова после кода. В некоторых случаях у хоста может не быть собственного имени. Обсуждение альтернативных имен для таких ситуаций приводится в параграфе 4.1.3. Ниже приведены 3 примера приветствий:

220 ISIF.USC.EDU Service ready
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
220 [10.0.0.1] Clueless host service ready

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

4.3.2 Последовательности команда — отклик

Для каждой команды указаны обычные позитивные отклики. Используемые перед позитивными откликами префиксы включают I (промежуточный), S (успех) и E (ошибка). Поскольку некоторые серверы могут генерировать иные отклики в соответствующих обстоятельствах и с учетом возможности появления новых кодов, клиентам SMTP следует (по возможности) интерпретировать только первую цифру кода. Кроме того, клиент должен быть готов к работе с неизвестными кодами, также интерпретируя в них только первую цифру. За исключением расширений, использующих механизмы, описанные в параграфе 2.2, для серверов SMTP недопустима передача кодов, содержащих что-либо сверх 3 цифр или использующих цифры, не входящие в разрешенный диапазон 2 — 5 (включительно).

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

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

500 — для случая «command line too long» (слишком длинная команда) или при получении непонятной команды. Отметим, что отклик «command not recognized» (неизвестная команда) в ответ на команду из обязательного набора является нарушением данной спецификации.

501 Syntax error in command or arguments (синтаксическая ошибка в команде или аргументах). Для поддержки будущих расширений командам, включенным в данную спецификацию, как команды без аргументов (DATA, RSET, QUIT), следует возвращать отклик 501 при получении команды с аргументами, если иное не согласовано в анонсированном EHLO расширении.

421 Service shutting down and closing transmission channel — сервис отключен с разрывом коммуникационного канала.

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

Команда	Успех	Неудача
Организация соединения	220	554
EHLO или HELO	250	504, 550
MAIL	250	552, 451, 452, 550, 553, 503
RCPT	250, 25115	550, 551, 552, 553, 450, 451, 452, 503, 550
DATA (промежуточный отклик 354)	250	552, 554, 451, 452
DATA		451, 554, 503
RSET	250
VRFY	250, 251, 252	550, 551, 553, 502, 504
EXPN	250, 252	550, 500, 502, 504
HELP	211, 214	502, 504
NOOP	250
QUIT	221

4.4 Трассировочная информация

Когда сервер SMTP получает сообщение для доставки или дальнейшей обработки, он должен вставить трассировочную информацию (time stamp или Received) в начало содержимого, как описано в параграфе 4.1.1.4.

Трассировочная строка должна иметь следующую структуру:

• В поле FROM, которое должно обеспечиваться в среде SMTP, следует включать (1) имя хоста-отправителя, представленное в команде EHLO, и (2) IP-адрес отправителя, определенный из соединения TCP.
• Поле ID может включать «@», как предложено в RFC 822, но это необязательно.
• Поле FOR может содержать список элементов <path>, если используется множество команд RCPT. Это может влиять на безопасность системы и обычно нежелательно включать такие списки (см. параграф 7.2).

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

По мере расширения сети Internet просмотр строк Received становится все более важным средством диагностики почтовых систем, особенно для обнаружения медленно работающих трансляторов. Серверам SMTP, которые создают поля Received, следует явно задавать временной сдвиг (например, -0800), а не использовать имена часовых поясов. По возможности следует указывать локальное время (с учетом пояса), а не UT. Такая информация дает больше сведений о локальных условиях. Если требуется использовать UT, получателю достаточно использовать простую арифметику для получения нужного значения. Использование формата UT приводит к потере информации о часовом поясе сервера. Если желательно указывать имя часового пояса, его следует давать как комментарий.

Когда сервер SMTP обеспечивает «окончательную доставку» сообщения, он вставляет строку обратного пути (return-path) в начало почтовых данных. Использование return-path является обязательным и почтовые системы должны поддерживать это. Строка обратного пути сохраняет значение параметра <reverse-path> из команды MAIL. Окончательная доставка сообщения все еще сохраняет его в среде SMTP. Обычно сообщение доставляется в почтовый ящик пользователя или почтовое хранилище, но в некоторых случаях сообщение может подвергаться дополнительной обработке или передаваться другими почтовыми системами.

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

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

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

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

Основным назначением Return-path является указание адреса, по которому следует доставлять сообщения об ошибках. Для однозначности следует включать в сообщение единственный вариант обратного пути. Системам, использующим синтаксис RFC 822 с отличным от SMTP транспортом, следует указывать однозначный адрес, связанный с транспортным конвертом, по которому должна возвращаться информация об ошибках (например, о невозможности доставки).

Историческое замечание: Приведенные в RFC 822 сведения, отвергающие использование заголовка Return-path (или адреса возврата из команды MAIL в конверте) для доставки информации об ошибках, неприменимы в среде Internet. Адрес обратного пути (копируемый в Return-path) должен использоваться для доставки всех сообщений об ошибках в процессе доставки.

В частности:

• Шлюзам из SMTP в другие среды следует вставлять обратный путь, если у них нет информации о том, что другая среда также использует в адресах доменные имена Internet и поддерживает отдельный конверт с адресом отправителя.
• Шлюзам из других сред в SMTP следует удалять из заголовка строку обратного пути и копировать эту информацию в конверт SMTP или объединять ее с присутствующей в конверте информацией из другой транспортной системы для построения обратного пути для команды MAIL в конверте SMTP.

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

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

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

Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info ";" FWS date-time
; date-time определено в [32], но форма "obs-", особенно для 2-значного указания года
; запрещена в SMTP и ее использование недопустимо.
From-domain = "FROM" FWS Extended-Domain CFWS
By-domain = "BY" FWS Extended-Domain CFWS
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
TCP-info = Address-literal / ( Domain FWS Address-literal )
; сервер получает информацию из соединения TCP, а не из команды EHLO.
Opt-info = [Via] [With] [ID] [For]
Via = "VIA" FWS Link CFWS
With = "WITH" FWS Protocol CFWS
ID = "ID" FWS String / msg-id CFWS
For = "FOR" FWS 1*( Path / Mailbox ) CFWS
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; Дополнительные стандартные имена каналов регистрируются в IANA.
; Поле Via используется прежде всего для чужого транспорта (не Internet).
; Серверам SMTP недопустимо использовать незарегистрированные имена.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom

4.5 Другие вопросы реализации

4.5.1 Минимальная реализация

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

EHLO
HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
VRFY

Любые системы, которые включают сервер SMTP, поддерживающий трансляцию или доставку почты, должны поддерживать зарезервированный почтовый ящик postmaster, как независимое от регистра символов локальное имя. Без такого адреса можно обойтись, если сервер всегда возвращает отклик 554 на открытие соединений (см. параграф 3.1). Требование принимать почту для адресата postmaster, ведет к тому, что команды RCPT, указывающие адрес postmaster в любом из доменов, для которых сервер SMTP обеспечивает почтовое обслуживание, а также специальный случай команды RCPT TO:<Postmaster> (без указания домена), должны поддерживаться сервером.

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

4.5.2 Прозрачность

Без принятия некоторых специальных мер последовательность <CRLF>.<CRLF> будет восприниматься как завершение почтовых данных и не может включаться пользователем в текст. Обычно пользователи даже не знают о таких «запрещенных» последовательностях. Для прозрачной передачи подготовленного пользователем текста служат следующие процедуры:

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

Почтовые данные могут включать любые из 128 символов ASCII. Все символы доставляются в почтовый ящик получателя, включая пробелы, табуляторы и другие управляющие символы. Если канал передачи поддерживает 8-битовый (октетный) поток данных, 7-битовые коды ASCII передаются с выравниванием по правому краю октета и нулевым значением старшего бита. Трансляторы SMTP используют специальную трактовку 8-битовых символов (см. 3.7).

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

4.5.3 Размеры и тайм-ауты

4.5.3.1 Ограничения размеров

Существуют некоторые объекты, для которых требуется ограничение размера. Каждая реализация должна быть способна принимать объекты, размеры которых не выходят за эти ограничения. Следует (по возможности) избегать передачи объектов большего размера. Однако некоторые почтовые системы Internet создают такие адреса в формате X.400 [16], которые могут потребовать большего размера объектов – клиенты могут пытаться передать такие объекты, но они должны быть готовы к отказу серверов от обслуживания слишком больших объектов. Для снижения вероятности возникновения проблем в реализациях следует использовать методы, не ограничивающие размеры объектов.

локальная часть адреса

Максимальный размер имени пользователя или локальной части адреса составляет 64 символа.

домен

Максимальный размер доменного имени составляет 255 символов.

путь

Максимальная длина прямого и обратного пути составляет 256 символов (включая разделители и пунктуацию).

командная строка

Максимальная длина командной строки с учетом завершающей последовательности <CRLF> составляет 512 символов. Расширения SMTP могут разрешать более длинные команды.

строка отклика

Максимальная длина строки отклика с учетом кода и <CRLF> составляет 512 символов. Дополнительную информацию можно передать, используя многострочный отклик.

текстовая строка

Максимальная длина строки текста с учетом <CRLF> составляет 1000 символов (без учета добавляемую для обеспечения прозрачности точки в начале). Расширения SMTP могут использовать более длинные строки.

содержимое сообщения

Ограничение максимального размера содержимого сообщения (включая заголовки и тело) должно быть не менее 64K октетов. После введения стандартов Internet на multimedia-почту [12] размеры почтовых сообщений Internet многократно возросли и по возможности следует избегать ограничения размера сообщений. Системам SMTP, которые не могут отказаться от ограничения размеров следует реализовать сервисное расширение SIZE [18], а клиентам SMTP, передающим большие сообщения, следует по возможности использовать это расширение.

буфер адресатов

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

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

500 Line too long – слишком длинная строка
501 Path too long – слишком длинный путь
452 Too many recipients – слишком много получателей (см. ниже)
552 Too much mail data – слишком много почтовых данных.

В RFC 821 [30] некорректно указано, что сервер SMTP в случаях превышения числа команд RCPT (too many recipients) генерирует отклик с кодом 552. Корректным кодом для таких откликов является 452. Клиентам следует трактовать код 552 в таких случаях как временную проблему, а не постоянную, чтобы описанная ниже логика могла работать.

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

Если сервер SMTP имеет предел для числа команд RCPT и этот предел превышен, сервер должен использовать отклик с кодом 452 (но клиенту следует быть готовым и к получению кода 552, как было указано выше). Если ограничения сервера заданы правилами, он может использовать отклик с кодом 5XX. Это будет наиболее разумным решением, если ограничение предназначено для блокировки передачи сообщений, в которых список получателей по размеру превышает само сообщение.

4.5.3.2 Тайм-ауты

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

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

Стартовое сообщение 220: 5 минут

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

Команда MAIL: 5 минут

Команда RCPT: 5 минут

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

Инициирование команды DATA: 2 минуты

Этот тайм-аут определяет время ожидания отклика 354 Start Input на команду DATA.

Блок данных: 3 минуты

Время ожидания завершения каждого вызова TCP SEND для передачи блока данных.

Завершение приема данных по команде DATA: 10 минут.

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

Серверам SMTP следует использовать тайм-аут не менее 5 минут при ожидании от клиента следующей команды.

4.5.4 Стратегия повторов

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

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

4.5.4.1 Стратегия передачи

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

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

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

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

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

Клиент SMTP может сократить задержку перед повтором, согласовав такое совращение с сервером SMTP. Например, при получении почты с какого-то адреса очевидна возможность передачи по этому адресу почты из очереди (если она есть). Применяя такой подход, приложение в большинстве случаев может обойтись без явного использования функций «передать сообщения из очереди сейчас» типа ETRN [9].

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

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

В то же время, клиентам SMTP следует с большой осторожностью использовать кэшированные негативные отклики от серверов. В экстремальном случае, если команда EHLO вводится много раз в течение одного соединения SMTP, сервер может возвращать разные отклики. Очень важно подчеркнуть, что отклики 5yz на команду MAIL недопустимо кэшировать.

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

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

4.5.4.2 Стратегия приема

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

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

4.5.5 Сообщения с пустым полем обратного пути

Некоторые типы уведомлений, требуемые существующими или предложенными стандартами, передаются с пустым полем обратного пути. К числу таких сообщений относятся уведомления об ошибках при доставке (см. параграф 3.7), другие типы сообщений DSN (Delivery Status Notifications – уведомления о состоянии доставки) [24] и сообщения MDN (Message Disposition Notifications – уведомления о диспозиции сообщений) [10]. Все типы указанных сообщений являются уведомлениями о предыдущем сообщении и посылаются по обратному пути из заголовка письма, с которым связано данное уведомление. Невозможность доставки зачастую связана с проблемами в почтовой системе на хосте адресата, поэтому некоторые АДП настраиваются на пересылку таких уведомлений кому-нибудь, кто будет способен исправить проблему с почтой (например, с использованием псевдонима postmaster).

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

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

5. Преобразование адресов и обслуживание почты

После того, как клиент SMTP лексически идентифицирует домен, для которого предназначена передаваемая на обработку почта (см. параграфы 3.6 и 3.7), должно выполняться обращение к серверу доменных имен (DNS lookup) для преобразования доменного имени [22]. Предполагается, что в адресах используются полные имена (FQDN) – механизм определения FQDN по частичному имени или локальному псевдониму выходит за пределы данной спецификации и, в силу сложившейся практики, в общем случае не должен использоваться. При поиске сначала предпринимается попытка найти локальную запись MX, связанную с именем. Если взамен этого будет найдена запись CNAME, полученное в результате имя обрабатывается как исходное. При отсутствии записей MX одновременно с наличием записей A, последняя трактуется, как будто она связана с реальной записью MX 0, указывающей на тот же хост. Если для данного имени найдена одна или несколько записей MX, для системы SMTP недопустимо использовать какие-либо записи A, связанные с этим именем, пока они не найдены с использованием записей MX; приведенное выше правило неявных записей MX применимо только в случаях отсутствия реальных MX. Если записи MX присутствуют, но ни одна из них не может быть использована, должно генерироваться сообщение об ошибке.

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

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

Хост получателя (возможно с предпочтительной записью MX) может оказаться многодомным – в таких случаях доменное имя будет преобразовываться в список адресов IP. Ответственность за упорядочивание этого списка лежит на интерфейсе преобразователя имен (domain name resolver), который должен упорядочивать список в порядке снижения предпочтений, а отправитель SMTP должен пытаться использовать адреса в предложенном порядке.

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

Если сервер SMTP принимает сообщение, для адресата которого данный сервер означен в записи MX, этот сервер может транслировать сообщение (потенциально, после получения переписанных адресов для MAIL FROM и/или RCPT TO), обеспечивая его окончательную доставку, или передать его дальше, используя тот или иной механизм, не относящийся к транспортной среде SMTP. Естественно, для второго случая сначала должен быть проверен список записей MX.

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

6. Обнаружение и решение проблем

6.1 Гарантированная доставка и отклики по электронной почте

Когда получатель SMTP принимает порцию почты (передав отклик 250 OK в ответ на команду DATA), он принимает на себя ответственность за доставку или трансляцию сообщения. К этой ответственности следует относиться серьезно. Недопустима потеря сообщений по незначительным причинам, типа последующего «падения» хоста или предсказуемой нехватки ресурсов.

Если после восприятия сообщения обнаруживается невозможность его доставки, получатель SMTP должен подготовить и передать уведомление об этом. При передаче уведомления должен использоваться пустой («<>») путь возврата в конверте. Получателем такого уведомления должен быть адрес из обратного пути в конверте (или строке Return-Path:). Если обратный путь пустой («<>»), для сервера SMTP недопустима передача уведомления. Обычно, ничто не запрещает на локальном уровне (в той же среде, к которой относится получатель SMTP) принимать решение о протоколировании или иной фиксации сведений о пустом пути возврата. Если адресом является явный маршрут source route, из него должен выделяться последний интервал (final hop).

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

MAIL FROM:<@a,@b:user@d>

Уведомление должно передаваться с помощью команды:

RCPT TO:<user@d>

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

Во избежание дублирования сообщений в результате тайм-аутов, получатель SMTP должен пытаться минимизировать время отклика на индикатор завершения данных <CRLF>.<CRLF>. Подробное обсуждение этого вопроса приводится в RFC 1047 [28].

6.2 Обнаружение петель

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

6.3 Компенсация отклонений от стандартов

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

Проблемы, связанные с некорректным форматом сообщений, обострились после введения специальных протоколов для чтения (загрузки) почты с серверов [3, 26, 5, 21]. Эти протоколы поддерживают использование SMTP в качестве протокола передачи (представления сообщений) и серверов SMTP для трансляции почты на хосты клиентов этих протоколов (которые часто не имеют прямого постоянного подключения к Internet). Исторически многие из таких хостов не поддерживают часть механизмов и данных, используемых SMTP (и протоколом почтовых форматов [7]). Некоторые могут не сохранять значение текущего времени, другие не понимают часовых поясов, третьи не знают своего имени и, конечно, ни один из таких хостов не может удовлетворять тем требованиям, которые заложены в концепцию заверенных адресов RFC 822.

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

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

• добавление поля message-id при его отсутствии;
• добавление даты, времени и часового пояса при их отсутствии;
• корректировка адреса в соответствии с форматом FQDN.

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

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

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

7.1 Безопасность почты и обманки

Природа почты SMTP не обеспечивает безопасности, поскольку любой пользователь может напрямую взаимодействовать с принимающим или транслирующим сервером SMTP, создавать сообщения и обманывать простодушных получателей, полагающих, что это почта от кого-то другого. Создание таких сообщений, обманный характер которых не обнаруживается, – задача более сложная, но вполне посильная для людей с нужными знаниями и соответствующей мотивацией. Следовательно, по мере повышения уровня знаний в сфере почты Internet человек начинает понимать, что почта SMTP не может быть заверена на транспортном уровне, равно как не обеспечивается и проверка целостности почты. Реальная безопасность почты обеспечивается только сквозными методами, включающими контроля тела сообщения, использования цифровых подписей и т. п. (см. [14], PGP [4], S/MIME [31]).

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

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

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

7.2 Скрытые копии — BC

В передаваемых серверу SMTP командах RCPT могут присутствовать адреса, по тем или иным причинам не указанные в заголовке сообщения. Двумя основными случаями являются использование почтового адреса, как «детонатора» списка (один адрес преобразуется во множество адресов реальных получателей) и скрытых копий (blind copy – или bc). В тех случаях, когда используется более одной команды RCPT и во избежание подавления некоторых функций этих механизмов, клиентам и серверам SMTP не следует копировать весь набор аргументов команды RCPT в заголовки, как часть трассировочных полей, информационных полей или заголовков частного расширения. Поскольку на практике это правило часто нарушается и его выполнение не может быть обеспечено принудительно, передающие системы SMTP, которые знают об использовании bcc, могут счесть полезной передачу каждой скрытой копии в отдельной транзакции с единственной командой RCPT.

Не существует неразрывных отношений между обратным (из команд MAIL, SAML и т. п.) или прямым (RCPT) адресом в транзакции SMTP (конверте) и адресами в заголовке. Принимающим системам не следует пытаться найти такие соотношения и использовать их для изменения заголовков с целью доставки сообщения. Популярный заголовок Apparently-to (видимо для) является нарушением данного принципа и хорошо известным случаем непреднамеренного разглашения информации; не следует пользоваться этим заголовком.

7.3 VRFY, EXPN и безопасность

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

Возврат кода 250 в ответ на команду VRFY после проверки лишь синтаксиса команды (а не указанного адреса), является нарушением этого правила. Естественно, что реализации, «поддерживающие» команду VRFY, которые всегда будут возвращать отклик 550 независимо от корректности адреса, также нарушают это правило.

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

7.4 Разглашение информации в анонсах

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

7.5 Разглашение информации в полях трассировки

В некоторых обстоятельствах (например, при доставке почты в локальной сети, хосты которой не подключены к Internet напрямую), поля трассировки (Received), вносимые в соответствии с данной спецификацией, могут содержать имена хостов и другую информацию, которую не следует разглашать. Обычно это не создает проблем, но для сайтов с высокими требованиями к вопросу разглашения имен это может иметь важное значение. Дополнительные операторы FOR также следует использовать с осторожностью или не использовать совсем в тех случаях, когда многочисленные получатели могут непреднамеренно передать информацию о скрытых получателях (blind copy — bc) другим.

7.6 Разглашение информации при пересылке сообщений

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

7.7 Свобода действий сервера SMTP

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

В последние годы использование функций трансляции на случайных сайтах стало применяться как способ сокрытия истинного происхождения почты. Некоторые сайты в результате стали предоставлять функции трансляции только известным или идентифицируемым отправителям и разработчикам следует обеспечивать в программах возможность такой фильтрации. Когда почта отвергается по тем или иным причинам, определяемым политикой сайта, следует использовать код 550 в откликах на команды EHLO, MAIL или RCPT.

8. Регистрация в IANA

Агентство IANA поддерживает три реестра, связанных с данной спецификацией. Первый реестр включает сервисные расширения SMTP и связанные с ними ключевые слова, а также (при необходимости) команды и их параметры. Как сказано в параграфе 2.2.2, ни одна из записей этого реестра не может начинаться с X. Записи могут создаваться только для расширений сервиса (и связанных с ними ключевых слов, параметров и команд), которые определены в стандартах или экспериментальных RFC, одобренных IESG для таких задач.

Второй реестр содержит теги, идентифицирующие «дословные» формы записи имен, отличные от адресов IPv4 (эта форма включена в RFC 821 и настоящую спецификацию) и IPv6 (включена в эту спецификацию). Для использования дополнительных вариантов «дословного» представления требуется стандартизация, которой в настоящее время нет ни для одного из них.

Третий реестр, основанный RFC 821 и обновленный данной спецификацией, содержит идентификаторы каналов и протоколов, которые могут использоваться в субоператорах via и with трассировочных строк (заголовки Received:), описанных в параграфе 4.4. Идентификаторы каналов и протоколов в дополнение к указанным в этой спецификации могут регистрироваться только путем стандартизации или через экспериментальные расширения протоколов (RFC, одобренные IESG).

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

[1] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, «USA Code for Information Interchange». ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.

[2] Braden, R., «Requirements for Internet hosts — application and support», STD 3, RFC 1123, October 1989.

[3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. Reynolds, «Post Office Protocol — version 2», RFC 937, February 1985.

[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, «OpenPGP Message Format», RFC 2440, November 1998.

[5] Crispin, M., «Interactive Mail Access Protocol — Version 2», RFC 1176, August 1990.

[6] Crispin, M., «Internet Message Access Protocol — Version 4», RFC 2060, December 1996.

[7] Crocker, D., «Standard for the Format of ARPA Internet Text Messages», RFC 822, August 1982.

[8] Crocker, D. and P. Overell, Eds., «Augmented BNF for Syntax Specifications: ABNF», RFC 2234, November 1997.

[9] De Winter, J., «SMTP Service Extension for Remote Message Queue Starting», RFC 1985, August 1996.

[10] Fajman, R., «An Extensible Message Format for Message Disposition Notifications», RFC 2298, March 1998.

[11] Freed, N, «Behavior of and Requirements for Internet Firewalls», RFC 2979, October 2000.

[12] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, December 1996.

[13] Freed, N., «SMTP Service Extension for Command Pipelining», RFC 2920, September 2000.

[14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, «Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted», RFC 1847, October 1995.

[15] Gellens, R. and J. Klensin, «Message Submission», RFC 2476, December 1998.

[16] Kille, S., «Mapping between X.400 and RFC822/MIME», RFC 2156, January 1998.

[17] Hinden, R and S. Deering, Eds. «IP Version 6 Addressing Architecture», RFC 2373, July 1998.

[18] Klensin, J., Freed, N. and K. Moore, «SMTP Service Extension for Message Size Declaration», STD 10, RFC 1870, November 1995.

[19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, «SMTP Service Extensions», STD 10, RFC 1869, November 1995.

[20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, «SMTP Service Extension for 8bit-MIMEtransport», RFC 1652, July 1994.

[21] Lambert, M., «PCMAIL: A distributed mail system for personal computers», RFC 1056, July 1988.

[22] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[23] Moore, K., «MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text», RFC 2047, December 1996.

[24] Moore, K., «SMTP Service Extension for Delivery Status Notifications», RFC 1891, January 1996.

[25] Moore, K., and G. Vaudreuil, «An Extensible Message Format for Delivery Status Notifications», RFC 1894, January 1996.

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

[27] Partridge, C., «Mail routing and the domain system», RFC 974, January 1986.

[28] Partridge, C., «Duplicate messages and SMTP», RFC 1047, February 1988.

[29] Postel, J., ed., «Transmission Control Protocol — DARPA Internet Program Protocol Specification», STD 7, RFC 793, September 1981.

[30] Postel, J., «Simple Mail Transfer Protocol», RFC 821, August 1982.

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

[32] Resnick, P., Ed., «Internet Message Format», RFC 2822, April 2001.

[33] Vaudreuil, G., «SMTP Service Extensions for Transmission of Large and Binary MIME Messages», RFC 1830, August 1995.

[34] Vaudreuil, G., «Enhanced Mail System Status Codes», RFC 1893, January 1996.

10. Адрес редактора

John C. Klensin

AT&T Laboratories

99 Bedford St

Boston, MA 02111 USA

Phone: 617-574-3076

EMail: klensin@research.att.com

---

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

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

nmalykh@protokols.ru

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

В долгом и трудном процессе подготовки этого документа приняло участие много людей. Долгое обсуждение с участием большого числа людей велось в рабочей группе IETF DRUMS (как в личных беседах, так и с использованием рассылок) по различным техническим вопросам и роли пересмотренного стандарта в почтовой системе Internet – многие участники этих дискуссий помогли в разработке окончательного варианта спецификации. Сотни участников дискуссий, длящихся с момента выхода RFC 821, трудно перечислить здесь, но все они внесли свой вклад в подготовку спецификации.

Приложения

A. Транспортный сервис TCP

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

B. Генерация команд SMTP из заголовков RFC 822

Некоторые системы используют заголовки RFC 822 (только) в протоколах представления почты, а в остальных случаях генерируют команды SMTP на основе заголовков RFC 822, когда такие сообщения передаются АДП (MTA) от агентов ППА (MUA). Поскольку протокол взаимодействия АДП – ППА является частным и не задается стандартами Internet, в таких случаях могут возникать проблемы. Например, проблемы могут возникать при обработке копий bcc и перераспределении списков, когда информация, потенциально относящаяся к почтовому конверту, не отделяется в процессе обработки от информации из заголовков и не хранится отдельно от нее.

Агентам ППА рекомендуется предоставлять своему первому АДП (submission client) конверт отдельно от сообщения. Однако, если конверты не поддерживаются, следует генерировать команды SMTP, используя приведенные правила:

1. Каждый адрес получателя из полей заголовка TO, CC, BCC следует копировать в команду RCPT (генерируя, при необходимости, нужное число копий сообщения для помещения в очередь или доставки). Сюда включаются все адреса, перечисленные в «группе» RFC 822. Все поля BCC следует удалять из заголовков. После завершения такой обработки оставшиеся поля заголовков следует проверить, чтобы убедиться, что осталось хотя бы одно поле To:, Cc:, Bcc:. При отсутствии следует поместить в заголовок поле BCC без дополнительной информации, как указано в работе [32].
2. Адрес возврата в команде MAIL следует (по возможности) получать из системной идентификации представляющего почту (локального) пользователя или из поля From:. При доступности системной идентификации, эти данные следует также копировать в поле заголовка Sender, если информация отличается от адреса в поле From (все имеющиеся поля Sender следует удалить). Система может позволять представляющим почту пользователям переписывать адрес возврата в конверте, но можно ограничить доступ к этому только привилегированными пользователями. Это не предотвращает подмены почтовых адресов, но осложняет такую подмену (см. параграф 7.1).

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

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

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

C. Маршруты Source Route

Исторически поле <reverse-path> содержало в source routing список промежуточных хостов и имя почтового ящика отправителя. Первым в списке <reverse-path> следует указывать хост, подавший команду MAIL. Подобно этому поле <forward-path> может быть списком хостов source routing и адреса получателя. Однако, в общем случае, в поле <forward-path> следует включать только почтовый ящик и доменное имя получателя, отдавая решение задачи маршрутизации почты на откуп системе DNS. Использование явных маршрутов осуждается — хотя серверы должны быть готовы к получению и обработке таких маршрутов (см. 3.3 и F.2), клиентам не следует передавать явные маршруты.

Для целей трансляции прямой путь может быть маршрутом source route в форме @ONE,@TWO:JOE@THREE, где ONE, TWO, THREE должны быть полными доменными именами. Такая форма используется для того, чтобы можно было отличить адреса от маршрутов. Почтовый ящик (в данном случае, JOE@THREE) представляет собой абсолютный адрес, а маршрут — информацию для доставки. Эти понятия не следует путать.

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

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

Отметим, что прямой и обратный пути появляются в командах и откликах SMTP, но не являются необходимыми в сообщении (т. е., нет необходимости включения таких путей и особенно описанного здесь синтаксиса в поля To:, From:, CC: и т. п.). И наоборот, для серверов SMTP недопустимо получать информацию на основе этих полей при окончательной доставке сообщения.

При наличии списка хостов он является «обратным» маршрутом source route и показывает, что почта транслировалась через каждый хост в списке (первым в списке указан последний по времени транслятор). Этот список используется как source route для возврата отправителю уведомлений о невозможности доставки. Когда каждый транслятор добавляет себя в начало списка, он должен использовать имя, которое известно в транспортной среде, куда транслируется почта, а не в среде, откуда почта поступила (если эти имена различаются).

D. Сценарии

В этом приложении приведено несколько примеров полных сценариев сеансов SMTP. Знаком C: обозначается отправитель (клиент SMTP), а знаком S: — сервер SMTP.

D.1 Сценарий типичной транзакции SMTP

Рассматриваемый ниже пример показывает передачу сообщения, отправленного Смитом (Smith) с хоста bar.com адресатам Jones, Green, Brown на foo.com. Предполагается, что bar.com контактирует с foo.com напрямую. Почта для Jones и Brown принимается, а Green не имеет почтового ящика на foo.com.

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

D.2 Сценарий прерванной транзакции SMTP

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RSET
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

D.3 Сценарий с трансляцией

Этап 1 — Отправитель -> транслятор.

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<@foo.com:Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

Этап 2 — Транслятор -> конечный получатель

S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<@foo.com:JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

D.4 Сценарий проверки и передачи

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250-VRFY
S: 250 HELP
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: SEND FROM:<EAK@bar.com>
S: 250 OK
C: RCPT TO:<Admin.MRC@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

E. Другие вопросы, связанные со шлюзами

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

F. Отмененные возможности RFC 821

Некоторые возможности RFC 821 признаны проблематичными и их не следует использовать в почте Internet.

F.1 Команда TURN

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

F.2 Задаваемая отправителем маршрутизация

RFC 821 использует концепцию явного задания маршрута отправителем для доставки почты с одного хоста на другой через промежуточные трансляторы. Необходимость использования такой маршрутизации в обычной почте отпала после появления в DNS записей MX. Существенный вклад в отказ от такой маршрутизации внес документ RFC 1123, в соответствии с которым после символа @ в адресе должно указываться полное доменное имя (FQDN). Следовательно, единственной причиной поддержки source route является интероперабельность со старыми клиентами SMTP или агентами MUA, а также отладка почтовых систем. Однако такая маршрутизация может быть полезна при возникновении серьезных проблем временного характера (типа релевантности записей DNS).

Серверы SMTP должны продолжать восприятие синтаксиса source route в соответствии с данной спецификацией и RFC 1123. При необходимости серверы могут игнорировать явные маршруты, используя из адреса только доменное имя. При использовании source route сообщение должно пересылаться в первый указанный в адресе домен. В частности, для серверов недопустимо сокращение маршрута source route.

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

F.3 Команда HELO

Как было указано в параграфах 3.1 и 4.1.1, команда EHLO является более предпочтительной, нежели устаревшая команда HELO. Серверы должны принимать и обрабатывать команды HELO для поддержки старых клиентов.

F.4 #-литералы

В RFC 821 указана возможность задания адресов Internet с помощью десятичного представления номера хоста с префиксом #. На практике с появлением TCP/IP актуальность такого представления была утрачена. В настоящее время этот вариант осуждается и недопустим для использования.

F.5 Даты и годы

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

F.6 Дополнительные команды прямой передачи

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

Клиентам не следует предоставлять услуги SEND, SAML или SOML, но серверы их могут реализовать. При реализации этих служб сервером должна использоваться модель, приведенная в спецификации RFC 821, а имена команд должны публиковаться в отклике на команду EHLO.

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

Copyright (C) The Internet Society (2001). Все права защищены.

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

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

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

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

Финансирование функций RFC Editor обеспечено Internet Society.