|
|
ru.unix.bsd- RU.UNIX.BSD ------------------------------------------------------------------ From : Slawa Olhovchenkov 2:5030/500 16 Feb 2005 15:41:26 To : Eugene Grosbein Subject : logo -------------------------------------------------------------------------------- 16 Feb 05, Eugene Grosbein writes to Slawa Olhovchenkov: EG>>>>> Тебе нужно обоснование необходимости невозможности спуфинга SO>>>> Да. Я считаю, что возможность спуфинга -- полезная фича, повышающая SO>>>> безопасность сети. Опровержение будет? EG>>> Хм. Что спуфинг может угрожать безопасности - это, думаю, очевидно. SO>> Hет, это не очевидно. Обосновывай. EG> Далеко не всегда можно доверять source IP/source port в пакете. EG> Особенно когда пакет пришел из чужой системы. Это очень плохо - EG> порождает бардак в децентрализованной сети IP-сети. Обоснуй чем именно это плохо в общем случае. Я пока не вижу как недоверие src IP порождает бардак в IP сети. EG>>> Что он может помогать безопасности - надо обосновывать тебе. SO>> Это позволяет с IPS/IDS/файрволов разрывать нежелательные соединения. EG> Их можно блокировать не хуже и без спуфинга, Расскажи как. Очень желательно что бы при этом у тебя произошло освобождение ресурсов. EG> не говоря уже о том что соединения бывают stateless (UDP в первую EG> очередь). С ними такой фокус может и не пройти. EG>>>>> по дефолту? SO>>>> По какому дефолту? Это дефолт в каком месте? EG>>> В архитектуре сети надо бы иметь, в генах. SO>> Hет, это будут плохие гены. Это будет плохая сеть. EG> Чем? Потому что сеть получится очень сложной, не децентрализированной, с большими накладными расходами. Различные приятные фичи в такой сети станут невозможны (например NAT, принудительное проксирование, автоматическая маскировка структуры сети и пр.) EG>>>>> Или тебе нужно обоснование полезности сохранения работоспособности EG>>>>> системы на скорости хотя бы в 60% от номинала при 25%-х потерях? SO>>>> Интересно, сумеешь ли ты математически корректо доказать, что такое SO>>>> вообще возможно? EG>>> В настоящий момент однозначно не могу, потому что исследованиями EG>>> такими не занимаюсь с момента защиты диплома и квалификацию ту EG>>> порастерял. SO>> Значит вычеркиваем. EG> Из моей неспособности не следует невозможность. Я ине говорил, что то невозможно. Hо пока что это выглядит как маниловщина. Поэтому вычеркиваем. В качестве аналогии утверждение "jpeg плохой алгоритм сжатия, потому что не позволяет сжимать картинку в 100 раз без потери качества". EG>>>>> Или тебе непонятны проблемы, возникающие на быстрых линках с EG>>>>> высоким connection rate, когда SO_REUSEPORT применить не EG>>>>> получается? SO>>>> Кролики не предназначены для лазания по деревьям, EG>>> Это точно. SO>> Так и не надо их заталкивать на дерево-то, для этого кошки есть. SO>>>> не надо на двух тачках на быстром линке постоянно заниматься SO>>>> реконектами. EG>>> Откуда цифра два? SO>> Из архитектуры TCP/UDP. EG> Пар может быть больше одной. Hу и что. Пары независимы. EG> Да и в случае одной пары иногда возникают быстрые реконнекты - ftp это EG> любит. У FTP есть активный режим, в котором этой проблемы не стоит. Hо в данном случае это проблема больше дизайна FTP, даже FTP сервера. Поскольку в принципе нету особой сложности решить ее на програмном уровне. ... Люди делятся на умных и тех, кто много говорит. --- GoldED+/BSD 1.1.5 * Origin: (2:5030/500) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix.bsd/222142133401.html, оценка из 5, голосов 10
|