#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

EKCKABATOR54 Crucially, we rejected mechanisms to provide congestion control by allowing packet drops, due to the ability to introduce end-to-end side channels in the packet drop pattern.

EKCKABATOR54 может я не так понял о чем это

onon Они там WRED отключили? Или я тоже не понял?

EKCKABATOR54 но в любом же случае узел по середине может влияеть на дропы и rtt. А других сигналов перегрузки и нет

EKCKABATOR54 не знаю

onon Ну если там только loss-control то да, промежуточный узел может ограничивать транзитную скорость дропами

EKCKABATOR54 а если delay, то задержками

EKCKABATOR54 и какая разица

extraNaCl onon, ты жырнозавр. У мтс нет никаких инкрементов, и пробив работает. Но чи шо объяснять утенку, который даже прочитать не в состоянии, у него своя "правда мира"

onon Такая что если ты будешь задержки делать большие, тебя из транзитов выкинут

extraNaCl EKCKABATOR54, не слушай его. Он не разбирается, хуйню несет околотемную.

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

EKCKABATOR54 сложнее, надо чуть подумат

EKCKABATOR54 extraNaCl, давай ты тогда по теме пиши

onon extraNaCl, ты если такой способный, давай нам библиотеку запили для соединения симнат-симнат

onon Мы посмотрим, как она будет работать, и тогда уже будем думать

EKCKABATOR54 onon, а не надо большое. в пределеха допустимого делать задержки, трафик уже менятся будет

a6585d6c4a Is it possible to download i2pd from .i2p? I know only GitHub.

onon Если у тебя первый и последний - узлы атакующего, он может просто пропускать трафик меандром

onon И это будет видно

EKCKABATOR54 проблема же в том, чтобы понять, что они первый и последний

EKCKABATOR54 об этом и атака

onon Да

extraNaCl EKCKABATOR54, тебе нужно просто переползти на nym. Nym решит все твои проблемы

onon Здесь только либо несколько совпадений/подтверждений в течении времени, либо физический контроль конечной точки.

EKCKABATOR54 я это к чему всё. пока я не осознал, что loss-based хуже с точки зрения анонимности чем delay-based

extraNaCl onon, мтс соединяется через стандратный stun. Но ты же топик не читал, залупкин

onon extraNaCl, ты либо не в теме, либо пытаешься толсто троллить

extraNaCl EKCKABATOR54, правильно осознал, теперь беги на nym

onon МОжешь не стараться

EKCKABATOR54 я читал кучу статей, но мне показалось, что атаки в равной степени к двум видам относятся

EKCKABATOR54 не знаю что за nym

extraNaCl вот и погугли

onon loss-based хуже с точки зрения скорости

EKCKABATOR54 тогда похуй. можно просто побенчмаркать и проверить)

extraNaCl в их блоге куча статей

EKCKABATOR54 я то думал там с анонимностью проблемы

EKCKABATOR54 extraNaCl, есть ссылка?

extraNaCl onon, классический сливной бачок. Ссылку кинул - сошел на говно

EKCKABATOR54 а то что хуже с точки зрения скорости совсем не очевидно

onon extraNaCl, ждём от тебя библиотеку для пробива симметриков

EKCKABATOR54 более того

orignal no, i2pd is on github only

extraNaCl EKCKABATOR54, nym.com/blog?category=network

onon Стан не умеет симметрики соединять, только с инкрементом

extraNaCl onon, тебе, долбоебышу уже указано: мтс пробивается стандартно

EKCKABATOR54 с точки зрения анонимности, имеет смысл играть с задержками, что уже делает java. Как в такой сети будут delay-based нормально работать, я не знаю

EKCKABATOR54 orignal, есть же гит репа i2pd в i2p

EKCKABATOR54 оттуда собрать можно

orignal я к ней отношения не имею

EKCKABATOR54 и что за nym?

EKCKABATOR54 какой то криптоскам?

EKCKABATOR54 или впн

EKCKABATOR54 нахуй это мне?

onon ЯП был такой когда-то NYM

onon Недоделанный

EKCKABATOR54 ладно, onon, можешь на что нибудь сослаться почему lossbased должен хуже рабоать?

extraNaCl Вово, вылез ты недоделанный

EKCKABATOR54 очень интересно почитать

extraNaCl nym с nim перепутать

onon EKCKABATOR54, ява роутер работает на lossbased

onon Там скорости нет

EKCKABATOR54 конкретная реализация еще ни о чем не говорит

EKCKABATOR54 может они криворукие

EKCKABATOR54 нужны нормальне аргументы

onon Ну давай, попробую объяснить. В loss-based алгоритме отправитель продолжает увеличивать количество одновременно отправляемых пакетов (окно), пока не получит от получателя ответ о не потере пакета.

onon Потеря пакета на промежуточном роутере происходит при достижении определённого уровня заполнения буфера (RED)

extraNaCl EKCKABATOR54, на медиуме погугли про nym mixnet. Там выкладывали серию статей со всей теорией, подробностями и сравнениями. Скам-коин? Читай статьи найдешь ответ, а так на улицу выходишь и во все пальцем тыкаешь со словами скамкоин.

onon Постоянно заполненный буфер создаёт задержку доставки пакета (ведь он лежит в буфере, пока отправляются предыдущие пакеты)

EKCKABATOR54 extraNaCl, заебал

extraNaCl Заебал тут только ты со своим нытьем

onon А так как размер окна у нас ограничен, отправитель может отправлять новые пакеты только когда получил подтверждение получения пакетов

extraNaCl тебе к свету пытаются привести, а ты как тот обрыган из платоновской пещеры. Хотя куда тебе об этом знать

onon И при высокой задержке отправитель очень долго ждёт пока придёт подтверждение пакетов

onon И не может слать новые пакеты

onon Отсюда и низкая скорость передачи данных

onon Вопросы есть?

EKCKABATOR54 читаю, подожди

EKCKABATOR54 есть вопросы

EKCKABATOR54 логика не понятна

EKCKABATOR54 если буфер заполнен, то значит вся полоса занята и быстрее просто нельзя отправлять

onon Да

EKCKABATOR54 так что не значит, что скорость низка

EKCKABATOR54 она достигла доступного максимума

onon Да, скорость упёрлась в лимит

EKCKABATOR54 это то что и нужны

EKCKABATOR54 выжрать всю доступную полосу

onon Не совсем

EKCKABATOR54 почему?

onon Потому что задержки

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

EKCKABATOR54 и что что задержки?

EKCKABATOR54 задержки зависят от размера буфера

onon Ты когда сайт открываешь, тебе нравится по пять секунд ждать?

onon Каждую картинку

extraNaCl блэт, nym установи и задержек не будет

EKCKABATOR54 да отъебись

onon И в интерактивные игрушки так не пиграешь

EKCKABATOR54 интерактивные игрушки вообще мимо

EKCKABATOR54 в любом случае

EKCKABATOR54 ну ща, погоди

onon Ну так это работает на всех уровнях

EKCKABATOR54 все равно не понятно

onon И на уровне транспортов тоже

EKCKABATOR54 откуда задержки, если мы по максимум полосу выжираем

EKCKABATOR54 то что пакет в буфере лежит, не так страшно

EKCKABATOR54 иначе он будет просто у отправителя висеть

onon Ну так он же там долго лежит

EKCKABATOR54 но все равно висеть

onon Хорошо, давай ещё аргументов подкину.

onon Кроме congestion loss бывают random loss

EKCKABATOR54 на уровне стримов?

EKCKABATOR54 не должно быть

onon Т.е. случайные поткри пакетов не на транспорте

EKCKABATOR54 не должно быть

extraNaCl Блэт иди сходи почитай про теорию пакетных сетей, полез гусь в болото

EKCKABATOR54 ssu2 или ntcp2 переотправят

onon А например на уровне сети провайдера

onon Ну так у тебя же получатель всё-равно "дырку" в ряду пакетов получит

onon И отправил тебе "loss"

onon И отправитель сбросит скорость

extraNaCl да хули ты реднек реднеку чето объясняешь

onon Ещё тебе аргумент. В i2pd не реализован RED. Вообще, никак.

extraNaCl Один из пещеры не вылез, другой про наты не знает

onon Т.е. если будет транзит от явы через i2pd то лимит не будет работать.

EKCKABATOR54 1 - оно потеряется на уровне транспортов и транспорты переотправят. у стримов потери возникают только когда буфер перепонлняется

EKCKABATOR54 2 - это не мешает всему остальному интернету. cubic почти везде в используется и все быстро работает

EKCKABATOR54 3 - с тем, что полоса не идеальна ничего не поделаешь. точно также в delay based могут возникать задежки на всех уровнях

onon 1. Транспорт переотправит, да. Но с задержкой. И Клиент уже успеет сообщить о потере отправителю.

onon 2. Это мешает всему остальному интернету.

EKCKABATOR54 2 - почему тогда кубик везде, а не вегас, например?

onon 3. Всех перевести на BBR1/2

EKCKABATOR54 про bbr я тоже думал

onon Потому что если у тебя на одном маршрутизаторе встретятся кубик и ббр кубик не даст нормально ббр-у работать

onon А два кубика норм

onon И два ббр-а норм

EKCKABATOR54 и опять же

EKCKABATOR54 у кубика быстрый набор скорои

EKCKABATOR54 короче, че я думаю

EKCKABATOR54 это все болтовня

EKCKABATOR54 надо запрогаать и посмотреть

EKCKABATOR54 самое главное, что меня интересует - есть ли ограничения на стримы со стороны анонимности?

onon Я думаю тебе нужно побольше узнать как эти алгоритмы работают

EKCKABATOR54 ну ты не даешь каких то рассчетов

onon Анонимность у нас только в том, что если сайт на i2pd то это сразу видно

onon Потому что быстрее работает

EKCKABATOR54 ты то верно говоришь, но нет алгоритма который во всех ситуациях идеально работает

EKCKABATOR54 разные реализации это проблема

onon Согласен

EKCKABATOR54 надо будет деду мозги ебать

EKCKABATOR54 а можешь почитать статьи от тора?

EKCKABATOR54 и почему они 20 лет не могли придумтаь алгоритм?

onon Нету времени

EKCKABATOR54 я читал, но не понял, почему какой то из алгоритмов стримов может стать проблемой для ш2з

onon Потому что это не просто

EKCKABATOR54 может там в торе как то иначе устроено, и для них это проблема

EKCKABATOR54 ну да

onon У нас ещё есть лимит на размер окна

onon Из-за шифрования

EKCKABATOR54 ну давай я кину статьи. а ты почитаешь как будет время

EKCKABATOR54 я кстати еще что думал. если аллгоритм стримов прям в ssu перенести, то должно по идее работать еще лучше, чем на ntcp

EKCKABATOR54 blog.torproject.org/congestion-contrl-047

onon SSU2 надо давно переделать

onon Но там проблема в производительности

EKCKABATOR54 research.torproject.org/techreports/side-channel-analysis-2018-11-27.pdf

EKCKABATOR54 archive.torproject.org/websites/lists.torproject.org/pipermail/tor-dev/2020-June/014343.html

EKCKABATOR54 lists.torproject.org/pipermail/tor-dev/2020-January/014140.html

onon Слишком много

EKCKABATOR54 я не заставляю тебя сегодня читать всё

EKCKABATOR54 я может еще деду мозги пойду поебу потом, че он думаешь на этот счёт

EKCKABATOR54 еще возможно это, но я не читал еще cypherpunks.ca/~iang/pubs/defenestrator.pdf

EKCKABATOR54 самое главное первые 4 ссылки

EKCKABATOR54 а что с лимитом окна из за шифрования?

onon Это тебе Лось расскажет, если захочет.

onon Или деда можешь подоставать.

EKCKABATOR54 самое главное сейчас - понять может ли неправильно выбранные алгоритм стримов открыть возможность для деанона

onon Ну если он у тебя уникальный...

EKCKABATOR54 кроме этого

EKCKABATOR54 алгоритмы должны быть одинаковые на всех роутерах

onon Вот я сейчас пытаюсь нормальный delay сделать, и тут на маршруте появляется снарк с loss-control и засирает мне буфер.

onon И у меня всё обламывается.

EKCKABATOR54 я бы делал в тестовой сетке, а потом доебывал деда, чтобы он такой же делал

EKCKABATOR54 потому что два разных алгоритма это проблема по нескольким причинам

orignal как может снарк появиться на маршруте?

EKCKABATOR54 orignal, а что там с лимитом окна из за шифрования?

onon Очень просто, построил туннель через часть нашего маршрута

onon Да даже через один роутер

orignal какого лимита окна с каким шифроманием?

orignal о чем это вообще?

EKCKABATOR54 onon говорит про какой то лимит окна из за шифрования

onon Про таги

orignal ааа так это сессия а не шифрование

EKCKABATOR54 ладно, я ушел, вечером прочту

EKCKABATOR54 ну и че там с тхагам?

onon Уже вечер?

EKCKABATOR54 так а че лось непишет

onon Так и не напишет

EKCKABATOR54 почему

onon Потому что не хочет

EKCKABATOR54 понятно

onon Я же сказал, ответит, если захочет

onon Видать не хочет

EKCKABATOR54 "Unfortunately, the present/absent bit vector of missing packets in this window is a communication channel between malicious Tor relays or Internet routers and the Exit node. This effect was an obscure piece of ancient mix network lore until Nick Mathewson publicly documented it on tor-dev a little over a year ago:"

EKCKABATOR54 Вот, как я понимаю, основная проблема с CC

EKCKABATOR54 Но, как я уже писал, не понятно, какую информацию такое поведение дает, если есть транзит и пакеты шифруются для каждого узла отдельно

Vort у Тор вообще странное отношение к угрозам

EKCKABATOR54 ?

Vort сейчас ссылку найду для примера

Vort forum.torproject.org/t/dont-create-a-publicly-available-webpage-showing-bandwidth-history-or-any-statistics-about-the-machine-e-g-cpu-ram-usage-as-these-can-be-used-in-surprising-ways-to-attack-users/16451/2

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

Vort но, может, и я не прав

EKCKABATOR54 чет нихуя не понял что они там обсуждают, но видимо проблема в том, что опять же, по характеру трафика можно догадаться через какой релей соединялись ноды

EKCKABATOR54 Вот опять читаю статью

EKCKABATOR54 However, I should have made our constraints more explicit. Our choice of acceptable congestion signal mechanism is restricted by these design constraints: 1. No side channels between Guard and Exit, or between circuits 2. Incremental upgrade path 3. Fast response time 4. Cheater prevention

EKCKABATOR54 1 - как можно достиь первого пункта, если в лобом случае стримы ориентируются на rtt и loss, что в любом случае подвластно ноде между

EKCKABATOR54 либо я что то очень сильно не понимаю

Vort ну я имею в виду, что они довольно упёртые и если в чём-то ошибаются, то переубедить их очень проблематично

Vort то есть, не стоит считать их решения и обоснования гарантированно верными

Vort и ещё кое что - не только переубедить, но даже получить хоть какую-то реакцию сложно. форум разработчики, похоже, игнорируют из принципа

Vort если кто-то из юзеров знает ответ - тогда будет обсуждение, иначе - тишина

EKCKABATOR54 кстати вот еще над чем можно подумать - кто то может намеренно использовать более агрессивные алгоритмы и выйдет ситуация как с кубиком и ббр

Vort речь об атаках что ли?

EKCKABATOR54 в том числе

Vort атак, в том числе трафиком, в последнее время было достаточно

Vort что i2p, что tor глючили, но выдерживали

Vort о качестве работы сети в таких условиях говорить сложно. работает - и уже хорошо

Vort так что думаю особо тщательно такой сценарий продумывать смысла мало

EKCKABATOR54 в i2p, по словам анона и в джаве и в ш2зв loss-based.

EKCKABATOR54 а вот в тор delay-based

` <extraNaCl> ААА, это ` [РОСКОМНАДЗОР] про гоатсе написал под орижиналькой. А я подумал сам орижиналька

` Таблетки не забывай принимать, пока людей не начал резать, вместо котят)00

orignal потому что лось занят