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

Идентификаторы интерфейса с особыми свойствами и протоколы на их основе

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >
Аннотация: Обязательный адрес anycast для маршрутизаторов подсети. Обеспечение конфиденциальности путем расширения механизма автоматической настройки адресов. Защита розыска соседей — SEND.

Выбор маршрутизатора наугад

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

Но если определенной политики нет и хосту безразлично, какой именно маршрутизатор он выберет, то возникает хороший повод применить вещание наугад (§5.3). Для этого всем маршрутизаторам канала надо назначить общепринятый адрес anycast, так чтобы он был заранее известен хостам. Адрес anycast по внешним свойствам не отличается от индивидуального адреса, поэтому он вполне может принадлежать подсети, назначенной данному каналу. Следовательно, общепринятое значение мы можем выбрать только для идентификатора интерфейса, так как префикс подсети следует из адресного плана данной сети, его выбирает администратор. Пусть во всякой подсети на маршрутизаторы указывает адрес anycast с нулевым идентификатором интерфейса [§2.6.1 RFC 4291] — см. рис. 6.1. Это адрес "маршрутизатор подсети". Как следствие, нулевой идентификатор интерфейса зарезервирован, и его нельзя использовать в обычных адресах IPv6, будь то индивидуальных или anycast.

Адрес anycast "маршрутизатор подсети"

Рис. 6.1. Адрес anycast "маршрутизатор подсети"

По изначальной задумке [§2.6 RFC 4291], адрес anycast "маршрутизатор подсети" был назначен, не только чтобы хост внутри подсети мог обратиться к произвольному маршрутизатору-соседу, но и чтобы хост извне подсети мог направить пакет на ее границу, скажем, при помощи маршрутного заголовка (§3.3.3). Этот план распространялся и на административные единицы больше подсети. Практического применения эта идея не получила.

Довольно узкоспециализированное применение адреса anycast "маршрутизатор подсети" — это отладка туннелей, в частности, 6rd [§5 RFC 5969] . Суть его сводится к тому, что стороны туннеля могут обращаться друг к другу, например, проводить ping удаленного конца, используя один заранее известный адрес, близкий по свойствам к индивидуальному, — на тот случай, если инструменты отладки не поддерживают групповое вещание.

Позже появились и другие общепринятые адреса anycast. В итоге сошлись на том, что 128 самых старших значений идентификатора интерфейса1 С учетом того, что бит U/L остается сброшен. в любой подсети зарезервированы для этой роли [RFC 2526]. Адрес "маршрутизатор подсети" был назначен самым первым и потому он — исключение из этого правила. Интересно отметить, что в зарезервированных таким образом идентификаторах (кроме нулевого) бит I/G установлен. Этим как бы подчеркивается, что основанные на них адреса — не индивидуальные.

То, что общепринятый адрес anycast "маршрутизатор подсети" уже существует и принят стандартами, — один из аргументов против назначения каналам "точка-точка" префиксов /127 [§3 RFC 3627]. При таком назначении один интерфейс неизбежно получает нулевой идентификатор. Хуже того, второй интерфейс может получить при этом настоящий адрес anycast "маршрутизатор подсети", с тем же численным значением, и тогда возникнет конфликт, потому что адреса anycast не подлежат проверке DAD (см. §5.4.1). Ответный аргумент сторонников /127 — что на практике адрес anycast "маршрутизатор подсети" используют исчезающее редко [§4 RFC 6164]. (Мы не выступаем ни за одну из сторон в этом споре, а предлагаем читателю решать данный вопрос в каждом конкретном случае сообразно техническим условиям и обстоятельствам — надеемся, что к концу курса он будет на это способен.)

Конфиденциальность на уровне адресов

СТАРШИЙ БРАТ СМОТРИТ НА ТЕБЯ.

(Дж. Оруэлл, "1984")

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

(Дж. Хеллер, "Уловка-22")

Возникший в §5.4 механизм SLAAC не только облегчает настройку хостов IPv6, но и подстегивает манию преследования у пользователей Internet. Вот представим себе: пользователь купил портативный компьютер, сетевой интерфейс которого обладает постоянным адресом MAC 48. Это может быть адаптер Ethernet или 802.11 WiFi. Путешествуя по миру, пользователь подключается к местным сетям IPv6, и всякий раз его компьютер настраивает адрес с помощью SLAAC. Нетрудно видеть, что идентификатор интерфейса в таком адресе всегда будет один и тот же. Скажем, если адрес MAC00-01-02-03-04-05, то идентификатор будет такой: 02-01-02-FF-FE-03-04-05. Если вам это не очевидно, повторите §2.7. Благодаря совместным усилиям IEEE и IETF, этот идентификатор глобально уникален и однозначно указывает на данный компьютер. Поэтому, пока пользователь возит с собой кремниевого любимца, у него тоже есть личный номер. Далее, префикс подсети в адресе IPv6 весьма часто указывает на географическое местоположение узла. Таким образом, по текущему адресу можно сказать, кто этот пользователь и где он находится! А текущий адрес не хранится в секрете, он известен владельцу любого сетевого ресурса, к которому пользователь обращается со своего компьютера. Теперь достаточно взять журнал ресурса, который пользователь регулярно посещает, чтобы узнать маршрут его путешествия. Связать же идентификатор интерфейса с личностью пользователя часто помогает сам пользователь, регистрируясь в различных интерактивных системах, таких как форумы WWW. Выходит, что сегодня за нами могут следить не только спецслужбы, но и пользователи Internet, у которых есть немного административных привилегий!

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

Прежде всего, еще раз назовем корень зла: постоянный и глобально уникальный идентификатор интерфейса. На самом деле, ни постоянство, ни глобальная уникальность нам от него не требуются — мы их получили в нагрузку от IEEE, когда скромно просили уникальность в §5.4 в пределах данного канала. Тем не менее, в §5.4.1 нам пришлось "разработать" механизм DAD, чтобы дополнительно проверять уникальность адресов на канале. Не применить ли его сейчас?

Допустим, хост генерирует совершенно случайный, непредсказуемый идентификатор интерфейса и использует его в SLAAC. Не исключено, что пробный идентификатор уже занят соседом, но это можно проверить с помощью DAD. Как быть, если DAD дал положительный результат, то есть адрес дубликатный? В обычном SLAAC (§5.4), где идентификатор интерфейса однозначно зависит от его аппаратного адреса, это была бы тупиковая ситуация, и хост ожидал бы административного вмешательства. Теперь же хост может сгенерировать другой случайный идентификатор, снова создать адрес, проверить его по DAD и так далее до тех пор, пока DAD не даст отрицательный результат. Эта простая идея и лежит в основе механизма IPv6, известного как расширения для конфиденциальности (Privacy Extensions) [RFC 4941].

Конечно, даже случайный идентификатор интерфейса должен удовлетворять требованиям формата "модифицированный EUI 64" (§2.7). В частности, бит U/L должен быть сброшен, так как этот идентификатор не происходит от официально полученного глобального EUI 64 [§3.2.1 RFC 4941]. В то же время, стандарт не предписывает сбрасывать в ноль бит I/G; почему — нам не вполне ясно. По крайней мере, родственный формат CGA из §6.3 не забывает потребовать этого.

Кроме того, надо проверить, что случайный идентификатор не совпадает ни с одним из зарезервированных значений и еще не присутствует ни на одном из интерфейсов хоста. Ведь колесо фортуны может повернуться неожиданной стороной. Хотя текущий протокол расширений для конфиденциальности основан на 64-битных идентификаторах интерфейса [§1 RFC 4941], в принципе длина идентификатора интерфейса могла бы быть произвольной, так как не представляет труда сгенерировать случайное значение любой заданной длины.

Конечно, хосту потребуется качественный генератор (псевдо)случайных чисел. Также надо исключить сценарий, когда два хоста одновременно генерируют одну и ту же псевдослучайную последовательность. Чтобы этого не произошло, генератор псевдослучайных чисел надо инициализировать каким-то заведомо уникальным и трудно предсказуемым значением. Эти проблемы давно известны и встречаются в самых разных областях технологии Internet, так что методы их решения тоже хорошо разработаны [RFC 4086].

Как раз здесь может пригодиться глобальный адрес MAC или EUI. Он поможет инициализировать генератор (псевдо)случайных чисел так, чтобы тот выдал достаточно уникальную последовательность. Конечно, адрес надо смешать хэш-функцией с другими, менее предсказуемыми источниками случайности, но он послужит неплохой основой ввиду своей высокой уникальности. Нормативный документ расширений для конфиденциальности предписывает использовать одну вполне определенную хэш-функцию [§3.2 RFC 4941], но это сделано, по-видимому, только чтобы избежать самодельных, ненадежных алгоритмов в реализациях. В теории же выбор хэш-функции может быть совершенно произвольным, пока результат обладает достаточной степенью случайности и непредсказуемости.

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >
Сергей Субботин
Сергей Субботин

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

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

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

 

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

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

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