Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1678 / 51 | Длительность: 24:05:00
Лекция 8:

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

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >

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

Давайте интегрируем эту схему в уже существующий цикл жизни адреса: пробный, предпочтительный, устаревший, недействительный, — как показано на рис. 6.2. Временный адрес начинает свою жизнь как пробный, потому что его обязательно надо проверить на уникальность по DAD. Если адрес действительно уникальный, то он становится предпочтительным, и с него можно устанавливать исходящие сеансы. В противном случае надо просто сгенерировать новый случайный идентификатор интерфейса и начать все сначала. На всякий случай число таких попыток создать уникальный идентификатор ограничено величиной TEMP_IDGEN_RETRIESпо умолчанию 3 раза [§3.3 RFC 4941]. Действительно, если несколько попыток подряд не удались, то налицо какой-то непредусмотренный нами сбой.

Временный адрес обречен на то, чтобы рано или поздно стать устаревшим. Он не может оставаться предпочтительным дольше, чем указано настройках хоста. в2 Параметр REGEN_ADVANCE, по умолчанию 5 с [§3.4, §5 RFC 4941]. После этого адрес уже не годится для открытия новых прикладных сеансов. Поэтому было бы неплохо создать и назначить новый адрес чуть заранее, чтобы у сетевого интерфейса всегда был хотя бы один предпочтительный временный адрес. У сетевого интерфейса IPv6 может быть много адресов, и не будет никакой беды в том, что времена жизни старого и нового адресов перекроются.

По нашей задумке новый адрес должен быть другим, так что ему потребуется новый случайный идентификатор интерфейса. Конечно, его можно генерировать каждый раз, когда в нем возникнет необходимость. Но если вычислительные ресурсы хоста ограничены, а требования к степени конфиденциальности не настолько высоки, чтобы каждый адрес хоста был случайным, достаточно время от времени генерировать один случайный идентификатор для каждого из сетевых интерфейсов [§3.5 RFC 4941]. Период регенерации должен быть таким, чтобы преемник устаревшего адреса отличался от него .3 То есть он должен быть короче, чем TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR.

Еще новый идентификатор следует сгенерировать, когда хост переключается с одного канала на другой [§3.5 RFC 4941]. Впрочем, достоверно определить, что канал другой, — нетривиальная задача [RFC 4135].

Тем временем устаревший адрес продолжит свое существование, чтобы активные прикладные сеансы спокойно завершились штатным порядком. В них этот адрес уже "засвечен", и нет никакой необходимости торопить его полное исчезновение. Тем не менее, рано или поздно его стоит объявить недействительным и удалить, чтобы избежать слишком большого числа адресов на интерфейсе. Ведь с каждым адресом связаны ресурсы хоста и сети: структуры в оперативной памяти, группа искомого узла и т.п. Поэтому действительное время жизни временного адреса тоже ограничено, хотя и довольно продолжительным интервалом .4 Параметр TEMP_VALID_LIFETIME, по умолчанию неделя [§3.3, §5 RFC 4941].

 Жизненный цикл временного адреса IPv6

Рис. 6.2. Жизненный цикл временного адреса IPv6

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

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

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

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

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

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

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

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

 

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

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

Дмитрий Сирош
Дмитрий Сирош
Украина, Черкассы
Игорь Акулич
Игорь Акулич
Россия, с. Самара