Comments 10
"Но в криптошлюзах с архитектурой как на рис. 3 весь защищаемый трафик между внутренними и внешними сегментами сети продвигается через шифратор (Ш), где потоки данных, исходящие во внешний сегмент сети, зашифровываются, а входящие – расшифровываются. Поэтому трафик по механизму очередей нужно обрабатывать не только на выходе маршрутизатора, но и на выходе из шифратора (блока криптографической обработки) с учетом его пропускной способности как отдельного виртуального интерфейса."
Так и не понял зачем?!?!? Те самые "мировые лидеры-разработчики телеком-оборудования" да и мировые лидеры в стандартописании в целом не идиоты и за ними довольно пристально следит целая армия крпто и телеком-спецов чтобы все было безопасно. В частности если передавать что-то криптозакрытое, то не стоит давать потенциальному слушателю возможность понять что часть трафика более приоритетна а если уж надо прям приоритетно и не приоритетно что-то передавать между точками ничего не мешает организовать ДВА SA (Security Association) и одному из них добавлять TOS/DSCP после шифрования.
Кстати, а эти отечественные изделия между собой хоть как-то совместимы?
Кстати, а эти отечественные изделия между собой хоть как-то совместимы?
Если вы имеете ввиду построение ГОСТ-туннеля между железками разных вендоров - то нет:(
Может и есть какие-то совместимые вендоры, но, пока, не сталкивался
Я последний раз с такими "изделиями" лет 18-19 назад имел дело. Видимо, и к огромному сожалению, они так и не вышли из зоны "велосипедоизобретения" и как были устройствами для ИБД так и остались. Только административного давления теперь в разы больше, и возможностей получить степень за счет "решения" проблем выдуманных для "более современным криптошлюзам из-за более сложной архитектуры"..... Жалко и обидно.....
Добрый день!
Если в блоке шифратора не обрабатывать трафик по приоритетам, то менее приоритетный может не дойти до адресата (или доходить с очень большой задержкой). И если делать два разных SA, то нагрузка на шифратор все равно останется, а поля TOS/DSCP все равно добавляются.
Так может "мировые лидеры-разработчики телеком-оборудования" делают все проще и правильнее: обрабатывают трафик по приоритетам ДО шифратора, выдают шифратору набор пакетов В ПРАВИЛЬНОЙ последовательности согласно приоритетам и ограничениям очередей а шифратор тупо берет пакеты, шифрует их и отсылает получателям? В чем вундервафельность то? В усложнении блока шифратора путем внедрения в него еще одного механизма приоритизации? Зачем? В переносе информации о шифрованных пакетах ЧЕРЕЗ ШИФРАТОР в "блок наружней маршрутизации" (что бы это не значило)? А тов. полковник о таких фривольностях знает?
Да и в современном мире говорить о каких-то титанических нагрузках на шифраторы как-то стыдно чтоли -- какая нибудь малинка за полкопейки может line rate или даже больше....
у наших решений есть две проблемы - 1) отсутствие стандартизации вместо с велосипедостроением - в итоге cisco с juniper прекрасно строят ipsec, а вот S-Terra с VipNet - нет, хотя ГОСТ, который впрочем описывает только алгоритм... 2) все наши решения - это linux на x86, ну или в последнее время на arm. Ну то есть шифрование на процессоре общего назначения, который при этом еще и роутит и линукс на себе запущает... никаких гарантий времени шифрования/дешифрования, чтоб можно было выстроить простую и логичную обработку трафика
Проблемы велосипедостроения известны более 20 лет как
По поводу шифрования — ГОСТ симметричный и использует s-boxы насколько я помню. Это значит что шифрует и дешифрует он за известное и одинаковое время. Да, без аппаратного ускорения это медленнее, но все равно время детерминированное. На днях попробую крутануть openssl в режиме benchmark с гост на arm - даже интересно стало
Что до линукса, но сетевая подсистема у него настолько вылизана уже, что даже самое дешевое железо выдает line rate не напрягаясь и сильно не напрягая платформу.
поэтому и кажется что все подобные «решения» несуществующих проблем чистой воды ИБД. Показав бурную деятельность какой нибудь сверхзакрытой дипломной комиссии вероятно можно получить плюшек например….
Гост это набор шифров. Алгоритмы шифрования у всех вендоров +- разные, поэтому и нет совместисти. У випнетов и континентов проприетарные(хотя континенты в 4.2 должны пересесть на ipsec), у стерры ipsec только с ikev1, у крипто-про тоже ipsec, но только с ikev2. Кстати говоря крипто-про ngate имеют совместиость с криптонитом и упомянутым здесь фактором-тс(дионисом). Вот такой расклад.
Не имею глубокой компетенции работе с сетевым стеком, но имею большую практику работы с шифраторами на больших инфраструктурах.
Мне видится задача, с годным для приложений эффектом, сложно решаемой. Особенно с учётом, выполнения её на x86 архитектуре с потоком в несколько гигабит различного трафика. Во-первых, приоритет сервиса и время ожидания ответа в рамках сессии, понятия несовместимые. Пока ждём завершения важного ВКС в 4К, сессии наших приложений будут дропаться. Не годится. Во-вторых, джиттер будет скакать. В-третьих, будет ли соблюдаться очерёдность пакетов? Бывает, что при простом прохождении без нагрузки Out Of Sequence frame зашкаливал так, что на уровне TCP буферы не спасали и реально мешал работе приложений.
Наша беда не в реализации производителями СКЗИ алгоритмов шифрования, а в том, что мы не можем "прожигать" ASIC с "ГОСТом", как "буржуины" AESом. Потому для шифрование приходиться применять, по сути ПК, и о работе на скорости линии говорить не приходится.
Повышаем качество обслуживания трафика в российских криптошлюзах: нюансы внедрения QoS