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