Definição e conceito de SDN

O Software-Defined Networking (SDN) é o conceito de uma rede com uma arquitetura que separa o controle de tráfego da rede (planos de controle) do hardware encarregado por transmitir os pacotes (plano de dados). Uma SDN diverge das redes tradicionais, que combinam os planos de controle e dados no mesmo dispositivo de hardware. A Open Networking Foundation é a organização dedicada a promover o uso da SDN e padronização do protocoloOpenFlow.

A decisão de como os pacotes irão transitar pela rede é feita a partir do plano de controle. Em uma rede SDN, o plano de controle tem o papel orquestrar os pacotes de maneira centralizada e controlada por software, fornecendo uma visão global da rede. A entidade controladora é denominada como Network Operating System (NOS). O controlador central toma a decisão de encaminhar os pacotes conforme o fluxo da rede. Já o plano de dados diz respeito aos dispositivos responsáveis apenas pelo encaminhamento de dados. Em uma rede SDN, dispositivos como roteadores e switches tem apenas o papel de seguir instruções fornecidas pelos controladores centrais.

O objetivo principal das redes definidas por software é tornar mais fácil e flexível o gerenciamento das redes. Ao abstrair o controle de pacotes do hardware, os administradores de rede têm a capacidade de gerenciar e configurar as redes de uma maneira semelhante ao gerenciamento de memória e outros recursos computacionais Nune et al. (2014). A possibilidade de programar a rede facilita a implementação de alterações e a otimização do desempenho da rede sem a necessidade de reconfigurar manualmente os componentes de hardware.

Evolução das redes tradicionais para SDN

Uma rede é composta por uma série de dispositivos de rede como roteadores e switches. Na arquitetura clássica, a decisão de como os dados serão encaminhados em uma rede é decidido localmente em cada um dos dispositivos dessa rede. Com a democratização do uso da internet, a arquitetura de rede tradicional enfrenta dificuldade no gerenciamento e escalabilidade das redes modernas. Um exemplo disso é que se a rede precisa de um redirecionamento de tráfego ou aplicação de novas políticas, os administradores devem reconfigurar manualmente os dispositivos, o que consome tempo e esforço; sinalizando, assim, a rigidez da rede. Diante desse cenário, a criação da SDN tinha como objetivo desenvolver redes de computadores programáveis, permitindo a diminuição das barreiras até então encontradas. Antes das SDNs surgiram outras tentativas, discutiremos a seguir algumas delas.

1. Active Networking: Nos anos 1990, Active Networking sugeriu a ideia de uma infraestrutura de rede programável para serviços personalizados, tendo duas abordagens: Switches programáveis pelo usuário e cápsulas, que eram fragmentos de programas incorporados em mensagens de usuário.
2. DCAN: O projeto Devolved Control of ATM Networks (DCAN), tinha como ideia central separar as funções de controle e gerenciamento dos dispositivos de rede e delegá-las a entidades externas especializada. Além disso, DCAN propunha um protocolo minimalista entre o gerenciador e a rede.
3. 4D Project: Em 2004, o projeto 4D sugeriu um plano de decisão com uma visão globalizada da rede, apoiado por planos de "disseminação" e "descoberta" para controlar o plano de "dados", responsável pelo encaminhamento de tráfego. Ou seja, o projeto propôs a ideia de uma clara separação entre o plano de controle e o plano de dados.
4. NETCONF: Em 2006, o NETCONF foi proposto pelo IETF Network Configuration Working Group, que é um protocolo de gerenciamento para modificar a configuração de dispositivos físicos de uma rede. A ideia por trás desse protocolo era permitir que os dispositivos expusessem uma API pela qual seria possível recuperar ou enviar dados de configuração.
5. Ethane: Em 2006 foi proposto pelo projeto SANE/ Ethane uma arquitetura de redes corporativas que poderiam usar um controlador centralizado para gerenciar políticas e segurança na rede.

Plano de Controle

O controlador SDN é o principal componente da arquitetura e funciona como uma espécie de cérebro da rede. É nele em que as funções do plano de controle são centralizadas, além de ser o responsável por tomar as decisões de roteamento e por garantir que políticas sejam aplicadas em toda a rede. Por ter uma visão global, ele pode mais facilmente otimizar o uso de recursos na rede e se adaptar a mudanças de demanda. Além disso, o controlador também expõe APIs que permitem que desenvolvedores criem aplicações e serviços que podem alterar os comportamentos da rede, abstraindo assim o gerenciamento para software. O controlador obtém essa visão da rede através da comunicação com os outros componentes, que é feita pelo uso de interfaces southbound. Essas interfaces, ou protocolos, são responsáveis por traduzir as instruções de alto nível para as configurações específicas de cada dispositivo. Tais protocolos permitem que o controlador envie comandos que modificam a tabela de encaminhamento de roteadores, colete estatísticas e informações sobre a condição do dispositivo, e detecte a mudança na topologia da rede. E como o plano de controle pode ser integrado com software, é possível criar todo tipo de automatização baseado em interfaces southbound, como o controle dinâmico de tráfego com o uso de balanceadores de carga. Existem alguns modelos de controlador SDN no mercado, cada um com suas particularidades, para citar alguns:

• OpenDaylight: Uma plataforma open-source modular que dá suporte para múltiplos protocolos southbound e é amplamente utilizada para SDN e Funções de Virtualização de Rede (NFV).
• ONON (Open Network Operating System): Projetado par alta disponibilidade e escalabilidade, adequado para rede de larga escala.
• Ryu: Um framework baseado em componentes, escrito em Python, ideal para desenvolvedor e pesquisadores
• Cisco Application Policy Infrastructure Controller (APIC): Um controlador comercial da Cisco, que integra os hardware e softwares proprietários da empresa.

Plano de Dados

Diferentemente de redes tradicionais em que os dispositivos de rede individualmente tomam decisões sobre roteamento, na arquitetura SDN, o papel de switches e roteadores é simplificado para simples encaminhadores de pacote. Eles ficam responsáveis por lidar com os pacotes de dados com base nas regras de fluxo determinadas pelo controlador da SDN. Várias vantagens decorrem dessa característica da arquitetura SDN. Em primeiro lugar, com a redução de complexidade, os dispositivos de rede podem ser construídos com hardware mais simples, reduzindo seus custos. Além disso, dispositivos mais simples reduzem a heterogeneidade da rede, o que torna o gerenciamento mais simples e reduz a probabilidade de erros de configuração. Outro ponto também é a flexibilidade, já que agora roteadores e switches podem ser atualizados ou reprogramados on-the-fly, através do controlador.

Interfaces de Comunicação

Como já mencionado, a comunicação entre o controlador e os dispositivos de baixo nível da rede é facilitada pela interface southbound, com destaque para a mais famosa delas, o protocolo OpenFlow. Já as interfaces northbound dizem respeito à conexão do controlador com as aplicações e serviços de rede. Essas interface são tipicamente API's, que permitem a alteração do comportamento da rede através de software. RESTful API's são as mais comuns, e provêm uma maneira padronizada de interação com o controlador. Dentre as possibilidade de uma aplicação, podemos citar enviar requisições de rede, definir políticas de controle de tráfego, implementar medidas de segurança e monitorar a performance da rede.

OpenFlow

O OpenFlow é um protocolo que permite a comunicação direta entre o plano de controle (controladores) e o plano de dados (dispositivos de rede, como switches e roteadores) em uma rede SDN. A imagem 1 ilustra sua arquitetura. Nela, os controladores se comunicam com um switch OpenFlow através do protocolo. Esses switchs contém uma ou mais tabelas de fluxo (flow tables) e uma camada de abstração.

1. Tabelas de Fluxo (Flow Table): É composta de diversas entradas de fluxo (flow entries) que descrevem como os pacotes pertencentes a um determinado fluxo serão processados e encaminhados. Um fluxo é essencialmente um conjunto de pacotes que compartilham características comuns (como endereço IP de origem/destino, porta de entrada, entre outras). Cada entrada de fluxo tem três componentes principais:
   1. Campos de Correspondência (Match Fields/Rule): Essas são regras usadas para identificar e comparar os pacotes que chegam ao switch. Os campos de correspondência incluem informações dos cabeçalhos dos pacotes (como endereços IP, portas TCP/UDP), a porta de entrada do pacote, e outros metadados.
   2. Contadores (Counters/Statistics): Esses contadores são usados para coletar estatísticas sobre o fluxo, como o número de pacotes recebidos, a quantidade de bytes transmitidos e a duração do fluxo. Eles ajudam a monitorar o comportamento do fluxo e podem ser usados para análises de desempenho ou políticas de rede.
   3. Conjunto de Instruções (Instructions/Actions): São ações a serem executadas quando um pacote corresponder a uma regra de fluxo. As instruções podem incluir encaminhamento do pacote para uma porta específica, descartá-lo, modificar algum campo do cabeçalho, ou até mesmo enviar o pacote para o controlador. As instruções definem como o switch deve lidar com os pacotes correspondentes.
2. Camada de Abstração (OpenFlow Client): Garante a comunicação segura com o controlador SDN via o protocolo OpenFlow. Essa comunicação permite que o controlador configure, modifique ou remova as regras de fluxo do switch.

Quando um pacote chega ao switch OpenFlow, o switch extrai os campos do cabeçalho, como IP de origem e destino, e verifica suas tabelas de fluxo para encontrar uma correspondência. Se o pacote corresponder a uma entrada da tabela, o switch aplica a ação associada, como encaminhar o pacote para uma porta específica. Por exemplo, um pacote com IP de origem "192.168.1.10" e destino "192.168.1.20" pode ser encaminhado para a porta 2, de acordo com a regra definida. Se não houver correspondência (table-miss), o switch executa uma ação predefinida, como descartar o pacote, encaminhá-lo ao controlador ou buscar outra tabela. Caso o pacote seja enviado ao controlador, ele pode instruir o switch a adicionar uma nova regra para pacotes futuros, garantindo uma tomada de decisão mais dinâmica e eficiente.

ForCES

O ForCES (Forwarding and Control Element Separation) é uma arquitetura e um protocolo que separa logicamente o plano de controle do plano de encaminhamento dentro de um dispositivo de rede. Diferentemente de arquiteturas como o OpenFlow, onde o plano de controle é completamente separado dos dispositivos de rede, o ForCES mantém o plano de controle e o plano de dados próximos fisicamente, como no mesmo dispositivo ou local. A arquitetura do ForCES tem dois compoentes principais:

1. Elemento de Controle (Control Element - CE):O CE é responsável pelas funções de controle e sinalização. Ele instrui o Elemento de Encaminhamento (FE) sobre como processar os pacotes, utilizando o protocolo ForCES.
2. Elemento de Encaminhamento (Forwarding Element - FE): O FE lida diretamente com o hardware de encaminhamento e é responsável pelo tratamento de pacotes, de acordo com as instruções do CE. Ele segue um modelo mestre-escravo, onde o CE é o mestre que comanda o FE.
3. Blocos de Função Lógica (LFB): Um componente importante do ForCES é o Bloco de Função Lógica, localizados nos FEs. Esse bloco permite ao CE controlar a configuração dos FEs e definir como os pacotes serão processados.

Comparação

É possível dizer que o ForCES não segue o modelo de SDN de forma rígida, ao contrário do OpenFlow, que faz uma separação total entre o plano de controle (gerenciado por controladores centralizados) e o plano de dados. Entretanto, a combinação de diferentes Blocos de Função Lógica pode oferecer a mesma flexibilidade, para fins de gerenciamento, administração e desenvolvimento da rede, que o OpenFlow oferece Tsou et al. (2012).. Ainda assim, devido à ampla adoção e suporte da comunidade, a arquitetura de SDN baseada em OpenFlow é vista como o padrão, tanto no desenvolvimento acadêmico quanto na implementação prática Nunes et al. (2014).

HPE Network Protector

O HPE Network Protector SDN Application é uma aplicação de segurança voltada para Redes Definidas por Software (SDN), desenvolvida pela Hewlett Packard Enterprise (HPE). Uma das funcionalidades da ferramenta é a Filtragem de DNS, em que a aplicação bloqueia consultas DNS que estejam relacionadas a domínios maliciosos, como sites de phishing, malware ou botnets. Isso evita que dispositivos na rede acessem destinos comprometidos. Hewlett Packard Enterprise (2014) Os itens abaixo, aliado à Figura 3, sugerem um passo a passo de como isso é feito utilizando SDNs:

1. Quando uma solicitação de resolução de DNS é feita (por exemplo, quando um usuário tenta acessar um site), o dispositivo de rede (como um switch OpenFlow) intercepta essa solicitação.
2. O switch OpenFlow encaminha os pacotes DNS ao controlador SDN, que tem uma visão global da rede e pode tomar decisões com base no conteúdo desses pacotes.
3. O controlador SDN recebe o pacote DNS e repassa essa informação para a aplicação de segurança, como o HPE Network Protector, através de uma API na interface norte.
4. A aplicação consulta um Banco de Dados para verificar o domínio
5. Se a aplicação determinar que o domínio deve ser bloqueado, ela envia uma instrução ao controlador SDN para tomar uma ação específica.
6. O controlador pode intruir o switch OpenFlow a: descartar a solicitação DNS antes que ela chegue ao servidor DNS ou redirecionar a solicitação DNS para uma página de advertência ou um servidor DNS interno.

Essa prática garante que novas ameaças e domínios maliciosos possam ser bloqueados dinamicamente, com atualizações enviadas diretamente aos switches OpenFlow. Antes da adoção de SDN, o processo de configuração de filtros e regras de segurança, como o filtro de DNS, precisava ser feito manualmente, roteador a roteador ou switch a switch. Isso envolvia configurações individuais em cada dispositivo de rede, o que tornava a administração de grandes redes complexa, demorada e propensa a erros.

SDN e 5G

Uma das principais aplicações do 5G é o fatiamento da rede (Network Slicing). Essa solução admite que uma infraestrutura física única possa ser dividida em várias redes virtuais, cada uma configurada para atender diferentes tipos de serviços (como baixa latência, alta largura de banda, ou suporte massivo a dispositivos IoT). A partir da separação dos planos de controle e dados, as SDNs permitem que as políticas de rede para cada fatia sejam configuradas e aplicadas de forma centralizada e programável. Babbar et al. (2022)

SDNs em redes IoT

Em redes IoT, em que dispositivos são heterogêneos e frequentemente distribuídos, a SDN permite que administradores configurem, monitorem e otimizem fluxos de dados de maneira eficiente, garantindo qualidade de serviço (QoS) e segurança em tempo real. Por exemplo, a SDN pode identificar dispositivos IoT vulneráveis e isolar automaticamente o tráfego suspeito, reduzindo riscos de ciberataques. Além disso, a SDN simplifica o gerenciamento da rede ao automatizar a alocação de recursos e priorizar dispositivos ou aplicações críticas, o que é essencial em ambientes de IoT com requisitos variáveis de conectividade e processamento. Thorat et al. (2020)

SDNs e Redes em Nuvem

Em ambientes de nuvem, onde os recursos como servidores, armazenamento e processamento, precisam ser provisionados de maneira rápida e eficiente, as SDNs oferecem a capacidade de automatizar a criação, configuração e gerenciamento de redes. Isso reduz o tempo e o esforço necessário para provisionar redes virtuais e ajustar a infraestrutura em resposta a demandas de cargas de trabalho em tempo real. Lin and Lin (2014)

Centralização

O ponto único de falha é uma preocupação primária. A dependência de um controlador central significa que, se este controlador falhar devido a falhas de hardware, bugs de software ou ataques, toda a rede pode ser afetada. Isso pode resultar em interrupções de serviço significativas, perda de conectividade e impactos negativos nas operações comerciais. O controlador SDN é um alvo valioso para invasores, pois comprometer o controlador pode permitir o controle total da rede. Ataques de Negação de Serviço (DoS) podem sobrecarregar o controlador com tráfego excessivo, esgotando seus recursos e impedindo-o de gerenciar efetivamente a rede. A exploração de vulnerabilidades no software do controlador pode conceder acesso não autorizado, permitindo que invasores modifiquem políticas, interceptem dados confidenciais ou interrompam operações críticas.

Para mitigar o risco de um ponto único de falha, é essencial implementar redundância e alta disponibilidade. Isso pode ser alcançado através da implantação de múltiplos controladores. A redundância garante que, se um controlador falhar, outro possa assumir imediatamente suas funções, mantendo a continuidade do serviço sem interrupções perceptíveis. A segurança robusta do controlador é igualmente crucial. Isso envolve a aplicação de práticas de segurança rigorosas, como atualizações regulares de software, aplicação de patches de segurança e desativação de serviços ou portas desnecessárias para minimizar a superfície de ataque. Implementar autenticação forte e controles de acesso ajuda a garantir que apenas usuários autorizados possam interagir com o controlador.

Comunicação Controlador-Plano de Dados

As ameaças à interface southbound incluem ataques Man-in-the-Middle (MitM), onde um invasor intercepta e possivelmente altera a comunicação entre o controlador e os dispositivos. Sem criptografia e autenticação adequadas, as mensagens podem ser interceptadas, permitindo que invasores manipulem o comportamento da rede ou acessem informações sensíveis. O acesso não autorizado às tabelas de fluxo nos dispositivos de rede também é uma preocupação. Se um invasor conseguir comprometer um switch ou roteador, ele pode visualizar ou modificar as regras de encaminhamento, desviando tráfego, espionando comunicações ou causando interrupções nos serviços. As vulnerabilidades dos protocolos, como limitações no OpenFlow, podem ser exploradas. Versões anteriores do OpenFlow não contavam com mecanismos robustos de autenticação e criptografia, tornando-as suscetíveis a interceptação e manipulação por atacantes.

A implementação de comunicação segura entre o controlador e os dispositivos é fundamental. O uso de protocolos seguros, como TLS/SSL, criptografa os dados em trânsito, impedindo que sejam interceptados ou alterados. Além disso, a aplicação de autenticação mútua garante que tanto o controlador quanto os dispositivos confirmem a identidade um do outro antes de trocar informações. Para proteger as tabelas de fluxo, é importante restringir o acesso aos dispositivos de rede. Isso pode ser feito através de controles de acesso baseados em função e segmentação de rede, garantindo que apenas entidades autorizadas possam interagir com os dispositivos. Manter os dispositivos atualizados com as últimas correções de segurança e firmware também ajuda a reduzir as vulnerabilidades exploráveis. Em relação às vulnerabilidades dos protocolos, é crucial adotar versões atualizadas que incluam melhorias de segurança. Participar de iniciativas da comunidade e seguir as melhores práticas recomendadas pelos órgãos de padronização, como a Open Networking Foundation (ONF), pode ajudar a manter a segurança dos protocolos utilizados.

Segurança no Plano de Aplicação

Os exploits da API northbound podem ocorrer quando aplicações de terceiros não seguem práticas de segurança adequadas. Vulnerabilidades nessas aplicações podem ser exploradas para comprometer o controlador, modificar políticas de rede ou acessar dados confidenciais. Além disso, aplicações maliciosas ou comprometidas representam uma ameaça significativa. Aplicações com intenções maliciosas podem ser instaladas inadvertidamente ou podem ser comprometidas após a instalação. Isso pode levar a alterações não autorizadas na rede, espionagem de tráfego ou interrupção de serviços. Para mitigar esses riscos, é essencial implementar controles de acesso rigorosos para a interface northbound. Isso inclui autenticação forte para garantir que apenas aplicações autorizadas possam interagir com o controlador. O uso de certificados digitais e chaves criptográficas pode fortalecer ainda mais o processo de autenticação.