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

S>А всего-то надо было с самого начала вклеивать в устройства поддержку SSL и идентификацию по device certificate.

Вклеивать на уровень IP адреса?

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

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

S> Вопрос такой какую часть занимает поиск Ip адреса от передачи данных? А там нет никакого кэша итд.

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

Мало того, даже в домашнем раутере может быть, что процессор проверил адреса, сделал подмену для NAT и добавил в очередь для сетевухи. Никаких тебе тотальных копирований, всё происходит в одном участке памяти.

Для PC сетевухи с таким свойством известны с середины 90х: Intel 8255x и потомки, 3Com линии Vortex-Boomerang-Cyclone (3C905 и тому подобные), DEC Tulip и т.п.

S> Во, что в итоге упираемся?

На такой обработке — в логику раутинга.

S> И так и не ответил, а как жили при 32 разрядных процессорах?

С чем именно жили?
IPv4 адрес влезает в 32 бита целиком.
IPv6 — как и с 64-битными, обрабатывается по частям.

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

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

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

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

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

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

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

N>А стабилизируется IoT — ещё что-то выползет...

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

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

N>Спросил тех кто прямо сейчас в теме. Ответ очень странный: большинство вендоров проверяют на https://en.wikipedia.org/wiki/Internet_Mix который не менялся существенно с ≈2013, и фиксируют результаты по нему.

N>А в этом источнике больше половины пакетов по объёму это 576 байт (Simple Imix) и по любому меньше 1500 (Accurate Imix).

А у тебя нет под рукой доступа к большому роутеру? Можешь посмотреть статистику трафика, в пакетах и байтах?

N>Так что или им надо методики менять, или я оказался точнее в прогнозе, чем ты.

Ну вообще, очень странно. Кто, интересно, херачит много мелких пакетов? Мелкие пакеты люто дорого стоят, когда проходят через wifi (и я подозреваю, через любой радиоканал) — там очень большая дырка между пакетами. А агрегировать их на источнике совсем не сложно, если мы про видеопоток говорим...

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

N>Спросил тех кто прямо сейчас в теме. Ответ очень странный: большинство вендоров проверяют на https://en.wikipedia.org/wiki/Internet_Mix который не менялся существенно с ≈2013, и фиксируют результаты по нему.

А, я понял, откуда такое может взяться.

Это те реализации TCP, которые консервативно шлют полукилобайтные пакеты, не имея на эту тему более светлых идей.

Да, получается, ты был прав в своем прогнозе, а я — нет.

В этом плане переход на IPv6, с его гарантиями на доставку пакетов длинной 1280 байтов без фрагментации, конечно, играют на пользу человечеству.

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


S>> Вопрос такой какую часть занимает поиск Ip адреса от передачи данных? А там нет никакого кэша итд.

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

То есть ждать адаптеры и прочее не нужно?
Или их значительно больше чем ядер процессора?

N>Мало того, даже в домашнем раутере может быть, что процессор проверил адреса, сделал подмену для NAT и добавил в очередь для сетевухи. Никаких тебе тотальных копирований, всё происходит в одном участке памяти.
То есть на передачу данных время не уходит?
При этом в IP6 большим пакетом, а значит и меньше обращений к процессору.
Не все так однозначно.

Джамбограммы
IPv6-пакет может нести больше данных с помощью опции jumbo payload в расширенном заголовке Hop-By-Hop Options[7]. Эта опция позволяет обмениваться пакетами с размером полезных данных на 1 байт меньшим чем 4 ГиБ (232 − 1 = 4294967295 байт). Пакет с таким содержимым называют джамбограммой.

Так как протоколы TCP и UDP оба имеют поля длины, ограниченные 16 битами, для поддержки джамбограмм требуется реализация модифицированных протоколов транспортного уровня. Джамбограммы могут работать только на подключениях с MTU, большим чем 65583 октетов (более 65 535 октетов для полезных данных, 40 октетов для фиксированного заголовка и 8 октетов для расширенного заголовка Hop-By-Hop Options).

N>Для PC сетевухи с таким свойством известны с середины 90х: Intel 8255x и потомки, 3Com линии Vortex-Boomerang-Cyclone (3C905 и тому подобные), DEC Tulip и т.п.

S>> Во, что в итоге упираемся?

N>На такой обработке — в логику раутинга.

S>> И так и не ответил, а как жили при 32 разрядных процессорах?

N>С чем именно жили?
N>IPv4 адрес влезает в 32 бита целиком.
32 бита это 4 байта. Тут жмых говорит именно о 8 ми, что их хватает на все случаи жизни. А 32 бита не хватает.
Ладно не буду больше тратить время. Спасибо!

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

N>при полном переходе на IPv6 его таблица минимум удвоится, если не дойдёт до миллиона, как сейчас с IPv4
Это, кстати, совершенно не точно. Из-за узости IPv4 диапазона блоки адресов выдаются небольшими порциями и происходит сильная фрагментация адресного пространства. Один клиент запросил 32 адреса, через год захотел ещё 16, а соседний блок уже занят и теперь надо новое правило добавлять, а не просто расширить диапазон. Поэтому таблицы выглядат как исключения из исключений из исключений из правил. В случае IPv6 можно выдавать диапазоны с огромным запасом, миллиард тому, триллион другому и хватит на много-много лет, это значительно уменьшает количество строк в таблицах роутинга.

Где-то я читал, что даже если таблица удвоится при полном переходе, то она будет всё равно по объёму в несколько раз меньше, чем сейчас для IPv4, несмотря на то, что строки в таблице шире.

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

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

N>>при полном переходе на IPv6 его таблица минимум удвоится, если не дойдёт до миллиона, как сейчас с IPv4
·>Это, кстати, совершенно не точно.

Про миллион — не точно, про удвоение — точно. Ещё дохрена провайдеров не брали никакой v6.

·> Из-за узости IPv4 диапазона блоки адресов выдаются небольшими порциями и происходит сильная фрагментация адресного пространства. Один клиент запросил 32 адреса, через год захотел ещё 16, а соседний блок уже занят и теперь надо новое правило добавлять, а не просто расширить диапазон.

Сказочки. В мировом раутинге меньше /24 не выделялось никогда, а последние годы даже /16 сложно было получить (было перед полным исчерпанием).

Описанное тобой могло происходить внутри блоков провайдеров, но там сильно легче перенумероваться. И вообще многие сдавали старые блоки при получении новых, побольше.

·> Поэтому таблицы выглядат как исключения из исключений из исключений из правил.

Таблицы выглядят как результат раздачи "он обосновал свои 10k, отдаём".

·> В случае IPv6 можно выдавать диапазоны с огромным запасом, миллиард тому, триллион другому и хватит на много-много лет, это значительно уменьшает количество строк в таблицах роутинга.

Ничего из этого не спасёт от того, что если кто-то захотел AS, он будет добиваться AS.

·>Где-то я читал, что даже если таблица удвоится при полном переходе, то она будет всё равно по объёму в несколько раз меньше, чем сейчас для IPv4, несмотря на то, что строки в таблице шире.

Прогнозы на ровном месте кто угодно рисует.

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

S> Вопрос такой какую часть занимает поиск Ip адреса от передачи данных? А там нет никакого кэша итд.
S> Во, что в итоге упираемся?

Я думаю, на магистральных свитчах процессор не участвует в передаче данных. И не факт, что участвует память.

S> И так и не ответил, а как жили при 32 разрядных процессорах?

Хорошо жили. Не было 40-гигабитных линков.

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

N>>Спросил тех кто прямо сейчас в теме. Ответ очень странный: большинство вендоров проверяют на https://en.wikipedia.org/wiki/Internet_Mix который не менялся существенно с ≈2013, и фиксируют результаты по нему.

Вот таки свежее: https://stats.ams-ix.net/sflow/size.html
До 109 — треть от общего количества. (вычел 18 на заголовок кадра. кажется, таки 18. потому что 802.1q) Непонятно, что они такое.
Ещё треть — от 1006 до 1495. Жаль, что не рассказано точнее (я бы выставил границу в 1280 или 1300).
Ровно 1500 (если я правильно понял только четверть. И вот они как раз в основном TCP при больших потоках.

А реалтайм видео сюда не ложится хотя бы потому, что ему нужен UDP, а не TCP.
Возможно, ту треть 1006-1495 даёт как раз оно.
И недополнение хвостика до сотни байт как раз в его духе.

Pzz>А, я понял, откуда такое может взяться.
Pzz>Это те реализации TCP, которые консервативно шлют полукилобайтные пакеты, не имея на эту тему более светлых идей.

Вот таких я не видел уже чёрт-те сколько лет.
Всё-таки в основном гонят по максимуму согласно PMTUD, и только если оно не даёт результата, переходят на более мелкие.

Pzz>Да, получается, ты был прав в своем прогнозе, а я — нет.
Pzz>В этом плане переход на IPv6, с его гарантиями на доставку пакетов длинной 1280 байтов без фрагментации, конечно, играют на пользу человечеству.

Не повлияет.

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

S>> Вопрос такой какую часть занимает поиск Ip адреса от передачи данных? А там нет никакого кэша итд.
S>> Во, что в итоге упираемся?

Pzz>Я думаю, на магистральных свитчах процессор не участвует в передаче данных. И не факт, что участвует память.

Я не про это. Сколько времени занимает передача данных и использование процессора.
То есть процессор занимается получением неких данных для шин которые и передают данные
Сколько таких шин на ядро? И что в итоге является лимитирующей стадией.
Передача данных (ядра простаивают) или есть очередь для получения данных от процессора (ядра заняты на 100%)?

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

n> AB>А там, где это имеет значение, используют различные техники повышения эффективности полезной нагрузки (типа jumbo frames)
n> Ни разу не видел на дальних маршрутах MTU больше 1500. Часто даже меньше, за счёт MPLS и прочих туннелей.

На "дальних" возможно и нет. Внутри ЦОД(ов) одного "оператора" (под оператором я подразумеваю условный Google), где внутреннего трафика на порядки больше — повсеместно.

n> AB> и сокращения маршрутов (чего в условиях IPv4 добиться или очень сложно или нереально).
n> IPv6 этому ничуть не помогает.

Тут подразумевается, что IPv6 благодаря своей широкой маске, где можно закодировать физическое местоположение и еще какую-то логику, позволяет относительно легко маршрутизировать большую часть трафика внутри ЦОД(ов) одного оператора чуть ли не на уровне стоечных свичей очень сильно разгружая "голову". Т.е. пакет вышедший из юнита в соседнюю стойку делает (если смотреть упрощенно) три хопа (src -> стоечный свич -> свич соседней стойки -> dst).

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

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

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

И меня удивляет это желание впихнуть в стандарт адресации (транспортного уровня) криптографию (прикладного уровня). Этим должны заниматься более другие стандарты.

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

Здравствуйте, Stanislaw K, Вы писали:
SK>Я не встречал человека, который бы думал что может скрыть публичный адрес в публичной сети и тем самым обеспечить некую безопасность.
Тысячи их. В параллельной подветке я писал: ещё каких-то 15 лет назад подавляющее большинство вендоров оборудования для IP-телефонии и видеоконференций искренне полагали, что можно вообще ничего не шифровать и не прятать, так как железки всё равно воткнуты во "внутреннюю сеть предприятия" без роутинга наружу. В лучшем случае — рудиментарная авторизация по plaintext юзернейму/паролю (с фабричной конфигурацией типа admin/admin).
SK>И меня удивляет это желание впихнуть в стандарт адресации (транспортного уровня) криптографию (прикладного уровня). Этим должны заниматься более другие стандарты.
Никакого желания впихивать в стандарт адресации криптографию у меня нету. У меня есть желание запретить людям полагаться на NAT в качестве инструмента контроля доступа. Одним из симптомов порочного образа мысли как раз и является "всё равно всем нужен NAT как мера безопасности, так что мы можем не париться с размером пространства адресов"

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

S>А всего-то надо было с самого начала вклеивать в устройства поддержку SSL и идентификацию по device certificate.

Надо понимать, что SSL в те времена был OpenSSL (или его предшественник от RSA), а это такая себе библиотека для вклеивания в не-UNIX платформы.

А написать SSL с нуля тоже упражнение не для слабых духом.

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

S>Ага, то есть запихать FTP, SIP, парсер XML, и ещё 100500 всяких кунштюков — проблем нет, а банальный SSL — ресурсов нету?
S>Сказки.

SSL на пару порядков сложнее, чем всё остальное, тобой перечисленное.

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

А как датчики давления в автомобильных шинах умудряются протянуть 10 лет на заводской батарейке?

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

K>>Вот попробуй представить по шагам — если Петя как-то связываетя с Васей и задал вопрос "почему наша система не работает? срочно надо!", кто из них что должен сделать дальше в каждом из вариантов. Чтобы задача была не такой тривиальной — пусть Вася в это время находится за рулем, но у него имеется гарнитура или громкий режим на телефоне.
O>Во-первых, специально для не-pro-связистов придумали DNS, чтобы называть вещи своими именами (а не номерами, ёмкость которых в голове быстро заканчивается).

Угу. А теперь предположим, что Петя с Васей как раз специалисты по упомянотому тобой DNS, и именно его и чинят...

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

SK>>Я не встречал человека, который бы думал что может скрыть публичный адрес в публичной сети и тем самым обеспечить некую безопасность.
S>Тысячи их. В параллельной подветке я писал: ещё каких-то 15 лет назад подавляющее большинство вендоров оборудования для IP-телефонии и видеоконференций искренне полагали, что

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

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


SK>>И меня удивляет это желание впихнуть в стандарт адресации (транспортного уровня) криптографию (прикладного уровня). Этим должны заниматься более другие стандарты.
S>Никакого желания впихивать в стандарт адресации криптографию у меня нету. У меня есть желание запретить людям полагаться на NAT в качестве инструмента контроля доступа. Одним из симптомов порочного образа мысли как раз и является "всё равно всем нужен NAT как мера безопасности, так что мы можем не париться с размером пространства адресов"

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

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

Pzz>Угу. А теперь предположим, что Петя с Васей как раз специалисты по упомянотому тобой DNS, и именно его и чинят...
И теперь ради того, чтобы этим 2 деятелям было проще, должны страдать миллионы всех остальных?