Здравствуйте, Stanislaw K, Вы писали:
SK>Ты, видимо, плохо понимаешь что криптография и SSL (кроме процессороёмкой реализации) тянут за собой большую сложную дорогую инфраструктуру CA, или не менее дорогие покупные сертификаты.
А что именно там дорого и сложно? Раздавать сертификаты в цепочке проверки? Вполне себе дёшево. Для таких задач редко применяют общественную инфраструктуру — достаточно иметь вендорский Root CA предпрошитым в устройстве.
А со стороны устройства главное — чтобы публичный ключ устройства был подписан сертификатом вендора, там цепочка из одного звена.
Поэтому платить никому ни за что не надо.

SK>И все ради чего? ради того, чтобы злоумышленник третье лицо, перехватив несколько пакетов трафика не смог понять содержимого.
Совершенно верно. Потому что когда это "содержимое" — plaintext username/password, как это было в случаях, которые я упоминал, его "понимание" злоумышленнику полный контроль над вашей железкой. А в плохом случае — и над вашим аккаунтом (если железка авторизуется на сервере, как IP телефон). Я бы, к примеру, мало кому из посторонних доверил управление моим утюгом. Или гаражной дверью.

SK>Эту позицию разделяю и поддерживаю.

Здравствуйте, Stanislaw K, Вы писали:

SK>>>Вклеивать на уровень IP адреса?
S>>Нет, наоборот. Не рассчитывать на то, что безопасность будет обеспечена сокрытием IP адреса от внешнего наблюдателя.

SK>Я не встречал человека, который бы думал что может скрыть публичный адрес в публичной сети и тем самым обеспечить некую безопасность.

Ну тогда познакомься: вот аж целых трое из в общем-то уважаемой организации IETF и аналогично уважаемых домашних организаций. TLDR: для отдельных взаимодействий запрашивается временный IP в дополнение к основному, генерируется случайно так, чтобы не совпал с выдаваемыми автоматом (то есть не соответствовал EUI-64 из MAC адреса). Живёт этот IP до закрытия последнего использующего его сокета (или аналога).

При этом никакого scope для того, чтобы через этот временный IP нельзя было достичь тех ресурсов, которые сидят на основном IP и ожидают поступающих соединений (или аналогов), не предполагается. О том, что первое же соединение к злоумышленнику покажет этот временный IP всем, они не думают. Файрволлинг такого IP тоже не очень предполагается, потому что он временный и типа "и так сойдёт" (этого в документе уже вроде нет, но это как реально будут делать).

Но это люди из уважаемых организаций, а ты кто?

Здравствуйте, Sinclair, Вы писали:

S>Никакого желания впихивать в стандарт адресации криптографию у меня нету. У меня есть желание запретить людям полагаться на NAT в качестве инструмента контроля доступа.

У тебя это никогда не получится, можешь и не пытаться.
Точно так же как не получится, например, заставить 99% людей не думать, что если они дома за запертой дверью, то не надо с собой постоянно держать заряженный пистолет.
Один параноик из ста (или даже меньшая доля) согласится. Остальные — нет.

Профессиональные безопасносники это знают и не пытаются обойти.

S> Одним из симптомов порочного образа мысли как раз и является "всё равно всем нужен NAT как мера безопасности, так что мы можем не париться с размером пространства адресов"

"Не париться" — нет. А вот не считать объём из его принудительного отсутствия для всех — таки да.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, netch80, Вы писали:
N>>Впихнуть туда что-то, умевшее SSL, просто не получалось (или жестоко тормозило). Это началось уже начиная с первой половины 2000-х, и началось именно с замены железа.
S>Ага, то есть запихать FTP, SIP, парсер XML, и ещё 100500 всяких кунштюков — проблем нет, а банальный SSL — ресурсов нету?
S>Сказки.

SIP — целевая задача. FTP для прошивки тривиален и нужен. XML — вероятно, для конфига, и то нужен простейший парсер, в духе, извините, sablotron. SSL — обосновать как? Ну и в случае MIPS длинная арифметика, мягко говоря, никакая.
Про объём и сложность кода уже сказали рядом.

N>>А вот в случае IoT всё сильно разнообразнее. В какой-нибудь электросчётчик впихнуть то, что умеет сформировать, закодировать и подписать пакет данных, не проблема: если оно сожрёт дважды в сутки два ватта в течение трёх секунд, никто и не заметит. Но там есть и такие устройства, которые должны висеть на внешней стене дома и работать 5 лет от одной батарейки — и при этом регулярно слать свой статус.
S>Было бы интересно посмотреть на энергетический бюджет такого устройства. Если оно подключено по воздуху — как же оно ухитряется 5 лет на одной батарейке вещать в эфир так, чтобы его кто-то слышал?

Я сейчас искал, но не смог найти. Была статья от Артамонова на Хабре, с описанием, что именно им пришлось исключить из вариантов, чтобы оно таки тянуло такой ресурс.

S>Если оно подключено по проводу — кто ему мешает взять дополнительно 0.05 милливатта на криптографию?
S>Альтернатива — ровно такая: ваше устройство — вовсе не ваше. Ксакеп с брелком за пару сотен баксов подключится к вашему устройству, просто подойдя к забору, и получит нужный ему результат.

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

N>>(Справедливости ради, такие устройства и не будут цепляться к 5G или что там сейчас. У них будет LoRa или что-то похожее. Вот там вообще раутинга не будет, только точка-точка.)
N>>Но я согласен с тем, что нормальная защита в IoT придёт ещё не скоро. По этой аналогии или нет, но в ближайшие надцать лет выпускать их в большой внешний мир будет нежелательно.
S>Это в какой-то мере зависит от нас с вами. Нужно пропагандировать правильные вещи. Чтобы люди не выдумывали рационализаций идиотским решениям. Идея несекьюрной коммуникации — в сто раз хуже идеи "удвоить размер IP адреса".

Невозможно заставить людей не думать в терминах защищённого периметра и ослабленных мер контроля внутри него. 99% в ванную или в постель для секса не потащат заряженный и взведённый пистолет. А кто потащит — или уже Джеймс Бонд с готовой репутацией (и тогда можно быть уверенным, что он не выстрелит, когда не надо), или на него будут слишком активно коситься.

И к системам внутри это тоже относится. Передаваемое по PCI или USB обычно не шифруется и не подписывается, эти меры применяются уже снаружи от них. Точно так же поставить внутренние серверы с доступом только через VPN и расслабиться, допуская общие для всех ресурсы видимыми без паролей — нормальная идея.

Сколько бы ты ни кричал про "в сто раз хуже", это останется только твоим персональным оценочным суждением. Метод границ-периметров — работает, и достаточно хорошо работает. Проблемы возникают там, где этот периметр нарушается или незаметно для ответственных за его контроль, или они это игнорируют.

N>>А это уже проблема администрирования.
S>Не администрирования, а административная. Дегенератам не выписали вовремя дюлей. Ну, вот как с подписанными прошивками — математика у всех одинаковая, чипы и ресурсы примерно одинаковые, но при этом получить root access на примерно любом андроиде, включая флагманов — как два пальца. В отличие от того же Apple. Что у Apple, инженеры более умные? Или стойки в датацентре дешевле, чем у Samsung? Нет, просто культура недружелюбная к дегенератам. Их бьют палкой до тех пор, пока из них не выпадет приемлемый результат. А не объяснения "ну мы же не можем выдавать каждому устройству уникальный публичный ключ, и потом подписывать все прошивки его приватным ключом".

И опять много ругани и чисто эмоциональных оценочных суждений. "Дегенераты", "более умные" и т.п. И ещё и рекомендации "бить палками". А то, что экосистема Apple этим уже отпугивает многих, ты не учитываешь?

И расскажи, что ты видишь плохого в root access, если он достигается по явной заявке владельца (оформленной, например, в виде тычков в меню в особом режиме загрузки).

N>>Для видео нет портящих тут картину жёстких лимитов по железу, иначе оно не работало бы. Но запрос на "secured perimeter" и "corporate VPN" шёл и идёт не от электронщиков, а как раз от корпоративных админов и безопасников.
S>В каком-то смысле — да, от них. Но не так, что они требовали сделать дырявую реализацию. А на вопрос "можете закрыть доступ к конфиг серверу снаружи" они отвечали "да, можем".

Да. А после этого принципиальная постановка вопроса в духе "мы можем заложиться на защиту сети?" в какой-то момент пропускается, скорее всего, на уровне интеграторов, которые просто не замечают проблемы (или игнорируют её). И снова, кто отвечает за то, что входная дверь в квартиру оказалась дизайна двери туалета? Почему (обычно) строители так не ляпают?

N>>Потому что те люди, что есть, не потерпят чрезмерных ограничений со стороны техники, они с ними не справятся. А защита в стиле "попал в периметр — уже имеешь какие-то права" это то, что работает как адекватный компромисс между шлепанутыми менеджерами по маркетингу и шизанутыми безопасниками.
S>Это "работает" до первого залетевшего дятла. Не, я понимаю, были времена, когда считалось, что https — это шибко дорого, и нужно только особенно отдельным сайтам — например, с визовыми анкетами и процессингами платежей. Ну так блин мы-то живём в 21 веке, а не в оруэлловском 1974.

Считалось, что https — шибко дорого, как раз до letsencrypt. И вполне обоснованно считалось. А в 2000-х — так вообще. Мало того, ещё и сложно: пока докажешь какому-нибудь Verizon, что ты — это ты, семь потов сойдёт — и то если получится, потому что каждый второй человек на той стороне скажет "да я имел этих таёжных варваров, я нихрена не понимаю в душе что у них там происходит" и зарежектит.

И letsencrypt появился совсем не в 2001. Вики говорит — 2014. А те телефоны, которые ты вкатил в эту дискуссию, начались в районе 1997.

Ну и про железячный их уровень я уже сказал. Они и тот H.323 или SIP еле-еле успевали провернуть.

А теперь скажи мне, как сделать простой и удобный (и межвендорски универсальный) раздатчик https сертификатов для локалки, раз уж ты предлагаешь, чтобы даже поход на местный файловый сервер шифровать. И чтобы все браузеры автоматом подтягивали всё нужное. Q?

N>>Это всё потому так, что тема тех же раутеров уже стабилизировалась — что они делают, как и почему. Любой очередной Лян Ляо, решивший производить теперь с клубничным вкусом, просто берёт готовую разработку вплоть до корпуса и мажет его клубникой со своей грядки.
N>>А для IoT до стабилизации ещё долго.
S>Долгота зависит ровно от того, насколько сильно будут бить палкой разработчиков IoT. Потому что никакой rocket science тут нету.

Ты явно не в курсе его специфики.

Здравствуйте, Sinclair, Вы писали:

S>А что именно там дорого и сложно? Раздавать сертификаты в цепочке проверки? Вполне себе дёшево. Для таких задач редко применяют общественную инфраструктуру — достаточно иметь вендорский Root CA предпрошитым в устройстве.
S>А со стороны устройства главное — чтобы публичный ключ устройства был подписан сертификатом вендора, там цепочка из одного звена.

Apple головного мозга (АГМ) в полный рост. При любой перепродаже устройства — ходи к производителю за ключами.

Я ещё как-то понимаю, если серверную сторону будут проверять по умолчанию (и предоставлен какой-то стандартный лёгкий путь вшить сертификат локального сервера). Но клиента... ???

А ещё, вот только что вспомнил, эти телефоны в массе умели получать начальный конфиг по TFTP. Это тоже ты предлагаешь сделать через SSL в облако?

S>Поэтому платить никому ни за что не надо.

Только изготовителю устройства, за то, что поддерживает своё хранилище ключей по каждому устройству. Этак баксов 20 в год, минимум (иначе не окупится) на каждое устройство. И расширенную проверку запросов, для чего держать детективное агентство.
А кто не заплатил в течение года — стирать нафиг, законно по SLA, чтобы бежали покупать новую железяку.
АГМ такое АГМ...

SK>>И все ради чего? ради того, чтобы злоумышленник третье лицо, перехватив несколько пакетов трафика не смог понять содержимого.
S>Совершенно верно. Потому что когда это "содержимое" — plaintext username/password, как это было в случаях, которые я упоминал, его "понимание" злоумышленнику полный контроль над вашей железкой.

Кстати, ты и SIP не знаешь. Почитай про стиль Digest авторизации. Нет там plaintext password. А Basic стиль там запрещён.

Ох уж эти мне сказочники, не попытавшиеся хоть что-то узнать про сеттинг...

Здравствуйте, Sinclair, Вы писали:

SK>>Ты, видимо, плохо понимаешь что криптография и SSL (кроме процессороёмкой реализации) тянут за собой большую сложную дорогую инфраструктуру CA, или не менее дорогие покупные сертификаты.
S>А что именно там дорого и сложно? Раздавать сертификаты в цепочке проверки? Вполне себе дёшево.

Кровавому энетрпрайзу дешево, у него уже есть документально оформленная (пусть и внутренними регламентами) программно-аппаратная инфраструктура CA, оборудованные рабочие места и выделенные специально обученные доверенные люди с допуском на ежемесячной зарплате поддерживающие её.

Всем остальным SMB предлагается делать так-же, ради пары дюжин VoIP акканутов?

S>Для таких задач редко применяют общественную инфраструктуру — достаточно иметь вендорский Root CA предпрошитым в устройстве.
S>А со стороны устройства главное — чтобы публичный ключ устройства был подписан сертификатом вендора, там цепочка из одного звена.
S>Поэтому платить никому ни за что не надо.

А затем вендорский RootCA со сроком действия 30 лет "утекает" (как это было и будет много раз) и смысл этого шапито нулевой.

SK>>И все ради чего? ради того, чтобы злоумышленник третье лицо, перехватив несколько пакетов трафика не смог понять содержимого.
S>Совершенно верно. Потому что когда это "содержимое" — plaintext username/password,

Не используй plaintext.

S>как это было в случаях, которые я упоминал, его "понимание" злоумышленнику полный контроль над вашей железкой. А в плохом случае — и над вашим аккаунтом (если железка авторизуется на сервере, как IP телефон).

так еще же нужно криптовать сам медиа трафик RTP/RTSP. а как стандарт sRTP/RTSPs приняли совсем недавно, так еще позже его поддержка появилась в PBX и "в железе". на тот момент типичный офисный ПК целиком стоил дешевле настольного VoIP аппарата.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>Кровавому энетрпрайзу дешево, у него уже есть документально оформленная (пусть и
S>>Для таких задач редко применяют общественную инфраструктуру — достаточно иметь вендорский Root CA предпрошитым в устройстве.
S>>А со стороны устройства главное — чтобы публичный ключ устройства был подписан сертификатом вендора, там цепочка из одного звена.
S>>Поэтому платить никому ни за что не надо.
SK>А затем вендорский RootCA со сроком действия 30 лет "утекает" (как это было и будет много раз) и смысл этого шапито нулевой.

++.

SK>>>И все ради чего? ради того, чтобы злоумышленник третье лицо, перехватив несколько пакетов трафика не смог понять содержимого.
S>>Совершенно верно. Потому что когда это "содержимое" — plaintext username/password,
SK>Не используй plaintext.

Он не в курсе, что авторизация SIP в принципе не бывает plaintext

S>>как это было в случаях, которые я упоминал, его "понимание" злоумышленнику полный контроль над вашей железкой. А в плохом случае — и над вашим аккаунтом (если железка авторизуется на сервере, как IP телефон).

SK>так еще же нужно криптовать сам медиа трафик RTP/RTSP. а как стандарт sRTP/RTSPs приняли совсем недавно, так еще позже его поддержка появилась в PBX и "в железе". на тот момент типичный офисный ПК целиком стоил дешевле настольного VoIP аппарата.

Ну тут несколько преувеличение, по моей памяти.

Базовый RFC по SRTP это 2004. К тому времени реализации как минимум SDES (когда стороны обменялись явными ключами через сигнализацию, может, и открытую) уже были отработаны, а в корпоративных условиях и это поверх SIPS бегало, так что ключи посторонний не видел. DTLS стандартизовали только в 2008, но опять же оно было и раньше, хоть и локально.

Телефоны были разных систем. Конечно, вендоры пытались продать максимально навороченные аппараты за тонны нефти, но в массе пользователи вполне могли сидеть на POTS (plain old telephone system) телефоне, включенном в FXS порт. Cisco ATA186 — H.323. Sipura звери типа SPA1000, SPA2000 — SIP. Я как раз в VoIP начал работать в 2004 и с ходу получил SPA2000 (то есть два порта FXS), а дальше пошёл в магазин, купил 2 обычных "офисных" телефона (чтобы была штатная кнопка Flash) с подключением в обычную сеть и работал через них. Так вот эта SPA2000 "на рынке" стоила около 200$, а офисный компьютер нормальный начинался от 500. SPA1000 с одним портом стоила ещё дешевле — около 150$. При этом SPA коробочки имели собственный веб-интерфейс, TFTP клиента, читатель конфига в бинарном формате (была тулза для его изготовления). Держали два звонка одновременно, но с ограничениями по кодекам — G.729 мог работать только на одном.

Потом когда стали делать и тестить всякие трансферы — потребовался, конечно, второй такой 2*FXS блок, потом выдали уже аппарат с дисплеем... но стартовать на таком было без проблем.

Я один раз в сипуру включил даже старый советский аппарат с дисковым номеронабирателем, ради хохмы. Работало как ни в чём ни бывало. Что в линии 48В вместо 60В и другой формат сигнала вызова — ему было пофиг, звонил и принимал.

Одновременно с этим включались и другие вендоры — я помню, что сразу же была пачка коробок всех видов от GrandStream. Позже кто только ни подключался, например, аж D-Link в куче конфигураций типа "2 FXO + 8 FXS". Но это уже в 2006 и далее.

(UPD: это я ещё не сразу вспомнил про чисто софтовые клиенты, которые работают через звуковуху компа. Мы их использовали почти только для факсов, потому что с ними нельзя сказать "алло" в одну трубку и услышать себя в другой. Но у клиентов они были в больших масштабах. А в интеграторе, где я работал до того, были как клиентские.)

И Sipura уже тогда умела SIPS и SDES (вот что за шифры, в упор не помню). DTLS появился позже с новыми прошивками (возможно, при переходе на PAP2). И с сертификатами там были сложности, мы до ~2010 на них не обращали внимания из-за чудовищной запутанности всей инфраструктуры. В основном работал вариант, что провижининг из некоего центра раздавал конфиг, в котором был уже сертификат SIP прокси, чтобы SIPS работал. А вот защиту провижининга чем делали — я не видел. Жалоб на взлом/перехват было крайне мало и только из-за ляпов в самих устройствах, а не перехват где-то посредине. Может, специфика наших клиентов.

То есть всё это медленно, постепенно развивалось, осваивая технологии.

Здравствуйте, netch80, Вы писали:

SK>>так еще же нужно криптовать сам медиа трафик RTP/RTSP. а как стандарт sRTP/RTSPs приняли совсем недавно, так еще позже его поддержка появилась в PBX и "в железе". на тот момент типичный офисный ПК целиком стоил дешевле настольного VoIP аппарата.

N>Ну тут несколько преувеличение, по моей памяти.

N>Базовый RFC по SRTP это 2004. К тому времени реализации как минимум SDES (когда стороны обменялись явными ключами через сигнализацию, может, и открытую) уже были отработаны, а в корпоративных условиях и это поверх SIPS бегало, так что ключи посторонний не видел. DTLS стандартизовали только в 2008, но опять же оно было и раньше, хоть и локально.

secure SIP (авторизация сигнализация) — не спорю, большинство аппаратов поддерживало. а вот с secure RTP (собственно голос) долгое время было "печально".

Но это все прикладной уровень, к ip адресации не имеющий отношения. тут ранее было предложение ввести SSL в стандарт адресации.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:
SK>Всем остальным SMB предлагается делать так-же, ради пары дюжин VoIP акканутов?
Откуда взялся SMB? Железки выпускаются тем самым кровавым энтерпрайзом, огромными тиражами.

SK>А затем вендорский RootCA со сроком действия 30 лет "утекает" (как это было и будет много раз) и смысл этого шапито нулевой.
:sigh: Если вендорский RooCA утекает, то в девайс заталкивается новая прошивка, подписанная приватным ключом этого устройства, в которой лежит новый RootCA.

SK>Не используй plaintext.
You're preaching to the choir.
SK>так еще же нужно криптовать сам медиа трафик RTP/RTSP.
Его криптование — факультативно. Если вы не хотите щифрованных переговоров, то можете не шифровать переговоры. А вот административные протоколы защищать абсолютно необходимо.
SK> а как стандарт sRTP/RTSPs приняли совсем недавно, так еще позже его поддержка появилась в PBX и "в железе". на тот момент типичный офисный ПК целиком стоил дешевле настольного VoIP аппарата.
Брр. Если поддержка появилась недавно, то самый навороченный IP-телефон не стоил больше $150. Если речь о том, сколько стоили IP-телефоны 20 лет назад — всё ещё сильно дешевле типичного офисного ПК.

Здравствуйте, netch80, Вы писали:

N>Apple головного мозга (АГМ) в полный рост. При любой перепродаже устройства — ходи к производителю за ключами.
Это всё ещё лучше, чем получить угон аккаунта. "Ходить к производителю" — ну, вот всякий раз, как я сдаю свой старый iPhone в трейд-ин, я "хожу к производителю за ключами". Неудобств, простите, на копейку. Безопасности — на $1200.
N>Я ещё как-то понимаю, если серверную сторону будут проверять по умолчанию (и предоставлен какой-то стандартный лёгкий путь вшить сертификат локального сервера). Но клиента... ???
А в чём проблема?
N>А ещё, вот только что вспомнил, эти телефоны в массе умели получать начальный конфиг по TFTP. Это тоже ты предлагаешь сделать через SSL в облако?
Именно. Потому что вот этот начальный конфиг собственно и содержит SIP креды, которые тривиально угоняются, если устройство торчит в публичный интернет, а не в локальную сетку, заботливо изолированную NAT-ом от внешнего мира.

N>Только изготовителю устройства, за то, что поддерживает своё хранилище ключей по каждому устройству. Этак баксов 20 в год, минимум (иначе не окупится) на каждое устройство.
Нифига себе у вас запросы. Двадцать баксов в год стоит хранение гигабайтных объёмов, с безлимитной отдачей их по запросу. Это, естественно, в розницу, то есть с большой прибылью. Если задача — не в том, чтобы содрать с клиента четыре шкуры, то безопасность стоит дешевле, чем её отсутствие.

N>И расширенную проверку запросов, для чего держать детективное агентство.
Какое агенство? Какую проверку? Ерунду пишете ведь.

N>Кстати, ты и SIP не знаешь. Почитай про стиль Digest авторизации. Нет там plaintext password. А Basic стиль там запрещён.
:sigh:. Речь не о том, что SIP не закриптован. А в том, что девайсина конфигурируется при помощи скачивания кредов по открытому протоколу.
Или вообще — выставляет наружу HTTP сервер без шифрования и авторизации (или с Basic), при помощи которой можно подключиться к видеопотоку и управлению камерой .
N>Ох уж эти мне сказочники, не попытавшиеся хоть что-то узнать про сеттинг...

Здравствуйте, netch80, Вы писали:
S>>Было бы интересно посмотреть на энергетический бюджет такого устройства. Если оно подключено по воздуху — как же оно ухитряется 5 лет на одной батарейке вещать в эфир так, чтобы его кто-то слышал?
N>Это я уже не в курсе криптографии в конкретном LoRa, чтобы ответить, будет оно так работать или нет. Но, насколько я помню, эти штуки только передавали — пару раз в час.

N>>>(Справедливости ради, такие устройства и не будут цепляться к 5G или что там сейчас. У них будет LoRa или что-то похожее. Вот там вообще раутинга не будет, только точка-точка.)
N>>>Но я согласен с тем, что нормальная защита в IoT придёт ещё не скоро. По этой аналогии или нет, но в ближайшие надцать лет выпускать их в большой внешний мир будет нежелательно.
S>>Это в какой-то мере зависит от нас с вами. Нужно пропагандировать правильные вещи. Чтобы люди не выдумывали рационализаций идиотским решениям. Идея несекьюрной коммуникации — в сто раз хуже идеи "удвоить размер IP адреса".

N>Невозможно заставить людей не думать в терминах защищённого периметра и ослабленных мер контроля внутри него. 99% в ванную или в постель для секса не потащат заряженный и взведённый пистолет. А кто потащит — или уже Джеймс Бонд с готовой репутацией (и тогда можно быть уверенным, что он не выстрелит, когда не надо), или на него будут слишком активно коситься.

N>И к системам внутри это тоже относится. Передаваемое по PCI или USB обычно не шифруется и не подписывается, эти меры применяются уже снаружи от них. Точно так же поставить внутренние серверы с доступом только через VPN и расслабиться, допуская общие для всех ресурсы видимыми без паролей — нормальная идея.
Но в USB и в PCI нет задачи "спроектировать сетевой протокол, одинаково пригодный и для подключения 10-сантиметровым шнурком и для связи через континент".

N>Сколько бы ты ни кричал про "в сто раз хуже", это останется только твоим персональным оценочным суждением.
Отож. См. название форума — он целиком посвящён персональным оценочным суждениям.
N>Метод границ-периметров — работает, и достаточно хорошо работает. Проблемы возникают там, где этот периметр нарушается или незаметно для ответственных за его контроль, или они это игнорируют.
В целом — да. На практике выясняется, что "решения", которые выглядят рабочими, работают только в каких-то узких тепличных условиях. И сэкономленные на спичках деньги с лихвой перекрываются зарплатами компетентных людей, которые строят и поддерживают эти защищённые периметры. А иногда — с ещё большей лихвой, когда происходит security breach.

N>И опять много ругани и чисто эмоциональных оценочных суждений. "Дегенераты", "более умные" и т.п. И ещё и рекомендации "бить палками". А то, что экосистема Apple этим уже отпугивает многих, ты не учитываешь?
Посмотрите на капитализацию Apple. Очень многие компании мечтали бы так "отпугивать многих". Удивительно не это, а то, что многие другие смотрят на Apple, и говорят "не, они какие-то слишком успешные. Не может быть что это из-за того, что они делают что-то толковое. Мы продолжим делать херню и добъёмся успеха".

N>И расскажи, что ты видишь плохого в root access, если он достигается по явной заявке владельца (оформленной, например, в виде тычков в меню в особом режиме загрузки).
Я вижу прекрасную возможность всадить трояна через социальную инженерию.
Недавно вот был случай — в магазине лежало вполне себе легальное приложение, детская игрулина. Сколько-то месяцев развивало пользовательскую базу. Семилетки играли и фанатели.
Потом в приложении появился магазин с инструкциями, как выпросить у родителей телефон, запустить на нём Сбербанк Онлайн, получить шестизначный код, и отправить его в аппликуху, "чтобы разблокировать новые скины".
А завтра я выкачу приложение для взрослых, которое даст выиграть в казино 600к, но для их вывода нужно будет провести "набор тычков в особом режиме загрузки" и загрузить новую прошивку.

Но это не тот сценарий, про который я рассказываю — я говорю о root access, который получил не пользователь, а злоумышленник. Потому что где-то один дегенерат решил, что "зачем секьюрить меню настроек гаражного замка — оно всё равно будет доступно только во внутренней сети", а другой дегенерат решил, что сервис "управление гаражными воротами через интернет" можно выгодно продать домашним пользователям.
Сочетание этих двух дегенеративных решений приводит к тому, что вашими гаражными воротами начинает управлять совершенно посторонний вам человек, в противоправных целях.

N>Да. А после этого принципиальная постановка вопроса в духе "мы можем заложиться на защиту сети?" в какой-то момент пропускается, скорее всего, на уровне интеграторов, которые просто не замечают проблемы (или игнорируют её). И снова, кто отвечает за то, что входная дверь в квартиру оказалась дизайна двери туалета? Почему (обычно) строители так не ляпают?
В первую очередь — инженеры. Это наша работа — понимать, что с чем связано. А не полагаться на то, что каждый гражданин Земли — сам себе security инженер.

N>>>Потому что те люди, что есть, не потерпят чрезмерных ограничений со стороны техники, они с ними не справятся. А защита в стиле "попал в периметр — уже имеешь какие-то права" это то, что работает как адекватный компромисс между шлепанутыми менеджерами по маркетингу и шизанутыми безопасниками.

N>Считалось, что https — шибко дорого, как раз до letsencrypt. И вполне обоснованно считалось. А в 2000-х — так вообще. Мало того, ещё и сложно: пока докажешь какому-нибудь Verizon, что ты — это ты, семь потов сойдёт — и то если получится, потому что каждый второй человек на той стороне скажет "да я имел этих таёжных варваров, я нихрена не понимаю в душе что у них там происходит" и зарежектит.
Подождите. Вы подменяете понятия. SSL != PKI. Мы же говорим об инженерной стоимости. А не о том, насколько велика была жадность Verizon.
Letsencrypt собственно и показывает, что SSL не стоит примерно ничего. Аргументировать технические решения жадностью третьих лиц.... Ну, такое себе.
N>И letsencrypt появился совсем не в 2001. Вики говорит — 2014. А те телефоны, которые ты вкатил в эту дискуссию, начались в районе 1997.
В 1997 году любой желающий мог сам себе сделать letsencrypt. И все так и делали — внутренние сетки отродясь пользовались local CA, и никто не жаловался на то, что эти ключи какие-то особенно дорогие.

N>Ну и про железячный их уровень я уже сказал. Они и тот H.323 или SIP еле-еле успевали провернуть.
Ну, в 1997 году — может быть. Как такая бредятина смогла дожить до 2007 — вот вопрос. А сейчас 2024, и мы на полном серьёзе обсуждаем идею "давайте делать небезопасные протоколы и ендпоинты в надежде на то, что их защищщят при помощи периметра".

N>А теперь скажи мне, как сделать простой и удобный (и межвендорски универсальный) раздатчик https сертификатов для локалки, раз уж ты предлагаешь, чтобы даже поход на местный файловый сервер шифровать. И чтобы все браузеры автоматом подтягивали всё нужное.
Во первых, какие ещё браузеры? Мы же вроде про IoT и технические протоколы взаимодействия.
Во вторых, есть вполне себе простой и удобный раздатчик https сертификатов. Называется Active Directory. И с десяток его аналогов от разных вендоров.
И даже если мы вернулись к разговору о браузерах, то я считаю идиотским решение
1. Поставить локальную Jira без https, "потому что мы экономим на сертификатах и IP адресах"
2. Вывести людей на удалёнку
3. Тратить деньги и усилия на поддержание VPN, который отваливается раз в иногда, и без которого не получается зайти в локальную жиру снаружи

Как по мне, так деньги, потраченные на эти еженедельные "ой, у меня отпал и основной и резервный VPN сервер, что мне делать", было бы лучше один раз потратить на десяток публичных IP-адресов и сертификатов.


S>>Долгота зависит ровно от того, насколько сильно будут бить палкой разработчиков IoT. Потому что никакой rocket science тут нету.
N>Ты явно не в курсе его специфики.
Возможно. Но я видел предыдущую итерацию — собственно, телефоны и веб-камеры и есть как раз первые примеры таких things.

Здравствуйте, netch80, Вы писали:

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.

Для секретности есть IPSec, который поддерживается в ipv6 нативно, а не как нашлёпка в ipv4.

N>При этом никакого scope для того, чтобы через этот временный IP нельзя было достичь тех ресурсов, которые сидят на основном IP и ожидают поступающих соединений (или аналогов), не предполагается.
Читаем вместе: "Temporary addresses are typically employed for initiating outgoing sessions". Причём тут "ожидают поступающих соединений"?? Читай 2й параграф секции 2.2 про incoming.

N>О том, что первое же соединение к злоумышленнику покажет этот временный IP всем, они не думают. Файрволлинг такого IP тоже не очень предполагается, потому что он временный и типа "и так сойдёт" (этого в документе уже вроде нет, но это как реально будут делать).
Не понял про файрволлинг. Это для Interface ID части адреса же, а фаерволлят, если я не ошибаюсь, Subnet ID.

Здравствуйте, netch80, Вы писали:

S>>>Скорости всегда мало — представь что запросов миллионы в секунду. И каждый IP нужно как-то обработать. Естественно нейтивно поддерживаемый процессором тип будет на порядки быстрее.
N>ChatGPT такой ChatGPT
N>Этот ответ не учитывает, что поиск по такой памяти чудовищно дорогой по энергии.
Я процитировал не полный ответ, про энергозатратность в ответе говориться.

BFE>>От себя добавлю, что если для поиска использовать B-Tree с ключом в байт, то разница между 8-байтовым адресом и 16 байтовым адресом будет всего 8 операций сложения и 8 операций сравнения, что не выглядит чем-то из-за чего стоит переживать.
N>Что-то очень странное и неадекватное говоришь.
N>Во-первых, в B-Tree ключи используются полной длины. Ты с Trie не перепутал? Там частичные ключи таки структурированы мелкими порциями, по биту или байту.
В B-Tree не обязательно хранить копии ключей, если для спуска на следующий уровень достаточно части.
ChatGPT называет похожую структуру Multibit Trie. Да, наверное так правильнее, так как в B-Tree для коротких префиксов будут храниться пустые поля, что не имеет смысла...

N>Во-вторых, 8 дополнительных лукапов на скорости нормального современного магистрального раутера могут уложиться в доступные временны́е рамки только при определённых ограничениях,
8 дополнительных шагов потребуются, если ключ разбивать по 8 бит и всего два шага, если ключ разбивать по 32 бита. Разница будет в скорости перестройки дерева при изменении таблицы маршрутизации.

N>из которых чуть ли не первое это неиспользование DRAM. Возьми ценник на память, умножь на 10 (объективно за счёт того, что на 1 бит не 1 транзистор, а почти десяток) и ещё на 3 (накрутка производителя раутера), посмотри, сколько её нужно на современные потребности (меньше 128MB не рассматриваем) и оцени, сколько нефти придётся выложить провайдеру на такую железяку.
N>И тогда пролетавшие тут рядом цены типа 47 миллионов деревянных перестают удивлять.

А какую задачу мы обсуждаем? Диспетчеризацию магистрального роутера или же поиск по IP-адресам из черного списка? У этих задач ведь немного разные требования ?

Цена в 47 миллионов меня не удивляет, так как товар специфичный и мелкосерийный.
И вообще, в чём сложность алгоритма для магистрального маршрутизатора? Сколько у такого маршрутизатора подключений ? сотня? две сотни? в чём алгоритмическая сложность разбить 128 битное данное на 200 выходов?

Здравствуйте, Sinclair, Вы писали:

SK>>Всем остальным SMB предлагается делать так-же, ради пары дюжин VoIP акканутов?
S>Откуда взялся SMB? Железки выпускаются тем самым кровавым энтерпрайзом, огромными тиражами.

small medium business тоже хочет пользоваться телефонией (сюрприз), но при этом не имеет ресурсов на содержание своей инфраструктуры.

SK>>А затем вендорский RootCA со сроком действия 30 лет "утекает" (как это было и будет много раз) и смысл этого шапито нулевой.
S>:sigh: Если вендорский RooCA утекает, то в девайс заталкивается новая прошивка, подписанная приватным ключом этого устройства, в которой лежит новый RootCA.

Кто этим займется, скажем в сети состоящей из 7 городских парикмахерских? Даже нет- как им вовремя узнать о том, что нужно что-то неведомое сделать с аппаратами?

SK>>так еще же нужно криптовать сам медиа трафик RTP/RTSP.
S>Его криптование — факультативно. Если вы не хотите щифрованных переговоров, то можете не шифровать переговоры. А вот административные протоколы защищать абсолютно необходимо.

оно "факультативно" по причине заведомо недостаточной производительности процессоров в настольных VoIP. там ИЛИ хороший кодек, ИЛИ шифрование.

SK>> а как стандарт sRTP/RTSPs приняли совсем недавно, так еще позже его поддержка появилась в PBX и "в железе". на тот момент типичный офисный ПК целиком стоил дешевле настольного VoIP аппарата.
S>Брр. Если поддержка появилась недавно, то самый навороченный IP-телефон не стоил больше $150. Если речь о том, сколько стоили IP-телефоны 20 лет назад — всё ещё сильно дешевле типичного офисного ПК.

аппараты, которые умели "_И_" стоили немногим меньше тысячи долларов.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:
SK>small medium business тоже хочет пользоваться телефонией (сюрприз), но при этом не имеет ресурсов на содержание своей инфраструктуры.
Совершенно верно. Поэтому им нужен способ пользоваться облачной инфраструктурой. Которая совершенно несовместима с дегенеративными решениями, доминировавшими в этой области каких-то десять лет назад.

SK>Кто этим займется, скажем в сети состоящей из 7 городских парикмахерских? Даже нет- как им вовремя узнать о том, что нужно что-то неведомое сделать с аппаратами?
Очевидно, вендор аппарата. Или эксплуатант Cloud PBX.
Встречный вопрос: а NAT и VPN этим семи городским парикмахерским кто маинтейнит? Кто поддерживает VoIP PBX, через который подключены их телефоны? Кто им там юзер аккаунты нарезает, следит за квотами за всякими? Пароли им забытые сбрасывает кто?
У SMB точно есть деньги на команду из нескольких фулл-тайм админов, сертифицированных одновременно Микрософтом, Циской, и Броадсофт?

SK>оно "факультативно" по причине заведомо недостаточной производительности процессоров в настольных VoIP. там ИЛИ хороший кодек, ИЛИ шифрование.
Да как так-то? Поток-то шифруется обычно симметричными шифрами, а они работают практически бесплатно на фоне всего остального. А то, значит, видео 1280 * 720 30fps они успевают компрессировать, а AES применить — всё, тактов не хватает?

SK>аппараты, которые умели "_И_" стоили немногим меньше тысячи долларов.
Мне очень, очень странно то, что вы рассказываете. Не, я понимаю, что кому-то хотелось драть по тыще долларов с бедных бизнесменов. Но первый айфон, который вышел в 2007 году, уже умел это всё и ещё в сто раз больше вещей, и стоил (с прибылью!) $600. То есть инженерно всё можно было сделать — и железки были, и перформанса хватало аж с запасом. Просто обычное головожопство в стиле "и так сойдёт".

Здравствуйте, Stanislaw K, Вы писали:

SK>small medium business тоже хочет пользоваться телефонией (сюрприз), но при этом не имеет ресурсов на содержание своей инфраструктуры.

Вообще-то я уверен, что у такого SMB есть наёмный админ, пусть даже у него ещё 50 точек. А вот насколько этот админ копенгаген в теме — это уже как раз вопрос.
Я бы на его месте прочитал инструкцию на каждую железяку и подписался на announce и security рассылки. Но я уже с опытом, а я помню себя зелёного, который многого такого не понимал.

SK>>>А затем вендорский RootCA со сроком действия 30 лет "утекает" (как это было и будет много раз) и смысл этого шапито нулевой.
S>>:sigh: Если вендорский RooCA утекает, то в девайс заталкивается новая прошивка, подписанная приватным ключом этого устройства, в которой лежит новый RootCA.
SK>Кто этим займется, скажем в сети состоящей из 7 городских парикмахерских? Даже нет- как им вовремя узнать о том, что нужно что-то неведомое сделать с аппаратами?

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

SK>>>так еще же нужно криптовать сам медиа трафик RTP/RTSP.
S>>Его криптование — факультативно. Если вы не хотите щифрованных переговоров, то можете не шифровать переговоры. А вот административные протоколы защищать абсолютно необходимо.
SK>оно "факультативно" по причине заведомо недостаточной производительности процессоров в настольных VoIP. там ИЛИ хороший кодек, ИЛИ шифрование.

Ну по крайней мере до 2010 таки да; после — если и не хватало, то это чисто лень производителя.

Здравствуйте, B0FEE664, Вы писали:

BFE>Я процитировал не полный ответ, про энергозатратность в ответе говориться.

Ну ок.

N>>Во-вторых, 8 дополнительных лукапов на скорости нормального современного магистрального раутера могут уложиться в доступные временны́е рамки только при определённых ограничениях,
BFE>8 дополнительных шагов потребуются, если ключ разбивать по 8 бит и всего два шага, если ключ разбивать по 32 бита. Разница будет в скорости перестройки дерева при изменении таблицы маршрутизации.

По 32 несмешно даже думать, не будет на одной странице 2^32 узлов. И даже 2^18 не будет, а это примерно как раз размер fullview на сейчас.

N>>из которых чуть ли не первое это неиспользование DRAM. Возьми ценник на память, умножь на 10 (объективно за счёт того, что на 1 бит не 1 транзистор, а почти десяток) и ещё на 3 (накрутка производителя раутера), посмотри, сколько её нужно на современные потребности (меньше 128MB не рассматриваем) и оцени, сколько нефти придётся выложить провайдеру на такую железяку.
N>>И тогда пролетавшие тут рядом цены типа 47 миллионов деревянных перестают удивлять.

BFE>А какую задачу мы обсуждаем? Диспетчеризацию магистрального роутера или же поиск по IP-адресам из черного списка? У этих задач ведь немного разные требования ?

Я акцентировался на Tier1 Core. То есть это уровень вида "пучок 100Gbit/s линков от США до Европы" или "ближайший к самому толстому ДЦ гугла". Там про чёрные списки речь не идёт. Они включаются как минимум на их выходах к Tier2.

BFE>Цена в 47 миллионов меня не удивляет, так как товар специфичный и мелкосерийный.
BFE>И вообще, в чём сложность алгоритма для магистрального маршрутизатора? Сколько у такого маршрутизатора подключений ? сотня? две сотни? в чём алгоритмическая сложность разбить 128 битное данное на 200 выходов?

Во времени. Hard realtime с критическим временем в единицы наносекунд.
"Hard" в смысле не совсем на каждый пакетик, но чтобы потери не превышали, условно, 0.001%.

Здравствуйте, ·, Вы писали:

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 — не пройдёт.

Здравствуйте, Sinclair, Вы писали:

а напомни, пожалуйста, что мы в этой ветке обсуждаем?

Все проблемы от жадности и глупости

Здравствуйте, 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 ничего общего с входящими портами не имеет.