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

Безопасность

Протокол ND получился более гибким и универсальным, чем его предшественник ARP, но устойчивость ND к умышленным атакам осталась низкой. Мы не станем разбирать все возможные векторы атаки, а ограничимся самым очевидным из них: узел злоумышленника подключается к каналу и отвечает на вызовы NS касательно чужих адресов. В своих ответах NA узел злоумышленника сообщает, что искомому адресу IPv6 отвечает его собственный канальный адрес. В результате прочие узлы канала сами направляют трафик узлу злоумышленника. К примеру, так узел злоумышленника может прикинуться маршрутизатором по умолчанию и перехватить весь трафик от узлов канала в Internet. Чтобы настоящий владелец адреса не мешал атаке своими ответами NA, можно подвергнуть его параллельной атаке типа "отказ в обслуживании" или выбрать момент, когда он отключен для профилактики.

В отличие от ARP, который стоял в иерархии стека рядом с IP, ND — это подмножество ICMPv6, а значит, в теории его можно защитить на уровне IPv6. Такую защиту обеспечивает протокол IPsec, рассмотренный нами в §3.3.5. Но, увы, на практике это слишком тяжеловесное, хотя и надежное решение. На нижнем уровне работой IPsec управляют связи безопасности — грубо говоря, элементарные правила о том, как именно защищать пакеты из данного источника к данному адресату. Если к каналу подключены N узлов, а у каждого из них M адресов, то для полноценной работы ND надо будет настроить до связей на каждом узле [§6 draft-arkko-manual-icmpv6-sas]. Это трудоемкая и неблагодарная по ложности работа. На более высоком уровне связями безопасности управляет удобный протокол IKE, но он требует полноценно работающего сетевого уровня, что неминуемо приводит нас к "проблеме курицы и яйца". В частности, IKE не позволит защитить самый уязвимый элемент ND — разрешение адресов [draft-arkko-icmpv6-ike-effects].

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

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

Однако мы ошибаемся, говоря, что априорной информации нет. Ведь при розыске соседа узел заранее знает соседский адрес IPv6! На самом деле, это допущение, и допущение очень важное: адрес IPv6 соседа — доверенный. Ведь сейчас мы работаем над защитой протокола ND, и нам нужны определенные "очаги доверия", гарантированные нам другими протоколами и уровнями стека, — иначе нам не на что будет опереться.

Что означает доверенность адреса IPv6? Это значит, что мы узнали его из доверенного источника. Скажем, мы хотим провести ping одного из интерфейсов узла-соседа Б. Как нам достоверно узнать его адрес IPv6? Во-первых, мы можем сами пойти к консоли этого узла, локально войти в систему и прочесть адрес в настройках.

Во-вторых, если у нас есть основания доверять DNS^{5Например, благодаря применению DNSSEC.} и мы знаем доменное имя узла Б, то программа ping6 сама узнает адрес по имени:

$ ping6 b.example.org

PING6(56=40+8+8 bytes) 2001:db8::2 --> 2001:db8::1

...

В-третьих, адрес Б мы можем узнать от доверенного лица, из рук в руки или в подписанном электронном письме… Читатель может самостоятельно продолжить этот список.