Здравствуйте, ·, Вы писали:
S>>>>Нет, наоборот. Не рассчитывать на то, что безопасность будет обеспечена сокрытием IP адреса от внешнего наблюдателя.
SK>>>Я не встречал человека, который бы думал что может скрыть публичный адрес в публичной сети и тем самым обеспечить некую безопасность.
N>>Ну тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF и аналогично уважаемых домашних организаций. TLDR: для отдельных взаимодействий запрашивается временный IP в дополнение к основному, генерируется случайно так, чтобы не совпал с выдаваемыми автоматом (то есть не соответствовал EUI-64 из MAC адреса). Живёт этот IP до закрытия последнего использующего его сокета (или аналога).
·>Что-то не вижу в этом rfc твою интерпретацию. Читаем "Problem Statement": "Anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier". Т.е. это не для обеспечения секретной передачи, а для сокрытия корреляций в сетевой активности.
На каком потолке ты вынашел про "секретную передачу" и что это "моя интерпретация"?
·>Как я понял, по сути это как бы способ для замены NAT+DHCP, но только позволяет делать stateless реализацию на клиенте без какого участия роутера, делает ненужным и NAT, и DHCP.
Во-первых, NAT ни при чём.
Во-вторых, заменой DHCP здесь служит SLAAC в целом. Только первичный адрес конструируется из MAC на основании префикса из router advertisement, который явно запрошен (если тот не успел случайно себя анонсировать именно в этот момент), а такие вот вторичные захватываются на основании описанного рандома и уже известного префикса.
·>Для секретности есть IPSec, который поддерживается в ipv6 нативно, а не как нашлёпка в ipv4.
1) Хватит ретранслировать бредовые сказочки образца 2000 года, это тогда почему-то некоторые утюги вещали то, что ты говоришь. IPSec в IPv4 и IPv6 отличается только деталями формата пакета, в остальном они идентичны.
2) IPSec требует настройки на уровне всего хоста (граничного раутера) и работает хост-хост или сеть-сеть. Догадываешься, почему это так мало используется сейчас?
N>>При этом никакого scope для того, чтобы через этот временный IP нельзя было достичь тех ресурсов, которые сидят на основном IP и ожидают поступающих соединений (или аналогов), не предполагается.
·>Читаем вместе: "Temporary addresses are typically employed for initiating outgoing sessions". Причём тут "ожидают поступающих соединений"?? Читай 2й параграф секции 2.2 про incoming.
(mode=Snape) Обычно рекомендуется не просто прочитать буквы написанного, а ещё и подумать над ним:
1) Появление нового адреса на интерфейсе означает, что автоматически все слушающие сервисы, которые прибиндились на звезду, будут принимать и на этот адрес тоже. И ни один существующий на сейчас стек не предполагает защиты от этого, и проблема в принципе не озвучена.
2) Typically это не must и даже не should (согласно RFC2119). Это вообще, как они говорят, informational часть. А если посмотреть на практику, возьмём тот же SIP. Пусть мы создали такой IP и создаём звонок с него. В сигнализации будет участвовать этот IP? Если нет, то мы раскрыли основной. Если да, то мы уже должны принимать входящий поток на него.
N>>О том, что первое же соединение к злоумышленнику покажет этот временный IP всем, они не думают. Файрволлинг такого IP тоже не очень предполагается, потому что он временный и типа "и так сойдёт" (этого в документе уже вроде нет, но это как реально будут делать).
·>Не понял про файрволлинг. Это для Interface ID части адреса же, а фаерволлят, если я не ошибаюсь, Subnet ID.
Файрволлят, в нормальном варианте, всё, кроме небольшого количества определённых входящих портов — и широкого набора исходящих.
Но это для веба хорошо надеяться только на исходящие. Для классического VoIP — не пройдёт.
