На слешдоте обсуждали грузинскую цензуру по отношению к российским новостным сайтам. Утверждают, что блокировка - DNS-based. Похоже, что это и в самом деле так, но этим оно не ограничивается.
[13:42] dg@iddater:~$ dig @62.168.168.2 lenta.ru. any
; <<>> DiG 9.3.4 <<>> @62.168.168.2 lenta.ru. any
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49807
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;lenta.ru. IN ANY
;; AUTHORITY SECTION:
ru. 86400 IN SOA ns0.caucasus.net. root.caucasus.net. 2008102903 14400 3600 1209600 172800
;; Query time: 170 msec
;; SERVER: 62.168.168.2#53(62.168.168.2)
;; WHEN: Mon Aug 18 13:43:08 2008
;; MSG SIZE rcvd: 83
Видно, что люди решили проблему радикально, и в соответствии с принципом “Разве может что-нибудь хорошее прийти из Назарета?”, накрыли медным тазом целый TLD.
Кстати, есть у кого-нибудь предположения, что может означать такой странный serial?
Для особо умных, которые умеют обращаться с собственным рекурсором и не пользуются провайдерским, есть второй слой блокировки - на уровне IP.
Вот пинги lenta.ru:
PING 81.19.69.232 (81.19.69.232) 56(84) bytes of data.
From 80.241.178.70 icmp_seq=3 Packet filtered
--- 81.19.69.232 ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2009ms
Как видно, приезжает ICMP 3/13 от 80.241.178.70.
И соседнего адреса:
PING 81.19.69.233 (81.19.69.233) 56(84) bytes of data.
64 bytes from 81.19.69.233: icmp_seq=1 ttl=42 time=132 ms
64 bytes from 81.19.69.233: icmp_seq=2 ttl=42 time=131 ms
64 bytes from 81.19.69.233: icmp_seq=3 ttl=42 time=132 ms
--- 81.19.69.233 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2037ms
rtt min/avg/max/mdev = 131.702/132.192/132.802/0.544 ms
Как видно, тут сделано несколько поизбирательней - блокируется только "вражеская пропаганда".
От оценок я воздержусь, пусть каждый делает выводы сам.
[13:42] dg@iddater:~$ dig @62.168.168.2 lenta.ru. any
; <<>> DiG 9.3.4 <<>> @62.168.168.2 lenta.ru. any
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49807
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;lenta.ru. IN ANY
;; AUTHORITY SECTION:
ru. 86400 IN SOA ns0.caucasus.net. root.caucasus.net. 2008102903 14400 3600 1209600 172800
;; Query time: 170 msec
;; SERVER: 62.168.168.2#53(62.168.168.2)
;; WHEN: Mon Aug 18 13:43:08 2008
;; MSG SIZE rcvd: 83
Видно, что люди решили проблему радикально, и в соответствии с принципом “Разве может что-нибудь хорошее прийти из Назарета?”, накрыли медным тазом целый TLD.
Кстати, есть у кого-нибудь предположения, что может означать такой странный serial?
Для особо умных, которые умеют обращаться с собственным рекурсором и не пользуются провайдерским, есть второй слой блокировки - на уровне IP.
Вот пинги lenta.ru:
PING 81.19.69.232 (81.19.69.232) 56(84) bytes of data.
From 80.241.178.70 icmp_seq=3 Packet filtered
--- 81.19.69.232 ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2009ms
Как видно, приезжает ICMP 3/13 от 80.241.178.70.
И соседнего адреса:
PING 81.19.69.233 (81.19.69.233) 56(84) bytes of data.
64 bytes from 81.19.69.233: icmp_seq=1 ttl=42 time=132 ms
64 bytes from 81.19.69.233: icmp_seq=2 ttl=42 time=131 ms
64 bytes from 81.19.69.233: icmp_seq=3 ttl=42 time=132 ms
--- 81.19.69.233 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2037ms
rtt min/avg/max/mdev = 131.702/132.192/132.802/0.544 ms
Как видно, тут сделано несколько поизбирательней - блокируется только "вражеская пропаганда".
От оценок я воздержусь, пусть каждый делает выводы сам.
Уважаемые, а давайте пофлеймим? Я кое-что скажу, а вы мне в ответ скажете, что я дурак и нихрена не понимаю.
А скажу я вот что: цископикс (ну и его производные) - говно.
Нет, я не буду говорить про управляемость, я не буду говорить про фичи, я не буду говорить про производительность, я даже не буду говорить про унылое множество атак, от которых может защитить пикс. Речь не о "недоделках".
Речь о том, что PIX - говно по построению. Сам принцип, по которому действует PIX, не позволяет построить что-либо, кроме говна.
А именно, попытка анализировать и модифицировать пакеты в некотором контексте, выведенном из пролетающего мимо трафика, - идея заведомо ущербная. Вот возьмем TCP, к примеру. TCP по своему дизайну - end-to-end протокол. Функции согласования параметров, сборки потока, ретрансмиссии, контроля скорости и все остальные выполняются на оконечном устройстве. Попытка вмешаться в пролетающие пакеты без взятия на себя всех функций неминуемо ведет к неисчислимым бедствиям.
Перейдем к примерам.
Я тут повспоминал, и понял, что PIX последовательно и неуклонно просрал все полимеры по очереди.
ECN просрал? Тупо и линейно. PIX присылал RST на SYN с установленными ECN-флагами (CSCds23698).
SACK просрал? Еще как! С фейрверком. PIX и ASA рандомизируют TCP sequence numbers, а тот sequence number, который внутри SACK option - забыли (CSCse14419). Oops.
Window scaling просрал? Просрал самым классическим образом. До некоторой версии window scaling не поддерживался. Попытка контролировать window overshooting в сочетании с непониманием window scaling приводил понятно к чему: пикс думал, что окошко маааленькое, и дропал совершенно нормальные пакеты. Починили это несчастье только в 2006 году, если мне не изменяет склероз. Т.е. через 14 (!) лет после выхода RFC 1323. Аплодисменты.
Не, конечно, всё это цискоиндусы поправили. Но поправили они это только после того как. А иначе быть и не могло. Появление всех расширений предвидеть невозможно, а принцип функционирования не позволяет обходиться с ними по-человечески без допиливания софта. Это не случайные баги, это системное.
И совершенно понятно, что это все повторится вновь. Следующее расширение опять будет сломано. Мы все опять будем пялиться красными от недосыпа глазами в wireshark и тихо материться.
Вы мне скажете: Даня, ты дурачок, это же security, security is supposed to break things.
Так я вам отвечу: Ежели так, то глобальная ядреная война - это the ultimate security solution. Вот взять, долбануть всех Бомбой и чтобы никто и никуда, и чтобы ша, и чтобы тихо и ничего не шевелилось.
/me облачился в asbestos suit. Расчехляйте flamethrower, коллеги.
А скажу я вот что: цископикс (ну и его производные) - говно.
Нет, я не буду говорить про управляемость, я не буду говорить про фичи, я не буду говорить про производительность, я даже не буду говорить про унылое множество атак, от которых может защитить пикс. Речь не о "недоделках".
Речь о том, что PIX - говно по построению. Сам принцип, по которому действует PIX, не позволяет построить что-либо, кроме говна.
А именно, попытка анализировать и модифицировать пакеты в некотором контексте, выведенном из пролетающего мимо трафика, - идея заведомо ущербная. Вот возьмем TCP, к примеру. TCP по своему дизайну - end-to-end протокол. Функции согласования параметров, сборки потока, ретрансмиссии, контроля скорости и все остальные выполняются на оконечном устройстве. Попытка вмешаться в пролетающие пакеты без взятия на себя всех функций неминуемо ведет к неисчислимым бедствиям.
Перейдем к примерам.
Я тут повспоминал, и понял, что PIX последовательно и неуклонно просрал все полимеры по очереди.
ECN просрал? Тупо и линейно. PIX присылал RST на SYN с установленными ECN-флагами (CSCds23698).
SACK просрал? Еще как! С фейрверком. PIX и ASA рандомизируют TCP sequence numbers, а тот sequence number, который внутри SACK option - забыли (CSCse14419). Oops.
Window scaling просрал? Просрал самым классическим образом. До некоторой версии window scaling не поддерживался. Попытка контролировать window overshooting в сочетании с непониманием window scaling приводил понятно к чему: пикс думал, что окошко маааленькое, и дропал совершенно нормальные пакеты. Починили это несчастье только в 2006 году, если мне не изменяет склероз. Т.е. через 14 (!) лет после выхода RFC 1323. Аплодисменты.
Не, конечно, всё это цискоиндусы поправили. Но поправили они это только после того как. А иначе быть и не могло. Появление всех расширений предвидеть невозможно, а принцип функционирования не позволяет обходиться с ними по-человечески без допиливания софта. Это не случайные баги, это системное.
И совершенно понятно, что это все повторится вновь. Следующее расширение опять будет сломано. Мы все опять будем пялиться красными от недосыпа глазами в wireshark и тихо материться.
Вы мне скажете: Даня, ты дурачок, это же security, security is supposed to break things.
Так я вам отвечу: Ежели так, то глобальная ядреная война - это the ultimate security solution. Вот взять, долбануть всех Бомбой и чтобы никто и никуда, и чтобы ша, и чтобы тихо и ничего не шевелилось.
/me облачился в asbestos suit. Расчехляйте flamethrower, коллеги.
На этой неделе в Дублине проходит очередная встреча IETF. Я сижу в Москве и наблюдаю издалека. На сегодня большая часть WG уже выложила свои материалы: https://datatracker.ietf.org/meeting/72/materials.html. Поэтому наблюдать интересно.
Несколько штучек, которые меня заинтересовали:
Virtual Aggregation
Некоторое время назад Paul Francis в grow@ietf рассказал про свою статью "Reducing FIB Size through Virtual Aggregation".
С тех пор он передумал и решил дополнить свой подход BGP-сигнализацией для некоторой автоматизации и, соотвественно, опубликовать свой драфт уже не в GROW, а в IDR. Что он и сделал в начале этого месяца, взяв в соавторы Xiaohu Xu из Huawei. В idr@ietf успели пообсуждать этот драфт немного, поэтому, скорее всего, надо ждать версии -01 в скором времени.
Суть предложенного подхода заключается в инжектировании довольно коротких префиксов (локальных для данной AS), и выкидывания из FIB (но не из RIB) префиксов более длинных. Если использовать правильную систему туннелей (например MPLS-туннелей), то это не приведет к циклам, но, естественно, может удлинить пути для трафика в данной AS. Статья показывает, что если выкидывать из FIB не все префиксы, а только "непопулярные", то можно достичь значительного сокращения объема FIB, не сильно ухудшив общую картину с оптимальностью путей трафика. Я в такой результат вполне верю: по словам коллеги из одного [довольно большого] оператора, на 120K префиксов уходит всего лишь около 1% трафика.
Кроме того, инжектирование покрывающих префиксов может помочь улучшить время сходимости. Здесь есть два фактора:
1) Покрывающий префикс распространяется независимо от специфичного и может служить своего рода fall back'ом для случая, когда next-hop специфичного префикса погиб. С несколькими одинаковыми префиксами обеспечить fallback труднее из-за того, что BGP-спикер анонсирует только лучший путь - это так называемая проблема path invisibility.
2) Маршрутизаторы, которые вбрасывают покрывающие префиксы, образуют уровень иерархии. Соответственно, как указал Robert Raszuk, само число роутеров, которые должны нести fallback пути, меньше. Плюс, если использовать BFD для быстрого обнаружения падения next-hop'ов, то BFD mesh серьезно уменьшается.
Надо сказать, в отношении BGP части у авторов получилась какая-то хуавейня, извините за выражение. Никакой особой автоматизации не получилось, а та, которая получилась, попросту опасна. Но это не отменяет ценности самого подхода, и, думается, что BGP часть поддается доработке.
Я эту конструкцию на прошлых выходных собрал в лабе. Работает (с некоторыми недочетами). Но получилось слишком сложно, чтобы рекомендовать это для реального внедрения прямо сегодня.
Текущая версия драфта: http://tools.ietf.org/html/draft-francis-idr-intra-va-00
Презентация на IETF72, кратко описывающая суть предложенного: http://www.ietf.org/proceedings/08jul/slides/idr-3.pdf
TANA
На этой встрече IETF запланирована BoF сессия TANA (Techniques for Advanced Networking Applications)
О чем речь? В одной из своих заметок я упоминал, что для peer-to-peer приложений пригодился бы новый транспортный протокол со специальным congestion control. Вот TANA именно про это. Цель в разработке алгоритма congestion control, который позволял бы p2p не мешать интерактивным задачам, но тем не менее эффективно утилизировал бы полосу, когда она не затребована другими приложениями. Насколько я понял, технология уже есть и используется в Bittorrent DNA.
BoF session по TANA будет 31-го июля. С нетерпением жду minutes.
TANA BoF agenda: http://www.ietf.org/proceedings/08jul/agenda/tana.txt
TANA Problem Statement: http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
Материалы с IETF P2PI Workshop: http://www.funchords.com/p2pi/ (чисто для смеху, там есть Position Paper of the RIAA - это очень смешно)
RRG on Loc/ID split
После прошлогоднего IAB Workshop on Routing and Addressing в списке рассылки RRG (Routing Research group) идет очень активная работа на предмет как намреорганизовать Рабкрин переделать архитектуру маршрутизации в Internet. Подходов там целая куча: LISP, Six/One, Ivip, TRRP и еще несколько. Останавливаться на них я не буду, отсылаю заинтересованных читателей к архиву maillist'а и соотвествующим статьям и драфтам.
На сессии RRG было (или только будет?) выступление Joel Halpern с очень правильной мыслью. Можно устроить разделение функций locator/identifier не внутри сетевого уровня, а между сетевым и транспортным уровнем: на сетевом locator, а на транспортном identifier. В принципе, идея не новая, но очень, по-моему, правильная. Пойдя по этому пути, можно избежать довольно опасных вещей, которые предлагаются в рамках того же LISP, например.
Презентация Joel Halpern: http://www.ietf.org/proceedings/08jul/slides/RRG-0.pdf
Несколько штучек, которые меня заинтересовали:
Virtual Aggregation
Некоторое время назад Paul Francis в grow@ietf рассказал про свою статью "Reducing FIB Size through Virtual Aggregation".
С тех пор он передумал и решил дополнить свой подход BGP-сигнализацией для некоторой автоматизации и, соотвественно, опубликовать свой драфт уже не в GROW, а в IDR. Что он и сделал в начале этого месяца, взяв в соавторы Xiaohu Xu из Huawei. В idr@ietf успели пообсуждать этот драфт немного, поэтому, скорее всего, надо ждать версии -01 в скором времени.
Суть предложенного подхода заключается в инжектировании довольно коротких префиксов (локальных для данной AS), и выкидывания из FIB (но не из RIB) префиксов более длинных. Если использовать правильную систему туннелей (например MPLS-туннелей), то это не приведет к циклам, но, естественно, может удлинить пути для трафика в данной AS. Статья показывает, что если выкидывать из FIB не все префиксы, а только "непопулярные", то можно достичь значительного сокращения объема FIB, не сильно ухудшив общую картину с оптимальностью путей трафика. Я в такой результат вполне верю: по словам коллеги из одного [довольно большого] оператора, на 120K префиксов уходит всего лишь около 1% трафика.
Кроме того, инжектирование покрывающих префиксов может помочь улучшить время сходимости. Здесь есть два фактора:
1) Покрывающий префикс распространяется независимо от специфичного и может служить своего рода fall back'ом для случая, когда next-hop специфичного префикса погиб. С несколькими одинаковыми префиксами обеспечить fallback труднее из-за того, что BGP-спикер анонсирует только лучший путь - это так называемая проблема path invisibility.
2) Маршрутизаторы, которые вбрасывают покрывающие префиксы, образуют уровень иерархии. Соответственно, как указал Robert Raszuk, само число роутеров, которые должны нести fallback пути, меньше. Плюс, если использовать BFD для быстрого обнаружения падения next-hop'ов, то BFD mesh серьезно уменьшается.
Надо сказать, в отношении BGP части у авторов получилась какая-то хуавейня, извините за выражение. Никакой особой автоматизации не получилось, а та, которая получилась, попросту опасна. Но это не отменяет ценности самого подхода, и, думается, что BGP часть поддается доработке.
Я эту конструкцию на прошлых выходных собрал в лабе. Работает (с некоторыми недочетами). Но получилось слишком сложно, чтобы рекомендовать это для реального внедрения прямо сегодня.
Текущая версия драфта: http://tools.ietf.org/html/draft-francis-idr-intra-va-00
Презентация на IETF72, кратко описывающая суть предложенного: http://www.ietf.org/proceedings/08jul/slides/idr-3.pdf
TANA
На этой встрече IETF запланирована BoF сессия TANA (Techniques for Advanced Networking Applications)
О чем речь? В одной из своих заметок я упоминал, что для peer-to-peer приложений пригодился бы новый транспортный протокол со специальным congestion control. Вот TANA именно про это. Цель в разработке алгоритма congestion control, который позволял бы p2p не мешать интерактивным задачам, но тем не менее эффективно утилизировал бы полосу, когда она не затребована другими приложениями. Насколько я понял, технология уже есть и используется в Bittorrent DNA.
BoF session по TANA будет 31-го июля. С нетерпением жду minutes.
TANA BoF agenda: http://www.ietf.org/proceedings/08jul/agenda/tana.txt
TANA Problem Statement: http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
Материалы с IETF P2PI Workshop: http://www.funchords.com/p2pi/ (чисто для смеху, там есть Position Paper of the RIAA - это очень смешно)
RRG on Loc/ID split
После прошлогоднего IAB Workshop on Routing and Addressing в списке рассылки RRG (Routing Research group) идет очень активная работа на предмет как нам
На сессии RRG было (или только будет?) выступление Joel Halpern с очень правильной мыслью. Можно устроить разделение функций locator/identifier не внутри сетевого уровня, а между сетевым и транспортным уровнем: на сетевом locator, а на транспортном identifier. В принципе, идея не новая, но очень, по-моему, правильная. Пойдя по этому пути, можно избежать довольно опасных вещей, которые предлагаются в рамках того же LISP, например.
Презентация Joel Halpern: http://www.ietf.org/proceedings/08jul/slides/RRG-0.pdf
Уважаемые френды и коллеги, в связи с успешным проебанием телефона, прошу содействия в восстановлении контактов - бэкап телефона был тухл, древен, и вообще на новый аппарат залиться не смог.
Оставляйте, пожалуйста, телефоны в комментах тут (скринятся) или присылайте на dbg-сабака-net-geek.org. Очень прошу. Мне ваши контакты были очень ценны. Спасибо и извините за предоставленные неудобства.
Оставляйте, пожалуйста, телефоны в комментах тут (скринятся) или присылайте на dbg-сабака-net-geek.org. Очень прошу. Мне ваши контакты были очень ценны. Спасибо и извините за предоставленные неудобства.
Что обычно говорят жены своим мужьям, когда уезжают в отпуск, а мужья остаются дома? Ну, например, "много не пей", или там "будешь девок водить - яйца оторву". А вот моя любимая супруга, уезжаючи, сказала: "дорогой, ну ты только по книжным не злоупотребляй, а то я ведь тебя знаю".
Действительно, этому пороку я подвержен. Захожу в книжный магазин - у меня начинается такая легкая лихорадка, немножко кружится голова, и чую подступающее безумия. Выхожу обычно со стопкой в 5-6 книжек - это, считай, легко отделался.
Это у меня наследственное. Мой дед, Павел Давыдович, был широко известен в нашем маленьком городке. Во всех библиотеках и книжных магазинах его знали и всегда были ему рады. Ну и меня, понятно. Благо дед меня таскал по этим злачным местам с малолетства. И домашнюю библиотеку дед содержал. Не в смысле полки и книжки, а натуральную библиотеку, куда можно было взять и записаться. Дед выписывал читательский билет и вперед - бери книжку или две и читай на здоровье.
Собственно, в киоск Союзпечати дед на пенсии устроился не просто так. Тут приходили читатели. Никакой подпольщины и диссидентщины, не подумайте. Просто все знали, что можно подойти, познакомиться и записаться в библиотеку. Я ошивался там в этом киоске после школы. Поэтому запах свежей типографской краски и табака - это очень, очень для меня клево.
А вот дядька мой - вот он натуральный маньяк. В нашу квартиру помещалось тысячи три томов и все было как-то цивилизованно, а в дядькину помещалось в два раза больше и там были Книжные Джунгли. Каждый год мы ездили в бабушке в деревню, что на Урале, и проездом гостили в Среднеуральске у тетки и дядьки и моих двоюродных брата и сестры. Это было офигительно, на самом деле. Помимо всего прочего, дядька собирал фантастику. Всю. Все что из фантастики издавалось в стране, у него было. Так вот, у него в квартире книги везде, вообще везде. Из любой точки протянешь руку, а у тебя в руке что-нибудь очень интересное. Дядьке на днях будет 70. С днем рождения, дядя Гера!
Да. Чего-то я заболтался. Я хотел сказать, что в один из последних заходов в книжный (дорогая, всего три раза за этот месяц, не больше, клянусь!), я приобрел пару книжек Лео Каганова. Как я раньше это пропустил, я не знаю. Мне очень понравилось. Много смеялся, немного грустил. В общем, удовольствие получал. Рекомендую.
Действительно, этому пороку я подвержен. Захожу в книжный магазин - у меня начинается такая легкая лихорадка, немножко кружится голова, и чую подступающее безумия. Выхожу обычно со стопкой в 5-6 книжек - это, считай, легко отделался.
Это у меня наследственное. Мой дед, Павел Давыдович, был широко известен в нашем маленьком городке. Во всех библиотеках и книжных магазинах его знали и всегда были ему рады. Ну и меня, понятно. Благо дед меня таскал по этим злачным местам с малолетства. И домашнюю библиотеку дед содержал. Не в смысле полки и книжки, а натуральную библиотеку, куда можно было взять и записаться. Дед выписывал читательский билет и вперед - бери книжку или две и читай на здоровье.
Собственно, в киоск Союзпечати дед на пенсии устроился не просто так. Тут приходили читатели. Никакой подпольщины и диссидентщины, не подумайте. Просто все знали, что можно подойти, познакомиться и записаться в библиотеку. Я ошивался там в этом киоске после школы. Поэтому запах свежей типографской краски и табака - это очень, очень для меня клево.
А вот дядька мой - вот он натуральный маньяк. В нашу квартиру помещалось тысячи три томов и все было как-то цивилизованно, а в дядькину помещалось в два раза больше и там были Книжные Джунгли. Каждый год мы ездили в бабушке в деревню, что на Урале, и проездом гостили в Среднеуральске у тетки и дядьки и моих двоюродных брата и сестры. Это было офигительно, на самом деле. Помимо всего прочего, дядька собирал фантастику. Всю. Все что из фантастики издавалось в стране, у него было. Так вот, у него в квартире книги везде, вообще везде. Из любой точки протянешь руку, а у тебя в руке что-нибудь очень интересное. Дядьке на днях будет 70. С днем рождения, дядя Гера!
Да. Чего-то я заболтался. Я хотел сказать, что в один из последних заходов в книжный (дорогая, всего три раза за этот месяц, не больше, клянусь!), я приобрел пару книжек Лео Каганова. Как я раньше это пропустил, я не знаю. Мне очень понравилось. Много смеялся, немного грустил. В общем, удовольствие получал. Рекомендую.
Я надеялся, что здравый смысл восторжествует, и С. Терентьева оправдают. Нет, дали год условно.
Что я имею по этому поводу сказать.
Социальная рознь у меня со всей этой сволотой существует объективно. Эту рознь не надо разжигать. Они сами замечательно c этим справляются. В том числе и такими вот приговорами.
А что касается методов наведения порядка среди прокуроров, ментов, журналистов и депутатов, то децимации должны помочь.
Что я имею по этому поводу сказать.
Социальная рознь у меня со всей этой сволотой существует объективно. Эту рознь не надо разжигать. Они сами замечательно c этим справляются. В том числе и такими вот приговорами.
А что касается методов наведения порядка среди прокуроров, ментов, журналистов и депутатов, то децимации должны помочь.
Сейчас в end2end-interest идет интересная дискуссия: Why do we need TCP flow control (rwnd). Там выступают очень правильные люди и говорят очень интересные вещи. David P. Reed (тот самый) поделился очень правильной мыслью:
У меня есть предположение, что мы наблюдаем это прямо сейчас в некоторых реализациях TCP.
Часто на форумах встречаются вопросы про сообщение "TCP: Treason Uncloaked!". Некоторые предполагают, что это атака, некоторые - что это ошибка в реализации TCP.
Код ядра, где возникает это сообщение, вполне прозрачен: если получатель закрыл окно, а у нас есть сегменты "в полете", то что-то здесь не так. В принципе RFC1122 (пункт 4.2.2.16) настоятельно не рекомендует получателю так поступать:
Я предполагаю, что такое поведение получателя - это не ошибка, а намеренное следование принципу, который высказал David Reed. И в самом деле, у нас теперь много мобильных устройств. Чем они характерны? У них мало памяти и они часто выходят в интернет через соединения с огромным RTT.
В этих условиях будет разумным анонсировать относительно большое окно, но буфер подо все окно не резервировать, а надеяться на то, что приложение будет выгребать данные достаточно быстро, и буфер не успеет заполниться. Конечно, помимо всего прочего, у этих устройств относительно слабый CPU, и приложение иногда не успевает потреблять данные из сокета. Тогда стеку не остается ничего другого, кроме как окошко прикрыть, несмотря на то, что раньше окно было анонсированно довольно большое.
Хорошо такое поведение или плохо? С одной стороны у мобильного стека большого выбора нет: линк с большим RTT хочется держать заполненным, но памяти под соотвествующий буфер нет. С другой, стек сервера в случае tcp treason продолжает режим retransmit'ов, а не входит в tcp persist, как было бы, если окошко закрылось нормально, т.е. генерирует пакетов больше, чем нужно.
Есть у кого-нибудь машина, куда приходит много мобильных клиентов? С благодарностью приму запись трафика TCP-сессий, в которых возникал tcp treason. Хочется навести кое-какую статистику.
Может быть, кто-нибудь хорошо знакомый с реализациями TCP на мобильных устройствах может подтвердить или опровергнуть предположение об аллокации TCP-буферов? Идеально - ссылка на документацию.
Некоторые авторы связывают сообщение "TCP: Treason Uncloaked" с DoS-атаками и странным поведением apache. Но все что удается найти по этому поводу - не более чем circumstatial evidence. Мне не ясен механизм, как таким образом можно заDoSить машину. Исчерпать память ядра буферами? Есть у кого-нибудь из уважаемых читателей более внятные свидетельства о связи tcp treason с DoS-атаками?
P.S.: Но вот эта презентация, конечно же, вносит некоторую ясность ;)
So the rwnd parameter is NOT actually measuring buffer pool size. It is actually a control loop that measures the endpoint application's ability to do work.
У меня есть предположение, что мы наблюдаем это прямо сейчас в некоторых реализациях TCP.
Часто на форумах встречаются вопросы про сообщение "TCP: Treason Uncloaked!". Некоторые предполагают, что это атака, некоторые - что это ошибка в реализации TCP.
Код ядра, где возникает это сообщение, вполне прозрачен: если получатель закрыл окно, а у нас есть сегменты "в полете", то что-то здесь не так. В принципе RFC1122 (пункт 4.2.2.16) настоятельно не рекомендует получателю так поступать:
A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left. However, a sending TCP MUST be robust against window shrinkingВоспроизвести такое сообщение очень просто. Вот скрипт для hping3, который делает именно это. Если будете экспериментировать, не забудьте зафильтровать исходящие RST.
Я предполагаю, что такое поведение получателя - это не ошибка, а намеренное следование принципу, который высказал David Reed. И в самом деле, у нас теперь много мобильных устройств. Чем они характерны? У них мало памяти и они часто выходят в интернет через соединения с огромным RTT.
В этих условиях будет разумным анонсировать относительно большое окно, но буфер подо все окно не резервировать, а надеяться на то, что приложение будет выгребать данные достаточно быстро, и буфер не успеет заполниться. Конечно, помимо всего прочего, у этих устройств относительно слабый CPU, и приложение иногда не успевает потреблять данные из сокета. Тогда стеку не остается ничего другого, кроме как окошко прикрыть, несмотря на то, что раньше окно было анонсированно довольно большое.
Хорошо такое поведение или плохо? С одной стороны у мобильного стека большого выбора нет: линк с большим RTT хочется держать заполненным, но памяти под соотвествующий буфер нет. С другой, стек сервера в случае tcp treason продолжает режим retransmit'ов, а не входит в tcp persist, как было бы, если окошко закрылось нормально, т.е. генерирует пакетов больше, чем нужно.
Есть у кого-нибудь машина, куда приходит много мобильных клиентов? С благодарностью приму запись трафика TCP-сессий, в которых возникал tcp treason. Хочется навести кое-какую статистику.
Может быть, кто-нибудь хорошо знакомый с реализациями TCP на мобильных устройствах может подтвердить или опровергнуть предположение об аллокации TCP-буферов? Идеально - ссылка на документацию.
Некоторые авторы связывают сообщение "TCP: Treason Uncloaked" с DoS-атаками и странным поведением apache. Но все что удается найти по этому поводу - не более чем circumstatial evidence. Мне не ясен механизм, как таким образом можно заDoSить машину. Исчерпать память ядра буферами? Есть у кого-нибудь из уважаемых читателей более внятные свидетельства о связи tcp treason с DoS-атаками?
P.S.: Но вот эта презентация, конечно же, вносит некоторую ясность ;)
Очередной интересный Google Tech Talk:
http://www.youtube.com/watch?v=IBPg9Lyta3A&feature=user
Докладчик Nick Feamster. Он, помимо всего прочего, автор нескольких очень интересных статей про interdomain routing: http://www.cc.gatech.edu/~feamster/publications/. Очень рекомендую к прочтению.
http://www.youtube.com/watch?v=IBPg9Lyta3A&feature=user
Докладчик Nick Feamster. Он, помимо всего прочего, автор нескольких очень интересных статей про interdomain routing: http://www.cc.gatech.edu/~feamster/publications/. Очень рекомендую к прочтению.
Вечер пятницы - время для досужих мечтаний. Вот и мне после вкусного ужина со стаканчиком пива слегка подумалось.
Вот какая есть штука: между работой data plane и работой control/management plane сетевого элемента есть существенный концептуальный разрыв.
Если опустить некоторые детали и упростить, то control/management plane оперирует понятиями логического интерфейса, адреса, маршрута, т.д., а на data plane ничего подобного нет, там есть физическая веревка, несколько таблиц и несколько простых операций: lookup в той или иной таблице (с возможным ее пополнением) по одному или нескольким полям, переписывание части пакета, передача его в физическую веревку или опять на lookup в другой таблице. А все эти subinterfaces, pseudowires, vlans, vrfs и прочая, и прочая, в терминах которых мы конфигурим наши железки, - их на самом деле нет, это интерфейс к реальным механизмам форвардинга, абстракция, предоставленная нам производителем роутера.
Хорошо это или плохо? С одной стороны это хорошо, поскольку необходимо, т.к. те же протоколы маршрутизации оперируют теми же понятиями интерфейса, адреса, маршрута. С другой стороны, иногда эти выразительные средства не позволяют добиться желаемого поведения сетевого элемента, или позволяют ценой немыслимых извращений, или насколько криво отображаются в примитивные средства data plane, что это приводит к самым неочевидным эффектами, из которых потеря в производительность не самый страшный, хотя и самый распространенный. Leaky abstraction и abstraction inversion во всей своей красе.
До относительно недавних пор все двигалось в одну сторону - когда кастомеры били ногами вендора, вендор вводил фичу, расширяя и усложняя control plane'овую абстракцию, но все же оставаясь в ее рамках. Так и появлялись всякие "this over that support", "whatever scalability enhancements", "virtual something", которыми пестрят release notes каждой новой версии софта. Это оптимизации, это поддержанные на официальном уровне accidental features, это закрытие зияющих прорех абстракции. И все это ad hoc, все лоскутно, все реактивно, а не проактивно.
Однако, недавно циску (у некоторых других вендоров есть, кажется, похожие вещи) это достало, и она сделала EVC (Ethernet Virtual Circuit). Это конфигурационный механизм, который позволяет определять поведение непосредственно в терминах match-rewrite-forward. По .1q'шным тэгам, но это уже хорошо. Этот EVC - большой рулез. Это гибкий механизм, который позволяет делать более естественно, то что можно было делать раньше с помощью субинтерфейсов, и делать новые, ранее невозможные вещи. Правильная, очень правильная вещь.
Но этого мало. Я хочу распространения похожего механизма на все data plane'овые операции. Это очень облегчило бы жизнь. Сразу исчезли бы глупые и крайне неочевидные хаки типа global keyword для статических маршрутов в VRF, или совершенно ужасного GRT prefix import into a VRF. Можно было бы строить интересные и полезные наложенные топологии со смешанным L2/L3 форвардингом (ох, у фанатов модели OSI сейчас будет инфаркт, хехе).
Я прекрасно отдаю себе отчет, что возможности разных платформ очень разные, и такой механизм был бы очень тесно привязан к платформе. Ну и что. Можно сделать это платформозависимо, можно придумать что-то вроде MQC - на самом деле, если немного расширить PBR, скомбинировать его с EVC, то получится похоже на то, что я хочу.
Вот какая есть штука: между работой data plane и работой control/management plane сетевого элемента есть существенный концептуальный разрыв.
Если опустить некоторые детали и упростить, то control/management plane оперирует понятиями логического интерфейса, адреса, маршрута, т.д., а на data plane ничего подобного нет, там есть физическая веревка, несколько таблиц и несколько простых операций: lookup в той или иной таблице (с возможным ее пополнением) по одному или нескольким полям, переписывание части пакета, передача его в физическую веревку или опять на lookup в другой таблице. А все эти subinterfaces, pseudowires, vlans, vrfs и прочая, и прочая, в терминах которых мы конфигурим наши железки, - их на самом деле нет, это интерфейс к реальным механизмам форвардинга, абстракция, предоставленная нам производителем роутера.
Хорошо это или плохо? С одной стороны это хорошо, поскольку необходимо, т.к. те же протоколы маршрутизации оперируют теми же понятиями интерфейса, адреса, маршрута. С другой стороны, иногда эти выразительные средства не позволяют добиться желаемого поведения сетевого элемента, или позволяют ценой немыслимых извращений, или насколько криво отображаются в примитивные средства data plane, что это приводит к самым неочевидным эффектами, из которых потеря в производительность не самый страшный, хотя и самый распространенный. Leaky abstraction и abstraction inversion во всей своей красе.
До относительно недавних пор все двигалось в одну сторону - когда кастомеры били ногами вендора, вендор вводил фичу, расширяя и усложняя control plane'овую абстракцию, но все же оставаясь в ее рамках. Так и появлялись всякие "this over that support", "whatever scalability enhancements", "virtual something", которыми пестрят release notes каждой новой версии софта. Это оптимизации, это поддержанные на официальном уровне accidental features, это закрытие зияющих прорех абстракции. И все это ad hoc, все лоскутно, все реактивно, а не проактивно.
Однако, недавно циску (у некоторых других вендоров есть, кажется, похожие вещи) это достало, и она сделала EVC (Ethernet Virtual Circuit). Это конфигурационный механизм, который позволяет определять поведение непосредственно в терминах match-rewrite-forward. По .1q'шным тэгам, но это уже хорошо. Этот EVC - большой рулез. Это гибкий механизм, который позволяет делать более естественно, то что можно было делать раньше с помощью субинтерфейсов, и делать новые, ранее невозможные вещи. Правильная, очень правильная вещь.
Но этого мало. Я хочу распространения похожего механизма на все data plane'овые операции. Это очень облегчило бы жизнь. Сразу исчезли бы глупые и крайне неочевидные хаки типа global keyword для статических маршрутов в VRF, или совершенно ужасного GRT prefix import into a VRF. Можно было бы строить интересные и полезные наложенные топологии со смешанным L2/L3 форвардингом (ох, у фанатов модели OSI сейчас будет инфаркт, хехе).
Я прекрасно отдаю себе отчет, что возможности разных платформ очень разные, и такой механизм был бы очень тесно привязан к платформе. Ну и что. Можно сделать это платформозависимо, можно придумать что-то вроде MQC - на самом деле, если немного расширить PBR, скомбинировать его с EVC, то получится похоже на то, что я хочу.
В ru_telecom@lj сегодня часа в 2 ночи какое-то существо запостило следующий текст (пост удален, но яндекс все помнит):
Ахринеть. Круто. Смотрим.
$ whois vfp.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).
domain: VFP.RU
type: CORPORATE
nserver: ns.vfp.ru. 195.68.187.163
nserver: ns.rusmedia.net.
state: REGISTERED, DELEGATED
org: Vash Finansovy Popechitel Ltd.
phone: +7 495 2536984
fax-no: +7 495 9564386
e-mail: boris@vfp.ru
registrar: RUCENTER-REG-RIPN
created: 1997.09.24
paid-till: 2008.10.01
source: TC-RIPN
Last updated on 2008.05.23 10:41:53 MSK/MSD
На TLD-серверах все зашибись:
$ dig +nostats +nocomments vfp.ru @NS.RIPN.NET
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @NS.RIPN.NET
; (1 server found)
;; global options: printcmd
;vfp.ru. IN A
vfp.ru. 345600 IN NS ns.rusmedia.net.
vfp.ru. 345600 IN NS ns.vfp.ru.
ns.vfp.ru. 345600 IN A 195.68.187.163
Смотрим на авторитетные сервера для зоны:
$ dig +nostats +nocomments vfp.ru @195.68.187.163
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163
; (1 server found)
;; global options: printcmd
;vfp.ru. IN A
vfp.ru. 7200 IN A 195.68.187.163
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 195.68.187.163
$ dig +nostats +nocomments vfp.ru @195.68.187.163 soa
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163 soa
; (1 server found)
;; global options: printcmd
;vfp.ru. IN SOA
vfp.ru. 7200 IN SOA ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 195.68.187.163
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net
; (1 server found)
;; global options: printcmd
;vfp.ru. IN A
vfp.ru. 7200 IN A 213.243.107.145
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 213.243.107.145
ns.rusmedia.net. 43200 IN A 195.230.64.13
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net soa
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net soa
; (1 server found)
;; global options: printcmd
;vfp.ru. IN SOA
vfp.ru. 7200 IN SOA ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 213.243.107.145
ns.rusmedia.net. 43200 IN A 195.230.64.13
Что видим? Видим стандартную ньюбисную ошибку - отредактировали зону, но забыли поменять сериал. Бывает. Но ведь нет, надо обязательно возопить, что теплая куча в штанах - это не мы обгадились, это проделки рейдеров (кровавой гэбни, жыдомарсиан, цру, бабы яги). Тьфу.
17 мая 2008 года около 11:30 рейдерами был захвачен домен, с 1997 года принадлежащий ОАО "Вашъ Финансовый Попечитель" - VFP.RU. Подложный сайт компании разместился в хостинговом центре ХЦ РБК. 20 мая контроль над доменом был восстановлен. В базе данных компании-регистратора RU-CENTER появились новые, легитимные данные об адресе настоящего сайта ОАО "ВФП" - 195.68.187.163. Но не все серверы доменных имен обновили информацию о вэб-сайте. Например, серверы компании Голден Телеком (194.85.128.10 и 194.85.129.80) указывают на заведомо ложный адрес нашего сайта. Получается, что Рунет (по крайней мере его часть) не является свободной средой распространения информации, а используется некоторыми нечистоплотными операторами для выполнения рейдерских заказов.
Ахринеть. Круто. Смотрим.
$ whois vfp.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).
domain: VFP.RU
type: CORPORATE
nserver: ns.vfp.ru. 195.68.187.163
nserver: ns.rusmedia.net.
state: REGISTERED, DELEGATED
org: Vash Finansovy Popechitel Ltd.
phone: +7 495 2536984
fax-no: +7 495 9564386
e-mail: boris@vfp.ru
registrar: RUCENTER-REG-RIPN
created: 1997.09.24
paid-till: 2008.10.01
source: TC-RIPN
Last updated on 2008.05.23 10:41:53 MSK/MSD
На TLD-серверах все зашибись:
$ dig +nostats +nocomments vfp.ru @NS.RIPN.NET
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @NS.RIPN.NET
; (1 server found)
;; global options: printcmd
;vfp.ru. IN A
vfp.ru. 345600 IN NS ns.rusmedia.net.
vfp.ru. 345600 IN NS ns.vfp.ru.
ns.vfp.ru. 345600 IN A 195.68.187.163
Смотрим на авторитетные сервера для зоны:
$ dig +nostats +nocomments vfp.ru @195.68.187.163
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163
; (1 server found)
;; global options: printcmd
;vfp.ru. IN A
vfp.ru. 7200 IN A 195.68.187.163
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 195.68.187.163
$ dig +nostats +nocomments vfp.ru @195.68.187.163 soa
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @195.68.187.163 soa
; (1 server found)
;; global options: printcmd
;vfp.ru. IN SOA
vfp.ru. 7200 IN SOA ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 195.68.187.163
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net
; (1 server found)
;; global options: printcmd
;vfp.ru. IN A
vfp.ru. 7200 IN A 213.243.107.145
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 213.243.107.145
ns.rusmedia.net. 43200 IN A 195.230.64.13
$ dig +nostats +nocomments vfp.ru @ns.rusmedia.net soa
; <<>> DiG 9.3.4 <<>> +nostats +nocomments vfp.ru @ns.rusmedia.net soa
; (1 server found)
;; global options: printcmd
;vfp.ru. IN SOA
vfp.ru. 7200 IN SOA ns.vfp.ru. root.ns.vfp.ru. 200701230 7200 600 3600000 7200
vfp.ru. 7200 IN NS ns.rusmedia.net.
vfp.ru. 7200 IN NS ns.vfp.ru.
ns.vfp.ru. 7200 IN A 213.243.107.145
ns.rusmedia.net. 43200 IN A 195.230.64.13
Что видим? Видим стандартную ньюбисную ошибку - отредактировали зону, но забыли поменять сериал. Бывает. Но ведь нет, надо обязательно возопить, что теплая куча в штанах - это не мы обгадились, это проделки рейдеров (кровавой гэбни, жыдомарсиан, цру, бабы яги). Тьфу.
