Извини, я позавчера посмотрела tcpdump'ом на сессии своего браузера с некоторыми поулярными серверами - ID в некоторых сессиях нифига не случайный, а увеличивается на единичку с каждым пакетом.
я не утверждаю что нельзя определить -- я эту тему не исследовал. я просто рецензирую конкретные документы
и хочу обратить внимание, что большинство клиентских компов -- винды, у которых tcp timestamp по умолчанию выключен и посему они пролетают мимо первого документа
что, конечно не исключает существования других методов, но они не из этих документов будут
>ну не рандомизация у отвечающих устройств никак не облегчает процедуру подсчета устройств
Мой поинт не в том, что устройство ОТВЕЧАЮЩЕЕ, а в том, что существуют стеки, которые не рандомизируют. Истинность данного утверждения доказана приведенным выше примером.
>не говоря уж о том, что рандомизнуть принудительно при натинге завсегда можно не могу только сказать насколько это принято
Что ж вы так все любите прятаться в домике security by obscurity? Вот тебе веселая ссылка про рандомизацию всякого при NAT - я много смеялась ;-) https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk35623
Мой поинт не в том, что устройство ОТВЕЧАЮЩЕЕ, а в том, что существуют стеки, которые не рандомизируют. Истинность данного утверждения доказана приведенным выше примером.
да ради бога, разве я с этим спорил? только если таких стеков окажется о-малое от числа хостов -- что это изменит?
Что ж вы так все любите прятаться в домике security by obscurity?
а это ничего, что практически вся безопасность на этом принципе основана? начиная от паролей и до криптухи?
Вот тебе веселая ссылка про рандомизацию всякого при NAT - я много смеялась ;-)
>>Что ж вы так все любите прятаться в домике security by obscurity?
>а это ничего, что практически вся безопасность на этом принципе основана? начиная от паролей и до криптухи?
Ты меня пугаешь. Про неприменимость security by obscurity в криптографии все давно сказано. Например: http://en.wikipedia.org/wiki/Kerckhoffs%27_principle
>> Вот тебе веселая ссылка про рандомизацию всякого при NAT - я много смеялась ;-)
>а что смешного?
Очередная смешная иллюстрация того, что бывает при попытке вмешаться в модель безопасности end2end.
Ты меня пугаешь. Про неприменимость security by obscurity в криптографии все давно сказано. Например: http://en.wikipedia.org/wiki/Kerckhoffs%27_principle
гы. тут говрится, что секретность алгоритма не делает криптографию надежной. секретным должен быть ключ. с принудительной рандомизацией мы не приносим никакого секретного алгоритма. так что нарушения принципа нет.
Очередная смешная иллюстрация того, что бывает при попытке вмешаться в модель безопасности end2end.
а где смеяться-то? а то я вижу только вполне разумную попытку прикрыть дырявый софт.
Короче, дорогой друг. Суть нашего спора сводится к тому, что мы исходим из разных предпосылок. Я убеждена, что исходить мы должны из сквозной связности узлов, на которую потом накладывать политики ограничения доступа, в частности. Попытка убедить меня, что нужно сначала сломать к чертовой матери всю связность (прикрываясь зачем-то священной коровой безопасности, вместо того, чтобы обеспечивать полноценный контроль доступа), а потом в поте лица (стоя и в гамаке) бороться с трудностями - скорее всего безнадежна ;) "Сначала мы учим своих детей ходить и говорить, а потом хотим, чтобы они сидели и молчали"(с).
нет. я исхожу из того, что должна быть сквозная связность или нет -- определяется конкретной задачей. в какой-то она нужнна, в какой-то нет. причем может быть так, что на определенном сетевом участке связность сквозная, потом нет, а между оконечными -- сквозная, но не для внешнего мира.
например: на интернетовском бэкбоне связность сквозная, между двумя CE-устройствами только по одному предоставленному IP (тарифный план), между двумя площадками через VPN -- сквозная, при этом внешний мир не должен знать сколько каких устройств на площадках, что бы например не мог сделать вывод о динамике или планах по развитию бизнеса.
почему именно так -- может быть по разным причинам. как и исходя из прямых требований безопасности, так и косвенных (что бы из анализа трафика нельзя было сделать выводов об происходящих процессах и тенденциях), так и из экономическо-технических (следствия особенностей тарифных планов и предоставляемых подключений).
два вопроса: 1) а кто бы (что почитать?) взялся за обратную задачу - убедить меня, что 100% связность всего ТырьНета не является такой же "священной коровой"?
2) типа,следствие - на как долго хватить диапазона IPv6, если следовать принципу 100% связности (как я его понял) - всем устройствам, включая умные холодильники, сотовые телефоны, и прочую "мелочь" ? Не случится ли так же - все начнут резервировать адреса "большими порциями" , чтобы не париться с "объединением" мелких одсеток?
сорри, очепятки.. вопрос №2 читать как: типа,следствие - на как долго может хватить диапазона IPv6, если следовать принципу 100% связности (как я его понял) - всем устройствам, включая умные холодильники, сотовые телефоны, и прочую "доступную через ИНет мелочь", давать "белые" адреса ? Не случится ли так же, как с IPv4 - все конторы начнут резервировать адреса "большими порциями" , чтобы не париться с "объединением" мелких подсеток?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
furrry![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 10 Nov 2008 20:43 (UTC)no subject
Date: 10 Nov 2008 21:50 (UTC)я не утверждаю что нельзя определить -- я эту тему не исследовал.
я просто рецензирую конкретные документы
и хочу обратить внимание, что большинство клиентских компов -- винды, у которых tcp timestamp по умолчанию выключен и посему они пролетают мимо первого документа
что, конечно не исключает существования других методов, но они не из этих документов будут
no subject
Date: 10 Nov 2008 22:45 (UTC)У меня (на моем маке) ID рандомизируется. Я говорю про то, что отвечающие мне устройства не всегда его рандомизируют.
no subject
Date: 10 Nov 2008 22:53 (UTC)не говоря уж о том, что рандомизнуть принудительно при натинге завсегда можно
не могу только сказать насколько это принято
no subject
Date: 10 Nov 2008 23:12 (UTC)Мой поинт не в том, что устройство ОТВЕЧАЮЩЕЕ, а в том, что существуют стеки, которые не рандомизируют. Истинность данного утверждения доказана приведенным выше примером.
>не говоря уж о том, что рандомизнуть принудительно при натинге завсегда можно
не могу только сказать насколько это принято
Что ж вы так все любите
прятаться в домикеsecurity by obscurity? Вот тебе веселая ссылка про рандомизацию всякого при NAT - я много смеялась ;-)https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk35623
no subject
Date: 11 Nov 2008 06:03 (UTC)да ради бога, разве я с этим спорил?
только если таких стеков окажется о-малое от числа хостов -- что это изменит?
а это ничего, что практически вся безопасность на этом принципе основана? начиная от паролей и до криптухи?
а что смешного?
no subject
Date: 11 Nov 2008 09:50 (UTC)>а это ничего, что практически вся безопасность на этом принципе основана? начиная от паролей и до криптухи?
Ты меня пугаешь. Про неприменимость security by obscurity в криптографии все давно сказано. Например:
http://en.wikipedia.org/wiki/Kerckhoffs%27_principle
>> Вот тебе веселая ссылка про рандомизацию всякого при NAT - я много смеялась ;-)
>а что смешного?
Очередная смешная иллюстрация того, что бывает при попытке вмешаться в модель безопасности end2end.
no subject
Date: 11 Nov 2008 10:21 (UTC)гы. тут говрится, что секретность алгоритма не делает криптографию надежной. секретным должен быть ключ.
с принудительной рандомизацией мы не приносим никакого секретного алгоритма. так что нарушения принципа нет.
а где смеяться-то? а то я вижу только вполне разумную попытку прикрыть дырявый софт.
no subject
Date: 11 Nov 2008 09:54 (UTC)"Сначала мы учим своих детей ходить и говорить, а потом хотим, чтобы они сидели и молчали"(с).
no subject
Date: 11 Nov 2008 10:29 (UTC)в какой-то она нужнна, в какой-то нет. причем может быть так, что на определенном сетевом участке связность сквозная, потом нет, а между оконечными -- сквозная, но не для внешнего мира.
например: на интернетовском бэкбоне связность сквозная, между двумя CE-устройствами только по одному предоставленному IP (тарифный план), между двумя площадками через VPN -- сквозная, при этом внешний мир не должен знать сколько каких устройств на площадках, что бы например не мог сделать вывод о динамике или планах по развитию бизнеса.
почему именно так -- может быть по разным причинам. как и исходя из прямых требований безопасности, так и косвенных (что бы из анализа трафика нельзя было сделать выводов об происходящих процессах и тенденциях), так и из экономическо-технических (следствия особенностей тарифных планов и предоставляемых подключений).
no subject
Date: 12 Nov 2008 07:21 (UTC)1) а кто бы (что почитать?) взялся за обратную задачу - убедить меня, что 100% связность всего ТырьНета не является такой же "священной коровой"?
2) типа,следствие - на как долго хватить диапазона IPv6, если следовать принципу 100% связности (как я его понял) - всем устройствам, включая умные холодильники, сотовые телефоны, и прочую "мелочь" ? Не случится ли так же - все начнут резервировать адреса "большими порциями" , чтобы не париться с "объединением" мелких одсеток?
no subject
Date: 12 Nov 2008 07:42 (UTC)вопрос №2 читать как: типа,следствие - на как долго может хватить диапазона IPv6, если следовать принципу 100% связности (как я его понял) - всем устройствам, включая умные холодильники, сотовые телефоны, и прочую "доступную через ИНет мелочь", давать "белые" адреса ? Не случится ли так же, как с IPv4 - все конторы начнут резервировать адреса "большими порциями" , чтобы не париться с "объединением" мелких подсеток?