Топ Open Source SDN проектов для того, чтобы быть в теме

Интерес и движения вокруг OpenFlow и Программно-конфигурируемых сетей или Software Defined Networking (SDN) безусловно ускоряется. Я думаю люди так взволнованы темой вокруг SDN потому, что, в то время пока мы видели множество инноваций вокруг сетей – в беспроводном пространстве, дата центрах и всех приложениях – было очень мало инноваций в области сетевых технологий – маршрутизаторы и коммутаторы – в течение последнего десятилетия никак не изменились. Перспектива полного изменения архитектуры сети, путем отделения плоскости управления от плоскости данных, открывает много новых возможностей.

С SDN, организации не будут скованы тем знанием, как у них построена сеть. Они будут свободны, будут строить ее динамически, «текучую» инфраструктуру, которая может поддерживать колебания спроса на сетевые ресурсы, более короткие циклы реализации и совершенно новые бизнес-модели. Но как я уже говорила, мы только в начале пути. В то время, как те из нас, кто наблюдает за этой областью были впечатлены быстрыми темпами инноваций SDN на сегодняшний день, трудно предсказать, что произойдет в следующий момент. Но это не мешает нам пробовать!
Я потратила несколько недель на некоторых пионеров в области SDN, чтобы посмотреть что происходит интересного в области SDN в последнее время. Среди них эксперты, Крис Смолл, Сетевой исследователь в Университете Индианы, Фил Поррас, Программный директор в Computer Science Lab SRI, и Дэн Талайоко, член технического отдела в Big Switch Networks. Далее приведены выдержки из бесед с ними:

Какие лучшие проекты, по вашему мнению, сейчас около OpenFlow и SDN наиболее правильные?

Дэн Талайоко: Трудно выделить всего лишь пару игроков на данном рынке, чтобы поговорить о них. Есть три очень разных части экосистемы в SDN. Первая, это коммутаторы, предоставляющие инфраструктуру для перемещения пакетов. Затем есть контроллеры. Это уровень централизованного управляющего ПО, перенаправляющие поведение инфраструктуры (наиболее часто через протокол OpenFlow) и предоставляющие платформу для третьего уровня, который есть полностью SDN приложения. Это программы, которые запускаются на контроллере. Они дают визуализацию топологии сети и уведомляют о событиях в сети.
Есть четыре Open Source SDN проектов на которые я бы указал. Я больше знаком с двумя нижними слоями (коммутаторы и контроллеры), так что я начну с них
Floodlight это open source контроллер на Java. Он появился меньше года назад, я верю, что он будет быстро принят сообществом OpenFlow. В настоящее время, он имеет наиболее дискуссионный форум, по сравнению с другими контроллерами, вместе взятыми.
Open vSwitch (OvS) это многослойный виртуальный коммутатор выпускающийся под лицензией open source apache 2.0. Его фокус в основном на виртуальный коммутатор, хотя он может быть портирован на различные платформы одинаково хорошо. Некоторые из создателей OpenFlow создали OvS.

OFTest был разработан в Сэнфорде. Это фреймворк и набор тестов реализованный на Python, которые дают людям способ проверить функциональность коммутаторов OpenFlow. Было даже простое ПО для коммутации, написанное на Python для проверки OpenFlow версии 1.1, которое распространялось с OFTest.
Indigo это проект, также начатый в Стэнфорде, предоставляющий реализацию OpenFlow на аппаратных коммутаторах. Он запускается на нескольких аппаратных платформах и использовался в основной архитектуре для OpenFlow коммутаторов нацеленных на аппаратную переадресацию.
Крис Смолл: В то время, пока работа, которая проведена над Контроллерами очень важна, я думаю самое интересное, это смотреть на это в реальных приложениях. Это поможет нам чувствовать, что это действительно важно. Первое, что я думаю интересно это то, что сделано в Университете Индианы. Мы имеем OpenFlow балансировщик нагрузки в FlowScale. Мы развернули его в нашей сети кампуса, как front-end к нашей системе обнаружения вторжений, и пропускаем весь трафик через него (48 портов по 10Г/с коммутатор). Он делает все, маршрутизация, отказоустойчивость и т.д. мы бы хотели сделать балансировщик, но дешевле, чем готовое решение.
Другой ключевой проект, на который я бы взглянул это CPqD (http://www.cpqd.com/). Он произошел из Бразильской Bell Лаборатории, и они также работают над RouteFlow (https://sites.google.com/site/routeflow/) для запуска виртуальной топологии с Open Source ПО, а затем реплицируют виртуальную топологию внутрь OpenFlow коммутаторов. Это то как вы можете взять топовый стоечный коммутатор и конвертировать его в очень способный маршрутизатор и интегрировать большое количество различных возможностей необходимых для исследований, кампуса и развертывания в среде предприятия.
Фил Поррас: я искал в этой области относительной безопасности и думаю, что есть несколько основных стратегий, которые исследователи изучают, чтобы узнать, как лучше развивать безопасные технологии, которые могут динамически отвечать на угрозы в сети или изменения в OpenFlow стеке. Идея состоит в том, чтобы следить за возможными угрозами, а затем иметь безопасные технологии взаимодействующие с контроллерами безопасности для применения новых, динамических политик.
Существует FlowVisor (https://openflow.stanford.edu/display/DOCS/Flowvisor) во главе с Али Аль-Шабиби из Стэнфорда и Робом Шервом (который раньше был в Стэнфорде, а теперь в Big Switch), который работает для обеспечения безопасности сетевых операций путем сегментирования или слайсинга, управления сетью в независимом виртуальном окружении. Каждый сетевой слайс (или домен) управляется автономным приложением, спроектирован как управляющий приложениями, которые управляют другими сетевыми слайами. Совсем недавно, они начали рассматривать слой гипервизора, который также может быть использован для интеграции на уровне предприятия или дата-центра в масштабе политик.
Мы (в SRI) работаем с FortNOX (http://www.openflowsec.org/FortNOX_Sigcomm_HotSDN_2022.pdf), который предоставляет расширенную безопасность OpenFlow контроллера, который становится безопасным посредником сервисов – он может применять сильные политики в сетевом слайсе, для обеспечения согласованности с фиксированными политиками. Эта способность инициирует иерархическую модель доверия, которая включает сетевые операции, безопасность приложений, и традиционных приложений OpenFlow. Контроллер примиряет все новые потоки правил с существующими наборами правил и, если существует конфликт, контроллер, используя цифровые сигнатуры аутентифицирует источник правила, разрешая ему на основе инициатора имеющего наибольший приоритет.
CloudPolice (http://www.hpl.hp.com/people/lucian_popa/cloudpolice_hotnets.pdf) во главе с Ионом Стойком из U.C. Беркли во взаимодействии с людьми из Принстона и Intel Labs Беркли, пытаются использовать OpenFlow как способ обеспечить очень многофункциональный контроль политики безопасности для виртуальной ОС в хосте. Здесь, ответственность за безопасность сети отделена от сетевой инфраструктуры и помещается внутрь гипервизора хоста принимающего потоки от пользовательских политик на одну виртуальную машину в стеке.
Университет Мэриленда, совместно с Georgia Tech, Национальным научным университетом и технологиями (Пакистан) работают над использованием OpenFlow в качестве доступного механизма безопасности логики для более эффективного распространения безопасности приложений к последнему хопу сетевой инфраструктры. Предпосылкой является интернет провайдер или профессиональные группы безопасности, отвечающих за управление сетевой безопасности, способные развернуть OpenFlow приложения внутри домашних маршрутизаторов, которые являются, рассадником сетевых вирусов, для предоставления индивидуальной защиты и лучшей передачи суммарных данных до уровня провайдера (или других точек), чтобы производить как более точные обнаружения угрозы, а также точно нацеленные ответы на угрозы.
Почему эти проекты так важны?
Дэн Талайоко: Потому, что контроллеры это основной центр между коммутаторами и SDN приложениями, это действительно важная часть системы, разрабатываемая в настоящее время. Это то, почему я думаю, что Floodlight так важен. Было интересно увидеть растущий общественный вклад в базовую функциональность и интерфейсы, которые были изначально определены. Я думаю, полностью веб-интерфейс был добавлен недавно.
Это важно хотя бы потому, что мы видим изменения в новых проектах и быстро растущую экосистему. Например, OFTest начал привлекать к себе больше внимания снова, отчасти потому, что мы добавили в него много тестов, а отчасти потому, что широкая группа тестирования ONF разработала формальные спецификации тестов.
OpenFlow на аппаратном обеспечении также интересен для меня, потому что я думаю он становится способным контролировать и управлять перенаправление инфраструктуры через SDN, которая будет важна в обозримом будущем и возможно надолго впоследствии. Именно это и есть причина почему я продолжаю активно участвовать в проекте Indigo.
Крис Смолл: FlowScale является той точкой, в которой подтверждается вся гибкость OpenFlow и его потенциал во внедрении данной инновации. Если вы имеет приложения, которые вы хотите развернуть, вы не должны ожидать поставщика, который это реализует, вам не придется ждать, чтобы получить оборудование, которое способно, вы можете взять существующее аппаратное обеспечение и немного программного обеспечения и реализовать его очень легко. Например, мы работаем с другими исследователями, которые интересуются новыми многоадресными алгоритмами или реализацией PGP, вместо того, чтобы ждать основных вендоров для того, чтобы решить, что будет разумно вложиться в их оборудование, мы можем очень недорого реализовать его, попробовать его, в скорости передачи по линиям, а затем развернуть более широко.
Это немного похоже на материал, который ONRC, в сотрудничестве между Стэнфордом и Беркли, разрабатывал на протяжении последних лет. Они делают много убеждающих доказательств концепции приложений с OpenFlow и продолжают проталкивать новые идеи в свет. Они проводят новые исследования и строят реализации, которые могут быть использованы в будущем для новых продуктов. Эти приложения появятся в дальнейшем, но это даст вам идеи о том, что может быть расширено и будет реализовано в новых продуктах. Они работают над большим количеством исследовательских проектов – таких как, балансировщик нагрузки как сетевой примитив (который мы включили в FlowScale) и их недавний анализ пространства заголовков, которые могут проверять корректность сети для обеспечения политики сети, соответствующей его реальному физическому развертыванию.
Routeflow важен потому, что он доказывает, что вы можете удалить всю сложность аппаратного обеспечения и получить те же возможности; он оставляет все особенности и сложность в ПК, а не в коммутаторы. Мы работаем с ними на демонстрации его на конференции Internet2, где мы собираемся показать routeflow работающий на аппаратных коммутаторах в качестве виртуализованных сервисов развертываемых в сети Internet2. Это первый раз, когда мы увидели нечто подобное на национальной магистрали.
Фил Поррас: проекты по безопасности акцентируются на двух направлениях: одна сфокусирована на использовании SDN для большей гибкости интеграции динамических сетевых политик безопасности, а другая для лучшей диагностики и смягчению последствий. Одна ветвь исследует как и где динамическая сетевая безопасность может быть реализована в сетевом стеке OppenFlow: контроллер, сетевой гипервизор (flow visor) или даже гипервизор ОС. Другая ветвь пытается продемонстрировать безопасность приложения, либо записать в виде приложений OpenFlow для более эффективного распределения или настройки для взаимодействия с контроллером OpenFlow для проведения смягчения динамических угроз.
Какие существуют препятствия?
Дэн Талайоко: быстрое изменение в спецификации протокола OpenFlow бросает нам вызов, который мы все встречаем лицом к лицу. Это симптом желания управлять изменениями в этих проектах так быстро, как только это возможно. OvS не обновлялось с версии 1.0, хотя имеет большое количество собственных расширений.
Вторая задача, которая стоит перед нами, это те кто работает с Open source, особенно на уровне протокола, является то, что часто бывают коллизии с требованиями генерации кода, который может быть поможет в понимании, по сравнению с кодом, который может стать основой для разработки качественного ПО для производственных сред.
Проект Indigo пострадал от двух других вещей: первое это большие ожидания, которые могли предоставить полную управляемость реализованную в коммутаторах, которая обычно включает в себя крупную компанию для реализации и поддержки, и второе, потому что до сих пор значимый компонент выпускается только в виде бинарников. Я думаю, что как только сообщество продвинется вперед, мы увидим дополнительную работу, которая сделает это намного проще в использовании всех инструментов и продуктов в множестве различных окружений.
Крис Смолл: Сейчас OpenFlow проекты на аппаратных коммутаторах до сих пор незрелые. Это важно признать, потому что это другая технология, с различными ограничениями и существует несколько вещей, которые просто невозможны сейчас. Но если вам не нужен полный список возможностей, тогда идеальным будет использование некоторых из этих приложений. Глядя на данную область, становится очевидным, что все движется довольно быстро, с новыми вендорами, спецификациями, поддержкой оборудования и т.д. каждый день мы будем догонять и мы сможем реализовать множество вещей, которые сейчас невозможны.
Фил Поррас: вся концепция SDN противоречит нашим традиционным представлениям о безопасности работы сети. Фундаментальное состояние безопасности, в любой момент времени вы знаете, что происходит. Это необходимость применения четко определенной политики безопасности экземпляров специально для топологии целевой сети, которая может быть проверена, протестирована на соответствие.
Программно-конфигурируемые сети, с другой стороны, охватывают момент, что вы постоянно можете переопределять политику безопасности. Они применяют понятия, что политики могут быть пересчитаны или выведены как раз вовремя, за счет динамической вставки или удаления правил, в соответствии с тем, как изменяются сетевые потоки или топология. Весь фокус заключается в этих двух, казалось бы, расходящихся представлениях.
В дополнение, OpenFlow приложения могут конкурировать, противоречить, переопределить один другому, включать уязвимости, или даже быть написанными противниками. Возможность многократных пользовательских и сторонных OpenFlow приложений запущенных на сетевом контроллере вводит устройство в уникальную политику – что произойдет когда различные приложения динамически управляют политиками совершенно по разному? Как контроллер гарантирует, что они не будут конфликтовать друг с другом? Как это исследовать и решить какие политики ограничить?
Я думаю, что лучшее, что мы имеем это разговоры о том, как мы представляем безопасность OpenFlow и расширения новых приложений безопасности в настоящее время. Безопасность имела репутацию, быть последней прибывшей на вечеринку. Я думаю это случай, где мы могли бы помочь сделать большое положительное влияние на технологию, которая может, в свою очередь, оказать большое положительное влияние на безопасность.
Что ожидает в будущем OpenSource и SDN?
Дэн Талайоко: я думаю, мы увидим новые архитектуры и эталонные реализации, что позволит ускорить развертывание SDN в ближайшем будущем. Люди часто пренебрежительны к одноразовым проектам, но реальность такова, что мы сталкиваемся с множеством проблем, каждую из которых необходимо решать несколько иным путем, в то время как все они могут рассмотрены в соответствии с подходами SDN. Эти проекты уже вышли из закрытой коробки, так как много людей лучше понимают SDN. Я слышал, несколько человек, которые начинают говорить о затянутых проектах, которые в конце концов убьют приложения SDN.
Крис Смолл: я верю, что будет адаптация SDN как нишевой технологии, где больше и больше приложений будут реализованы до тех пор, пока это не достигнет критической массы, и это имеет больше смысла с точки зрения перспектив времени и стоимости, нет необходимости управлять двумя различными сетями – традиционной и основанной на SDN. Когда это произойдет, я думаю, мы увидим переход на SDN.
Фил Поррас: OpenFlow имеет некоторый очень интересный потенциал управлять новыми инновациями в интеллектуальной и динамической защите сетевой безопасности в будущем. В долгосрочной перспективе, я думаю, что OpenFlow может доказать то, что он один из наиболее впечатляющих технологий для управления различными новыми решениями в области сетевой безопасности. Я могу представить себе будущее, в котором безопасная сеть OpenFlow:
• Включает в себя логику на уровне управления или инфраструктуры служащей связующим звеном между всем входящим потоком правил против потока сетевой политики безопасности организации таким образом, что не может быть обойдена и быть завершенной.
• Которая позволяет полный динамизм в приложениях OpenFlow для получения оптимальных решений маршрутизации потока, в то же время остающаяся свободно в неведении текущей политики безопасности и не зависящая от сохранности сетевой безопасности.
• Позволяющей практикам по информационной безопасности разрабатывать мощные приложения безопасности с поддержкой OpenFlow, которые могут динамически перепрограммировать маршрутизацию потоков, для смягчения угроз сети, удаления или помещения в карантин активных, которые нарушают безопасность или для которых не выполняется целостность, и реагирующее на отказы всей сетью
Когда мы сможем достичь всех трех из них, мы сможем предоставить некоторые веские причины, почему OpenFlow имеет явное преимущество по сравнению с существующими сетями, способствуя при этом укреплению доверия мы должны иметь ввиду все другие преимущества SDN. Я верю, что мы можем примирить статическую и динамическую политики и создавать все новые сервисы, которые будут более интеллектуальными и эффективными контрмерами, чтобы лучше защищать наши сети.

Оригинал

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля отмечены *

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post Navigation