OpenFlow

UFRJ - EEL879 - Redes de Computadores 2 - 2019.2

Alunos:
Felipe Assis
Lidiana Souza dos Anjos

Introdução


Motivações


Tradicionalmente, as redes são controladas por algoritmos especiais implementados em hardwares dedicados, proprietários, fechados e de alto custo. Mudanças no funcionamento avançado do equipamento, especializações ou inserções de novas funcionalidades são dependentes do fabricante e de seu ciclo de desenvolvimento e testes. Tais problemas não só trazem prejuízos a quem use os aparelhos de maneira prática e comercial, mas também no que se refere a pesquisa. Tanto o alto custo como a falta de flexibilidade dificultam ambientes experimentais, com diferentes topologias, funcionalidades e protocolos, atrasando assim a evolução da tecnologia.

A solução encontrada para combater os prejuízos vindos de hardware proprietários se deu em implementar as regras de manipulação dos dados por meio de software programável, ao invés de um que vem incorporado no hardware. Com isso, é possível resolver tanto o problema da falta de flexibilidade, agora tendo os equipamentos completamente programáveis, tanto quanto o problema do preço, pois poderia ser usado um equipamento universal e genérico, sem a dependência dos grandes fabricantes. Tal tecnologia é chamada de Redes Definidas por Software (SDN).

Redes Definidas por Software


Nos últimos 20 anos, a internet não evoluiu muito em sua arquitetura, apesar de seu grande crescimento. Com o seu crescimento comercial, seus componentes se tornaram caixas pretas, equipamentos os quais são fechados e não há muito controle interno, que não por parte dos fabricantes. Essa estagnação arquitetural é o que é conhecido como o engessamento da internet.

As Redes Definidas por Software (ou Software-Defined Networks - SDN) vem como uma contraposição a esse modelo. Se trata de uma arquitetura dinâmica, gerenciável, rentável e adaptável, que nos entrega a flexibilidade desejada, assim como o baixo custo. A principal característica de tal arquitetura se dá no desacoplamento dos chamados plano de dados e plano de controle, mais detalhados no tópico seguinte.

As SDN apresentam diversas características vantajosas. Por exemplo, temos padrões abertos que independem de fornecedores, o que flexibiliza o controle e a comunicação da rede. Temos inteligência e velocidade, pois o fluxo de dados pode ser ajustado dinamicamente pela rede, atendendo as demandas e mudanças, assim como uma boa distribuição de carga na rede. E é claro, como já evidenciado, é diretamente programável e tem um controle logicamente centralizado, permitindo aos administradores uma visão e manipulação geral da rede com certa facilidade.

Atualmente existem diversos padrões de protocolos existem para o SDN, porém um se destaca com sua popularidade, o OpenFlow. Como o nome já diz, é aberto e orientado a fluxos, e abstrai usa abstrações de portas e comutadores para controlar o fluxo. Nele também temos controladores universais SDN e comutadores universais SDN.


Plano de Controle e Plano de Dados


Como dito anteriormente, uma das principais características das Redes Definidas por Software é o desacoplamento do Plano de Controle e do Plano de dados. Em redes tradicionais, esses planos se encontram juntos, ou seja, não há uma clara diferenciação dos dois. Os próprios elementos da rede são os responsáveis por fazer o controle de fluxos assim como fazer o próprio encaminhamento do fluxo. Com o SDN, esses planos podem ser separados em dois elementos distintos.

O plano de dados consiste simplesmente nos elementos responsáveis por fazer o encaminhamento na rede. Ou seja, o papel deste plano é majoritariamente encaminhar dados, mas também apresenta as responsabilidades de monitoramento de informações e o ajuntamento de estatísticas.

O plano de controle, como o próprio nome já indica, é responsável por gerenciar o que é feito no plano de dados, visto que ele não possui nenhum tipo de inteligência por si só. Os controladores têm uma visão geral da rede e podem usar informações adquiridas pelo plano de dados para definir como serão as operações feitas na rede. Os controladores podem ser múltiplos, evitando assim problemas por falha no componente central do sistema e se comunicam com os elementos do plano de dados por meio de interfaces padrão.

Arquitetura


Elementos da topologia


Para além da separação do gerenciamento do Plano de Controle e do Plano de Dados, há elementos importantes para a composição do OpenFlow. São esses o controlador, a tabela de fluxos e o canal seguro.

some text

Figura 1 - Topogia do OpenFlow



  • Controlador

    • O controlador é o componente responsável pelas regras e ações que gerenciam o encaminhamento de pacotes. Ele se comunica com os comutadores OpenFlow e é configurado de acordo com a aplicação, garantindo flexibilidade em diversificadas aplicações. O controlador abstrai o que seria a configuração, a priori, do aparato físico e o torna reutilizável, visto que cada aplicação definirá como o gerenciamento se dará e não ficará limitada a configuração prévia de um equipamento de rede.

    Ainda, como o controlador é programável, o desenvolvimento de melhorias associadas ao Plano de Controle e ao Plano de Dados não dependem estritamente de novos dispositivos de redes que atendam aos critérios desejados.

    O controlador pode ser desde um servidor até uma única máquina. É através de uma conexão TCP (Transmission Control Protocol) que o controlador se comunica com os comutadores.

  • Tabela de Fluxos

    • É na Tabela de Fluxos que ocorre a caracterização dos fluxos recebidos em um roteador OpenFlow. Nas entradas da tabela há 3 campos: cabeçalho, contadores e ações.

    No cabeçalho que está definido o tipo de fluxo que chega e nele há campos que são usados na descrição de um fluxo. Esses campos guardam informações como a porta de entrada do fluxo e IP de origem. Dados associados a quantidade de dados e pacotes transmitidos e o tempo de transmissão são determinados pelo contador. Ainda, a depender do fluxo, diferentes ações podem ser tomadas e quem define-as é o controlador. Essas ações são definidas no cabeçalho da Tabela de Fluxos.

  • Canal Seguro

    • É por meio do Canal Seguro que o Controlador distribui as regras de encaminhamento. A segurança na comunicação entre o controlador e o roteador pode ser primordial a depender da aplicação. O Canal Seguro visa proteger essa comunicação por meio de protocolos. O mais recomendando é o Secure Socket Layer (SSL).

    Controlador OpenFlow: Out-of-Band e in-Band


    Há duas maneiras do Controlador OpenFlow se comunicar com os comutadores. No primeiro, Out-of-Band, o controlador tem um caminho para se comunicar com os comutadores OpenFlow que não é o caminho usado pelo OpenFlow para a comunicação entre os comutadores. No segundo, in-Band, o caminho usado na comunicação entre os comutadores é igualmente usado pelo controlador para se comunicar com esses.

    some text

    Figura 2 - À esquerda da imagem está o controle OpenFlow Out-of-Band, à direita está o controle OpenFlow in-Band.



    Para viabilizar controle OpenFlow Out-of-Band é necessário estabelecer VLANs ou interfaces físicas que não estão submetidas ao protocolo OpenFlow.

    Protocolo

    Aplicações



  • Virtualização de redes


  • Balanceamento de Carga

    • Disponibilidade e escalabilidade

    Segurança e vulnerabilidades


    A centralização do gerenciamento no Controlador e separação em Plano de Controle e Plano de Dados trazem novos desafios quanto a segurança na utilização do OpenFlow. Além de ataques diretos ao Controlador, podem ocorrer ataques aos roteadores/comutadores OpenFlow e aos canais de comunicação. Os desafios e vulnerabilidades dependem do componente do OpenFlow em análise.

  • No roteador

    • De forma geral, o atacante pode escanear a rede para conseguir informações sobre ela e elaborar como pretende atacar. Conhecendo a topologia da rede, as configurações da rede e obtendo informações da comunicação na rede é possível lançar ataques de grande impacto. Um deles é o ataque Denial-of-Service (DoS) que consiste em tornar indisponível os recursos da rede para quem tenta acessa-la. Pode ser realizado mandando muitas requisições de acesso, desta forma a tabela de fluxos não conseguirá armazenar todos os dados de fluxo que chega. Há também um tipo de ataque DoS que atinge o Plano de Dados fazendo falsas requisição de fluxo, com isso são calculadas regras desnecessariamente e os recursos são consumidos. Sem esses recursos, requisições reais não são atendidas.

  • No controlador





  • Na comunicação entre Plano de Dados e Plano de Controle


    • Conclusão

    Perguntas

    Bibliografia

    Open Networking Foundation. OpenFlow Switch Specification. Disponível em: < https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf>. Acesso em: 26/08/2019.

    CHIRGWIN, Richard. OpenFlow protocol has a switch authentication vulnerability. Disponível em:
    SCOTT-HAYWARD, Sandra. Trailing the Snail: SDN Controller Security Evolution. Disponível em: . Acesso em: 26/08/2019.

    Bellagamba, Elisa, James Kempf, and Pontus Skoldstrom. 2011. “Link Failure Detection and Traffic Redirection in an Openflow Network.”

    Hu, F., Hao, Q., & Bao, K. . A Survey on Software-Defined Network and OpenFlow: From Concept to Implementation. IEEE Communications Surveys and Tutorials, 16(4), 2181–2206.

    WU, Huijun. HUANG, Dijiang. Mobile Cloud Computing. Disponível em: . Acesso em: 26/08/2019.

    CULVER, Timothy. BLACK, Chuck. GORANSSON, Paul. Software Defined Networks: A Comprehensive Approach. Disponível em: . Acesso em: 26/08/2019.

    Bianco, A., Birke, R. R. M., Giraudo, L., & Palacin, M. . OpenFlow Switching: Data Plane Performance. In 2010 IEEE International Conference on Communications (pp. 1–5).

    Benton, K., Camp, L. J., & Small, C. . OpenFlow vulnerability assessment. In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking (pp. 151–152).

    Fernandez, M. P. . Comparing OpenFlow Controller Paradigms Scalability: Reactive and Proactive. In 2013 IEEE 27th International Conference on Advanced Information Networking and Applications (AINA) (pp. 1009–1016).

    Klöti, R., Kotronis, V., & Smith, P. (2013). OpenFlow: A security analysis. In 2013 21st IEEE International Conference on Network Protocols (ICNP) (pp. 1–6).

    Wendong, W., Xiangyang, G., Xirong, Q., Long, F., Hongyun, L., & Tong, Z. OpenFlow network system and method for enhancing programmable capability.

    Muntaner, G. R. de T. . Evaluation of OpenFlow Controllers.

    Suzuki, K., Sonoda, K., Tomizawa, N., Yakuwa, Y., Uchida, T., Higuchi, Y., … Shimonishi, H. . A Survey on OpenFlow Technologies. IEICE Transactions on Communications, 97(2), 375–386.

    Kandoi, R., & Antikainen, M. . Denial-of-service attacks in OpenFlow SDN networks. In 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM) (pp. 1322–1326).

    Ichino, K. . OpenFlow COMMUNICATION SYSTEM AND OpenFlow COMMUNICATION METHOD.

    Rothenberg , Christian Esteve . Nascimento, Marcelo Ribeiro . Salvador, Marcos Rogério. Magalhães , Maurício Ferreira. OpenFlow e redes definidas por software: um novo paradigma de controle e inovação em redes de pacotes

    Braun, Wolfgang. Menth, Michael. Software-Defined Networking Using OpenFlow: Protocols,Applications and Architectural Design Choices

    Centeno, Paulo Vieira. Uma análise de segurança de Redes Definidas por Software sobre protocolo OpenFlow

    Kobayashi, Masayoshi. Seetharaman, Srini. Parulkar, Guru. Appenzeller, Guido. Little, Joseph. Reijendam, Johanvan. Weissmann, Paul. McKeown, Nick. Maturing of OpenFlow and Software-defined Networking through deployments

    Neto, Francisco José Badaró Valente. OpenFlow-based Routing

    Lia, Wenjuan. Meng, Weizhi. Kwok, Lam For. A survey on OpenFlow-based Software Defined Networks: Security challenges and countermeasures

    Tiwari, Varun. Parekh, Rushit. Patel, Vishal.A Survey on Vulnerabilities of Openflow Network and its Impact on SDN/Openflow Controller

    Lara, Adrian. Kolasani, Anisha. Ramamurthy, Byrav. Network Innovation using OpenFlow: A Survey