|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 16 Feb 2005 18:39:10
To : Eugene Grosbein
Subject : logo
--------------------------------------------------------------------------------
16 Feb 05, Eugene Grosbein writes to Slawa Olhovchenkov:
EG>>> Далеко не всегда можно доверять source IP/source port в пакете.
EG>>> Особенно когда пакет пришел из чужой системы. Это очень плохо -
EG>>> порождает бардак в децентрализованной сети IP-сети.
SO>> Обоснуй чем именно это плохо в общем случае.
SO>> Я пока не вижу как недоверие src IP порождает бардак в IP сети.
EG> Возможно, "порождает" не вполне точное слово; не порождает, но
EG> не мешает и даже поощряет.
Hе вижу, покажи. Вообще, бардак, как и разруха -- в головах, а не сортирах.
EG>>>>> Что он может помогать безопасности - надо обосновывать тебе.
SO>>>> Это позволяет с IPS/IDS/файрволов разрывать нежелательные
SO>>>> соединения.
EG>>> Их можно блокировать не хуже и без спуфинга,
SO>> Расскажи как.
EG> Рассказать, как пакеты дропать на границе сети?
Да-да, особенно в случае когда IDS вовсе не на границе стоит.
SO>> Очень желательно что бы при этом у тебя произошло освобождение
SO>> ресурсов.
EG> Спуфинг - не единственный способ сообщить защищаемому серверу, что
EG> коннект можно очистить, хотя и очень хороший конечно.
Расскажи как. При этом не выходя из своей желаемой модели доверенности.
EG> Hо кроме этой вполне заменяемой фичи возможность спуфинга несет imho
EG> гораздо больше вреда.
Это только мнение, без обоснования.
EG>>>>>>> по дефолту?
SO>>>>>> По какому дефолту? Это дефолт в каком месте?
EG>>>>> В архитектуре сети надо бы иметь, в генах.
SO>>>> Hет, это будут плохие гены. Это будет плохая сеть.
EG>>> Чем?
SO>> Потому что сеть получится очень сложной, не децентрализированной, с
SO>> большими накладными расходами. Различные приятные фичи в такой сети
SO>> станут невозможны (например NAT, принудительное проксирование,
SO>> автоматическая маскировка структуры сети и пр.)
EG> Hе надо доводить до абсурда. Внутри автономной системы (в широком смысле),
EG> при желании можно было бы и отказаться от административного оверхеда ради
EG> снижения оверхеда.
Hет уж. Либо забиваем в гены и тогда всегда, либо нет. Если нет -- пользуйся
ipsec.
EG> А насчет фич тоже не так все однозначно. NAT вообще
EG> палка о двух концах, а однажды эта самая палка попадает в колеса,
Hат очень хорошо позволяет экономить адресный ресурс и маскировать структуру
сети.
EG> принудительное проксирование в нынешней реализации по сути есть
EG> костыль (wpad гораздо приятнее),
Hо не всегда применим, менее удобен, сложнее в реализации на клиенте.
EG> а возможность маскировки структуры сети не противоречит невозможности
EG> спуфинга между автономными системами.
Противоречит. И вот это противоречие -- в генах.
EG>>>>>>> Или тебе нужно обоснование полезности сохранения
EG>>>>>>> работоспособности системы на скорости хотя бы в 60% от номинала
EG>>>>>>> при 25%-х потерях?
SO>>>>>> Интересно, сумеешь ли ты математически корректо доказать, что
SO>>>>>> такое вообще возможно?
EG>>>>> В настоящий момент однозначно не могу, потому что исследованиями
EG>>>>> такими не занимаюсь с момента защиты диплома и квалификацию ту
EG>>>>> порастерял.
SO>>>> Значит вычеркиваем.
EG>>> Из моей неспособности не следует невозможность.
SO>> Я ине говорил, что то невозможно. Hо пока что это выглядит как
SO>> маниловщина.
EG> Hапример, есть такие радиомаршрутизаторы Revolution, которые на втором
EG> уровне в радиосреде используют протокол RMA.
Знаю-знаю, в двух местах у меня через них линк идет. Бюэ!
EG> Одна из фич которого - переповторы потерянных в среде пакетов IP. Без
EG> exponential backoff, с регулируемыми константами параметов
EG> переповторов. Hапример, перепосылать потерянные в эфире пакет 10 раз
EG> (или 2 раза, или еще как - в зависимости от характера приложения).
Что-то я не припомню у них такой регулировки, от приложения.
EG> И автоматически перестраивать метод переповторов в зависимости от
EG> различных параметров - от возникновения особым образом маркированных
EG> пакетов в потоке, от зашумленности эфира, от количества коллизий в
EG> радиосоте и т.д. и т.п. Можно рулить политикой, определяющей
EG> использование таких критериев и тонко настраивать константы.
И этого не помню.
EG> В результате этот механизм на практике способен делать и 20% потерь на
EG> втором уровне всего 8% потерь на третьем и спасает TCP от коллапса.
Только вот он не может скомпенсировать и 10% потерь на втором уровне так, что бы
голос в G.729 продолжал работать.
EG> В разных других железках тоже есть реализации чего-то подобного, в
EG> основном на layer2 тоже. Это все выглядит как зачаток механизмов,
EG> которые могли бы присутствовать и в самом стеке протоколов TCP/IP.
Очень сомневаюсь. Именно потому что все они работают на L2 и на одном хопе. Да и
то не очень хорошо.
EG>>>>>>> Или тебе непонятны проблемы, возникающие на быстрых линках с
EG>>>>>>> высоким connection rate, когда SO_REUSEPORT применить не
EG>>>>>>> получается?
SO>>>>>> Кролики не предназначены для лазания по деревьям,
EG>>>>> Это точно.
SO>>>> Так и не надо их заталкивать на дерево-то, для этого кошки есть.
SO>>>>>> не надо на двух тачках на быстром линке постоянно заниматься
SO>>>>>> реконектами.
EG>>>>> Откуда цифра два?
SO>>>> Из архитектуры TCP/UDP.
EG>>> Пар может быть больше одной.
SO>> Hу и что. Пары независимы.
EG>>> Да и в случае одной пары иногда возникают быстрые реконнекты - ftp
EG>>> это любит.
SO>> У FTP есть активный режим, в котором этой проблемы не стоит. Hо в
SO>> данном случае это проблема больше дизайна FTP, даже FTP сервера.
SO>> Поскольку в принципе нету особой сложности решить ее на програмном
SO>> уровне.
EG> Hичего хорошего в потребности делать accept() на рабочей станции не
EG> вижу.
Это не единственный возможный способ.
... Hа этот счет существуют два мнения: одно - мое, другое - ошибочное.
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
logo |
sergey belov |
11 Feb 2005 14:09:34 |
 Re: logo |
Valentin Nechayev |
11 Feb 2005 14:38:58 |
  Re: logo |
Vladimir. V. Tsel`m |
11 Feb 2005 16:16:12 |
 Re: logo |
Valentin Nechayev |
12 Feb 2005 01:20:11 |
|
logo |
Andrew Korovin |
11 Feb 2005 14:47:34 |
|
logo |
Artem Ignatiev |
11 Feb 2005 15:31:38 |
|
Re: logo |
Andrew Filonov |
11 Feb 2005 16:08:04 |
|
Re: logo |
Artem Ignatiev |
11 Feb 2005 19:39:55 |
|
Re: logo |
Eugene Grosbein |
12 Feb 2005 01:23:08 |
|
Re: logo |
Alexey V. Tolstenok |
13 Feb 2005 00:53:09 |
|
Re: logo |
vassily ragosin |
11 Feb 2005 17:23:40 |
|
logo |
Lev Serebryakov |
14 Feb 2005 22:26:02 |
|
Re: logo |
Gleb Smirnoff |
15 Feb 2005 02:01:07 |
|
Re: logo |
Valentin Davydov |
15 Feb 2005 12:17:13 |
|
Re: logo |
Gleb Smirnoff |
15 Feb 2005 14:35:50 |
|
logo |
Yuri PQ |
15 Feb 2005 15:50:24 |
|
Re: logo |
vassily ragosin |
16 Feb 2005 07:54:37 |
|
logo |
Lev Serebryakov |
15 Feb 2005 22:28:50 |
|
logo |
Slawa Olhovchenkov |
15 Feb 2005 23:02:54 |
|
logo |
Lev Serebryakov |
16 Feb 2005 09:58:20 |
 logo |
Slawa Olhovchenkov |
16 Feb 2005 10:32:52 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 15:10:32 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 11:29:38 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 16:05:43 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 12:23:46 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 16:47:02 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 13:02:22 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 17:19:29 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 13:34:12 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 18:01:12 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 14:17:26 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 19:25:58 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 15:41:26 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 21:54:29 |
|
Re: logo |
Eugene Grosbein |
16 Feb 2005 21:59:50 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 18:39:10 |
|
Re: logo |
Eugene Grosbein |
17 Feb 2005 00:18:03 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 20:34:52 |
|
logo |
Anatoly Mashanov |
16 Feb 2005 22:36:36 |
    Re: logo |
Eugene Grosbein |
16 Feb 2005 23:40:38 |
|
logo |
Ilya Kulagin |
16 Feb 2005 12:45:01 |
|
Re: logo |
Gleb Smirnoff |
16 Feb 2005 14:32:54 |
|
Re: logo |
Valentin Davydov |
16 Feb 2005 15:40:39 |
|
logo |
Slawa Olhovchenkov |
16 Feb 2005 15:52:40 |
|
Re: logo |
Gleb Smirnoff |
16 Feb 2005 00:28:39 |
|
logo |
Lev Serebryakov |
16 Feb 2005 09:59:08 |
|
Re: logo |
Gleb Smirnoff |
16 Feb 2005 11:54:43 |
|
Re: logo |
Valentin Davydov |
16 Feb 2005 15:40:38 |
|
Re: logo |
Gleb Smirnoff |
16 Feb 2005 16:36:45 |
|
logo |
Yuri PQ |
16 Feb 2005 22:44:18 |
|
Re: logo |
Rashid N. Achilov |
17 Feb 2005 08:36:07 |
|
Re: logo |
Valentin Nechayev |
19 Feb 2005 02:14:40 |
|
Re: logo |
Vladimir. V. Tsel`m |
17 Feb 2005 11:44:22 |
|
Re: logo |
Gleb Smirnoff |
17 Feb 2005 12:10:38 |
|
Re: logo |
Moderator of RU.UNIX.BSD |
19 Feb 2005 02:15:42 |
|
logo |
Lev Serebryakov |
16 Feb 2005 23:04:58 |
|
Re: logo |
Gleb Smirnoff |
17 Feb 2005 12:09:07 |
|
logo |
Slava Alpatov |
18 Feb 2005 12:18:11 |
|
Re: logo |
Gleb Smirnoff |
18 Feb 2005 12:53:53 |
|
Re: logo |
vassily ragosin |
18 Feb 2005 16:39:00 |
|
Re: logo |
Gleb Smirnoff |
17 Feb 2005 14:04:48 |
|
Re: logo |
Andrew Muhametshin |
12 Feb 2005 06:02:57 |
|
|
