https://www.opennet.ru/openforum/vsluhforumID3/44163.html "IPv6 Neighbor Discovery Protocol routing vulnerability (http://security.freebsd.org/advisories/FreeBSD-SA-08:10.nd6.asc)" - уязвимость в реализации IPv6 протокола FreeBSD. Злоумышленник из близлежащей сети может использовать протокол Neighbor Discovery Protocol для создания или изменения записи в кэше соседних IPv6 сетей (neighbor cache) на FreeBSD шлюзе. Проблема присутствует во всех поддерживаемых версиях FreeBSD - 6.3 и 7.0. В качестве временного решения можно блокировать пакетным фильтром NDP (ICMPv6 type 135) сообщения из внешних сетей.<br><br>URL: http://security.freebsd.org/advisories/FreeBSD-SA-08:10.nd6.asc<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=18215<br> https://www.opennet.ru/openforum/vsluhforumID3/44163.html#11 Sat, 04 Oct 2008 11:29:31 GMT Как раз на скорости 300 км/ч и ходит TVG. <br>Разумеется, по специальному полотну - но все-таки по рельсам.<br> https://www.opennet.ru/openforum/vsluhforumID3/44163.html#10 Thu, 02 Oct 2008 17:22:29 GMT Мне сегодняшнее состояние TCP/IP напоминает ситуацию с преодолением сверхзвукового барьера, когда, до этого хорошо зарекомендовавший себя самолет, пытались адаптировать для полета на сверхзвуковых скоростях... Только разваливался он постоянно, пока принципиально новые технологии не реализовали, хотя наверное уместней был бы пример с поездами на магнитной подушке - сколько ни старайся, а 300 км в час по ЖД-полотну не выжмешь. TCP/IP сейчас тоже по швам трещит, 40 лет назад как-никак совсем все было по другому, то что сейчас через очередной хак под именем IPv6 пытаются на лишний десяток лет оттянуть агонию - проблемы не решает, а лишь усугубляет запущенность положения.<br> https://www.opennet.ru/openforum/vsluhforumID3/44163.html#9 Thu, 02 Oct 2008 15:11:11 GMT &gt;разработки и верификации протоколов? <br><br>Работающая голова на плечах, учитывающая реалии в которых будет работать протокол?А то если уж такие гранды которым десятилетия и по сей день несовершенны - почему бы собственно не попробовать подумать самому?А вдруг лучше получится?Совсем не факт, конечно, но попытаться можно.В частности и с другими goals :)<br><br>&gt;Было дело реализовывал простенький протокол для обмена данными с устройством, так и <br>&gt;то чуть мозг не сломал, рисуя диаграмки и отслеживая возможные состояния. <br><br>Это да.Но чем проще протокол тем меньше подобного геморроя.Кроме того - ну например я когда-то писал реализацию X-Modem.Мало того что его в природе 3 варианта так еще сам протокол крайне бестолковый, плохо переносит ошибки, легко теряет синхронизацию до фатальных последствий а некоторый софт еще и крайне нестандартно себя ведет (на что пришлось изгаляться с воркэраундами).Наплевал на все и сделал свой протокол, простой, надежный и стабильный как танк.Пусть и не самый быстрый на свете, но (учтя реали https://www.opennet.ru/openforum/vsluhforumID3/44163.html#8 Thu, 02 Oct 2008 14:48:17 GMT &gt;Интересно, а как быть, если фрагментация изначально существует в IP, <br><br>Просто: при разработке нового протокола сделать так чтобы не существовала.Замочив проблему как класс.Вроде кой-что по этой части даже сделано.<br><br>&gt;и вызвана она разным MTU? <br><br>Никто не спорит, если захотеть создать геморрой то эта цель вполне достижима.Ну вот, достигли.В итоге дошло до того что авторы прикладных программ (которых все это вообще по идее колебать не должно) для достижения оптимальной производительности подчас трахаются с определением максимально возможного MTU самопальными методами.Как раз чтобы срубить фрагментацию и достичь максимальной производительности (reassembly пакетов тормозит и роутеры и протокольный стэк).<br><br>&gt;И вообще, попробуй сделать свой протокол с аналогичной <br>&gt;(или лучшей) эффективностью работы в реальных сетях со всеми их проблемами! <br><br>А тут придется выбирать - или колосс на глиняных ногах с кучей костылей и подпорок или простой дизайн но может быть чуть менее эффективный в каких-то ситуациях.Как пример https://www.opennet.ru/openforum/vsluhforumID3/44163.html#7 Thu, 02 Oct 2008 13:04:10 GMT &gt;А тут на самом деле все просто. Хороший протокол должен быть прост <br>&gt;как топор, изящен и с понятной, четко определенной логикой.Тогда там будет <br>&gt;нечего ломать. <br><br>Это конечно хорошо, но с такими критериями сложно реализовать что-то =)<br><br>Вообще, для меня тема протоколов в ближайшие месяцы станет очень актуальной. Т.к. необходимо реализовать свой протокол и хотелось бы избежать граблей. Естественно сложность моей "поделки" и TCP/IP несравнима, но и знаний (опыта) у меня гораздо меньше. Поэтому взгляд пал на средство верификации SPIN и книжку "Design and validation of computer protocols". Интересно какие ещё есть средства разработки и верификации протоколов? <br><br>Было дело реализовывал простенький протокол для обмена данными с устройством, так и то чуть мозг не сломал, рисуя диаграмки и отслеживая возможные состояния. Как можно проанализировать все возможные "затыки" в протоколах уровня TCP даже представить не могу.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/44163.html#6 Thu, 02 Oct 2008 12:03:42 GMT &gt; TCP этому не соответствует. Дурь с фрагментацией, MSS, и вагоном прочей мутотени кардинально усложняют протокол.<br><br>Интересно, а как быть, если фрагментация изначально существует в IP, и вызвана она разным MTU? И вообще, попробуй сделать свой протокол с аналогичной (или лучшей) эффективностью работы в реальных сетях со всеми их проблемами!<br><br>Конечно, в TCP многое следовало бы сделать иначе (наприменр, ввести функции авторизации и компрессии прямо на уровне протокола); но "иначе" != "проще" !!!<br> https://www.opennet.ru/openforum/vsluhforumID3/44163.html#5 Thu, 02 Oct 2008 11:58:50 GMT А тут на самом деле все просто. Хороший протокол должен быть прост как топор, изящен и с понятной, четко определенной логикой.Тогда там будет нечего ломать.<br><br>TCP этому не соответствует. Дурь с фрагментацией, MSS, и вагоном прочей мутотени кардинально усложняют протокол. К тому же делался он во времена когда хакеры, вирусы и трояны были мифом. Да и половина других протоколов (ну вон хоть тот же DNS) отнюдь не сделаны с допущением что их будут долго и качественно пытаться сломать.Посему у того же DNS есть (неустранимые в рамках стандартного варианта протокола) дыры.<br><br>IPv6 с одной стороны сделали проще местами.Но только местами.С другой стороны наворотили для удобства юзеров.Это и удобства для хакеров заодно, потому что вопросами "а что будет если нехороший парень пошлет такие-то пакеты вон туда?" никто судя по всему не заботился.Заодно надо было под шумок перепахать TCP, устранив его некоторые фирменные грабли, как раз возможность есть.Но почему-то его предпочли оставить как есть.А зря.ИМХО еще не раз будут https://www.opennet.ru/openforum/vsluhforumID3/44163.html#4 Thu, 02 Oct 2008 11:46:18 GMT &gt;Зато вот это - весьма актуально <br>&gt;http://uinc.ru/news/sn10817.html <br><br>Что же будет когда хаксоры посмотрят на жаббер... :)))<br><br> https://www.opennet.ru/openforum/vsluhforumID3/44163.html#3 Thu, 02 Oct 2008 10:56:15 GMT &gt;не актуально <br><br>Кому-то может и нет. А вообще интересно сколько ещё дыр в реализации IPv6 найдут, не говоря уже о проблемах самого протокола?<br>