Опубликован: 30.07.2013 | Уровень: для всех | Доступ: платный
Лекция 7:

Приложения протокола розыска соседей

Чтобы помочь администратору в согласовании параметров, каждому маршрутизатору рекомендовано следить за объявлениями соседей, сравнивать их со своими и сообщать в системном журнале о найденных противоречиях [§6.2.7 RFC 4861].

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

Между тем, один префикс может включать в себя другой. Например, двоичный префикс 01 содержится в префиксе 0100, а префикс IPv6 2001:DB8::/32 — в префиксе 2001:DB8::/48. При этом префикс большей длины точнее, так как ему отвечает меньшее множество адресов. Когда такие префиксы находятся на одном канале, это тривиальный случай: множество адресов короткого префикса полностью содержит в себе множество адресов длинного префикса. Тем не менее, это разные префиксы, у каждого из которых свой набор флагов и свое время жизни. Например, префикс "на канале" 2001:DB8::/32 может устареть раньше, чем 2001:DB8::/48, и тогда адреса, составляющие разность этих множеств, окажутся "вне канала".

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

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

От засылки извне канала пакеты RS и RA защищены при помощи GTSM: поле "предельное число шагов" в них обязано равняться 255 — см. §5.1.

Маршрутизатору не возбраняется всегда направлять объявления RA по адресу "все узлы канала" независимо от того, шлет ли он это объявление по таймеру или по вызову [§6.2.6 RFC 4861, §5.5.1 RFC 4862]. Так злоумышленник или даже просто сбойный хост сможет вызвать целую бурю группового трафика. Чтобы этого не произошло, каждый маршрутизатор обязан ограничить частоту своих объявлений RA12 Параметр MIN_DELAY_BETWEEN_RAS, 3 с [§6.2.6 RFC 4861]. .

Тем не менее, проблема нежелательной синхронизации RA остается. С ней надо бороться, сделав время отправки RA случайным. Если RA по вызову, то надо внести случайную задержку, а если по таймеру, то достаточно сделать его интервал случайным [§6.2.4 и §6.2.6 RFC 4861]. Последний штрих состоит в том, чтобы вообще не слать RA по вызову, если задержка помещает его на оси времени после ближайшего RA по таймеру. Благодаря этим предосторожностям, групповая рассылка объявлений RA не повредит каналу даже при возникновении сбойных или злонамеренных хостов.

Интересно, что разные периодические события в сети неожиданно проявляют склонность к самопроизвольной синхронизации во времени13S. Floyd, V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, April 1994. http://ee.lbl.gov/papers/sync_94.pdf , и чаще всего это нежелательное явление. Поэтому приходится явным образом вносить случайность в длины задержек и прочие подобные параметры протоколов, как мы это сделали для ReachableTime в §5.1. В свою очередь, хорошее качество случайных величин можно обеспечить, только опираясь на теоретическую базу; действовать наобум здесь нельзя [RFC 4086].

Последний вопрос, связанный с розыском маршрутизаторов, заключается в том, может ли узел IPv6 впоследствии отказаться от роли маршрутизатора. Согласно общепринятой модели [§6.2.1 RFC 4861], маршрутизатор IPv6 — это функция узла, которую можно избирательно включить или выключить на каждом из его сетевых интерфейсов, при условии что узел вообще способен быть маршрутизатором. Из соображений устойчивости и безопасности, по умолчанию эта функция выключена.

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

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

Однако в памяти хостов все еще остаются записи DC, которые указывают на узел М. Подобные записи могли возникнуть, даже если М не был маршрутизатором по умолчанию, а значит, их нельзя убрать объявлением RA. Например, эти записи могли быть созданы по переадресовке другого маршрутизатора Н. В результате окажется, что хосты продолжают слать транзитный трафик через узел М, хотя тот его просто игнорирует. Если бы узел М вообще исчез, то сработал бы механизм NUD, и хосты бы вычистили устаревшие записи DC, связанные с недоступным соседом. Но в нашем случае узел М будет по-прежнему доступен, и образуется "черная дыра".

Чтобы разрешить это затруднение, нам пригодится флаг R в объявлении NA, который мы предварительно зарезервировали. Пусть узел устанавливает этот флаг в своих сообщениях NA, когда он маршрутизатор на данном интерфейсе, и сбрасывает, когда он просто хост. Тогда хосты-соседи смогут более надежно узнать об отказе узла М продвигать транзитный трафик. Как только флаг R в его сообщениях NA обнулится, полагается вычистить все записи DC, указывающие на узел М, потому что он добровольно сложил с себя полномочия маршрутизатора [§7.2.5 RFC 4861].

Таким образом, оказывается, что хост IPv6 должен следить не только за доступностью соседей, но и за их состоянием "хост/маршрутизатор". Этой цели служит булево поле IsRouter в эталонной записи NC [§5.1 RFC 4861].

Определить, что сосед — маршрутизатор, хост может по прямым или косвенным признакам [Приложение D RFC 4861]. Прямой признак один, это флаг R в объявлении NA, тогда как косвенных признаков несколько. Скажем, получение объявления RA от соседа говорит о том, что он — маршрутизатор. На то же самое указывает переадресовка на соседа, если это переадресовка на маршрутизатор (адрес цели не совпадает с адресом назначения). (Переадресовку от соседа хост может получить, только если он уже использует его как маршрутизатор.) Косвенные признаки, в отличие от прямого, не могут подтвердить обратное, а именно что сосед — это хост, а не маршрутизатор.

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

  1. преобразует канальный адрес интерфейса в идентификатор интерфейса IPv6 длины N;

    Еще раз напомним себе, что N = 64 — это чисто административное решение, которое не следует "зашивать" в протоколы стека IPv6. Строго говоря, хост не обязан использовать канальный адрес интерфейса при выборе его идентификатора IPv6 [Приложение A RFC 4291], однако это повсеместная практика, если канальный адрес у интерфейса имеется.
  2. создает пробный внутриканальный адрес IPv6, сцепляя префикс FE80::/(128-N) и идентификатор интерфейса, полученный на шаге №1;
  3. проверяет пробный внутриканальный адрес на уникальность с помощью DAD;
  4. если адрес уникальный, назначает его интерфейсу и устанавливает для него бесконечные времена жизни. В противном случае работа IPv6 через данный интерфейс невозможна и происходит останов процедуры [§5.4.5 RFC 4862];
  5. возможно, посылает вызов RS группе "все маршрутизаторы канала", FF02::2;
  6. по мере получения объявлений RA сканирует опции PIO [§5.5.3 RFC 4862]:

    а)

    игнорирует опцию, если в ней сброшен флаг A;

    Опция PIO с A = 0 может пригодиться для заполнения списка префиксов "на канале", если у нее L = 1; но мы сейчас говорим только об автоматическом назначении адресов сетевому интерфейсу.

    б)

    игнорирует опцию, если префикс внутриканальный;

    в)

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

    г)

    если префикс еще не назначен:

    i)

    игнорирует префикс, если сумма длин префикса и идентификатора интерфейса не равна длине адреса IPv6, 128 бит;

    ii)

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

    iii)

    создает пробный адрес, сцепляя префикс из RA и идентификатор интерфейса из шага №1;

    iv)

    проверяет пробный адрес на уникальность с помощью DAD;

    v)

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

    д)

    иначе, если префикс уже назначен в составе ранее созданного адреса:

    i)

    устанавливает предпочтительное время жизни адреса согласно опции;

    ii)

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

Хотя вопрос о безопасности ND мы еще не обсуждали, уже сейчас понятно, что без дополнительных механизмов защиты сообщения ND уязвимы к обычной подделке. Подделка RA, помимо прочего, позволяет провести очень простую атаку типа "отказ в обслуживании", когда хост получает RA, в котором действительное время жизни его текущих префиксов очень короткое. В результате хост сбрасывает свои адреса и некоторое время остается полностью недоступен. Обратите внимание, что хост не нужно "бомбардировать" — достаточно единственного фальшивого RA. Чтобы блокировать этот вектор атаки, стоит ограничить возможность RA сокращать действительное время жизни адресов [§5.5.3 RFC 4862]. Суть этого ограничения довольно проста, ее иллюстрирует рис. 6.14. Прежде всего, RA может беспрепятственно удлинять время жизни адреса. Например, если к приходу RA адресу оставалось жить 5 минут, а новое время жизни 10 минут, то таймер адреса будет установлен на 10 минут. Если же RA на самом деле пытается сократить время жизни адреса, то оно может укоротить его только до 2 часов. К примеру, если адресу оставалось жить 1 час, а новое время жизни 10 минут, то адрес проживет целый час. Если адресу оставалось жить 3 часа, а новое время жизни 45 минут, то адрес проживет 2 часа. И только если новое время жизни больше 2 часов, оно вступит в силу как есть. Когда у нас появится надежная защита сообщений RA от подделки, это ограничение можно будет снять. Иными словами, ограничение действует только на те сообщения RA, подлинность которых никак не подтверждена. Кроме того, оно действует только на действительное время жизни как наиболее уязвимый параметр, тогда как предпочтительным временем жизни адресов можно управлять без ограничений.

 Защита от атаки на время жизни адреса

Рис. 6.14. Защита от атаки на время жизни адреса

Хост выполняет шаг 6 в фоне, пока интерфейс активен, так как периодические объявления RA сообщают текущую конфигурацию данного канала, а она может изменяться по желанию администратора сети. Маршрутизатор может сам назначить своим интерфейсам внутриканальные адреса, выполнив шаги 1–4; шаги 5 и далее — только для хостов [§4 RFC 4862].

У такого механизма автоматической настройки адресов есть одна любопытная особенность: ни маршрутизатор, ни хост не фиксируют назначение адреса в долговременной памяти. Когда хост включают, он проводит процедуру автоматической настройки с самого начала и, как нетрудно убедиться, получает тот же самый набор адресов, пока постоянны его канальный адрес и конфигурация маршрутизаторов. Можно сказать, что у такого механизма нет внутреннего состояния. Поэтому полностью его называют так: автоматическая настройка адресов без внутреннего состояния, сокращенно SLAAC (stateless address autoconfiguration) [RFC 4862].

В качестве безвредной оптимизации, [§5.7 RFC 4862] разрешает хосту хранить текущие настройки SLAAC в долговременной памяти (ППЗУ, диск) в пределах времени их жизни.

Важное условие работы SLAAC — чтобы канал поддерживал групповое вещание на сетевом уровне. Если это не так, то и SLAAC на таком канале работать не сможет.

Это не значит, что для SLAAC нужно настоящее групповое вещание на канальном уровне, например, каким мы его знаем в Ethernet. Требуется групповое вещание именно на сетевом уровне, а канальный уровень может его эмулировать. Так, например, в канале "точка-точка" групповое вещание сводится к передаче пакетов удаленному узлу. А если канал многоадресный и широковещательный, но без группового вещания, то групповые пакеты можно передавать всем узлам в широковещательных кадрах, полагаясь на отбор нужных пакетов сетевым уровнем. Пример этого подхода мы находим в ARCNET [§4.3 RFC 1201, §7 RFC 2497].

Как и всякий сложный автоматический механизм, SLAAC должен быть, в идеале, полностью управляемым, а по меньшей мере — отключаемым. У оператора узла должна быть возможность блокировать работу SLAAC на сетевом интерфейсе, если она нежелательна по тем или иным соображениям. Это касается как хостов, так и маршрутизаторов. Хост должен быть готов работать с ручными настройками, игнорируя объявления RA. Что же касается маршрутизатора, то рассылка RA может повлиять на конфигурацию многих хостов, и поэтому ее надо вообще отключить по умолчанию14 Параметр AdvSendAdvertisements, по умолчанию FALSE [§6.2.1 RFC 4861]. [ ] и включать явным образом только при необходимости и только после надлежащей настройки всех параметров объявления RA.

Это вовсе не противоречит обязательному статусу поддержки элементов SLAAC узлами IPv6. Одно дело, когда функцию можно избирательно отключить, а совсем другое, когда она вообще недоступна. То же касается DAD [§5.4 RFC 4862] и ND в целом.

Интересное применение возможностей SLAAC — это перенумерация сети IPv6, например, при переходе от одного провайдера к другому [§4.1 RFC 4862]. Ввиду постоянной длины префикса подсети, все идентификаторы интерфейсов могут остаться теми же, и тогда задача сводится к перенумерации префиксов подсетей. Гладко провести эту операцию можно, применяя в переходный период два префикса с установленным флагом A. Тогда каждый хост назначит своему интерфейсу два адреса, старый и новый. Далее, управляя предпочтительным временем жизни старого адреса, можно добиться, чтобы он больше не выступал источником новых сеансов. Завершить операцию можно, полностью упразднив старый адрес с помощью его действительного времени жизни. При этом достаточно менять настройки маршрутизаторов, а хосты сами их подхватят из объявлений RA. Подробно безболезненная процедура перенумерации разобрана в [RFC 4192].

Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.

Александр Худышкин
Александр Худышкин
Россия
Константин Второв
Константин Второв
Россия, Бокситогорск, ЛГОУ им. А.С.Пушкина, 2003