um mecanismo para isolamento seguro de redes virtuais ... · xen virtual machines. in the plane...

Um Mecanismo para Isolamento Seguro de Redes VirtuaisUsando a Abordagem Hıbrida Xen e OpenFlow⇤

Diogo Menezes Ferrazani Mattos, Lyno Henrique Goncalves Ferraz eOtto Carlos Muniz Bandeira Duarte

1Grupo de Teleinformatica e AutomacaoUniversidade Federal do Rio de Janeiro (UFRJ)

Rio de Janeiro – RJ – Brasil

{menezes,lyno,otto}@gta.ufrj.br

Resumo. Redes virtuais seguras devem prover a privacidade e evitar a negacaode servico. Este artigo propoe um mecanismo de isolamento seguro baseadono paradigma de separacao do plano de controle do de dados e na tecnica deencaminhamento de pacotes XenFlow, uma abordagem hıbrida usando Xen eOpenFlow. O mecanismo proposto emprega uma aplicacao de controle de re-des OpenFlow para marcar com etiquetas cada rede formada por maquinasvirtuais Xen. No paradigma de separacao de planos o encaminhamento dospacotes de cada rede virtual e realizado diretamente no plano de dados e omecanismo proposto garante o isolamento do trafego com reserva de recursospara cada rede virtual. O prototipo desenvolvido e avaliado perante dois mo-delos de atacante: o primeiro tenta exaurir os recursos das redes virtuais e osegundo tenta bisbilhotar a comunicacao de redes virtuais. Os resultados dosexperimentos revelam a eficacia do mecanismo proposto em isolar o trafego ateem situacoes adversas como redes virtuais com o mesmo endereco IP ou compacotes em difusao.

Abstract. Secure virtual networks must provide privacy and avoid denial of ser-vice attacks. In this paper, we propose a mechanism which securely isolates vir-tual networks based on the paradigm of data and control plane separation. Theproposal is deployed over XenFlow, a hybrid network virtualization tool thatuses both Xen and OpenFlow. The proposed mechanism associates an Open-Flow control application with a labeling scheme for each virtual network ofXen virtual machines. In the plane separation paradigm, packets of each virtualnetwork are forwarded directly in data plane, and the proposal ensures trafficisolation with resource reservation for each virtual network. The experimentsevaluate two attackers’ models: one that tries to exhaust the resources of vir-tual networks and other that attempts to eavesdrop on communications fromother virtual networks. The results show that the proposal completely blocksthe action of both attackers’ model. Results reveal the effectiveness for trafficisolation, even on adverse situations, where virtual networks share the same IPaddress space or broadcast packets.

1. IntroducaoA virtualizacao de rede e uma tecnologia essencial para prover um ambiente de

experimentacao para a Internet do Futuro, assim como tambem e uma efetiva propostapluralista para a Internet, na qual diversas redes executam sobre um mesmo substrato

⇤Este trabalho foi realizado com recursos da FINEP, FUNTTEL, CNPq, CAPES, FAPERJ e UOL.

XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais — SBSeg 2013

128 c�2013 SBC — Soc. Bras. de Computação

fısico [Mattos et al. 2011, Feamster et al. 2007]. A virtualizacao separa a funcao desem-penhada por um elemento de rede de sua realizacao fısica. Assim, permite experimentardiversos protocolos e servicos inovadores no nucleo da rede, pois cada rede virtual deveser isolada das demais. Entretanto, as iniciativas atuais de virtualizacao de redes aindaenfrentam desafios para garantir desempenho, requisitos de qualidade de servico exigidospelas aplicacoes que executam nas redes virtuais e isolamento seguro do trafego entre asredes virtuais [Mattos and Duarte 2012, Barabash et al. 2011].

O isolamento de redes virtuais e composto por duas vertentes importantes: o isola-mento de recursos [Mattos and Duarte 2012, Fernandes and Duarte 2010] e o isolamentoda comunicacao entre nos de uma rede virtual [Barabash et al. 2011]. O isolamento nocompartilhamento de recursos garante que um elemento virtual nao interfira no desempe-nho dos demais elementos virtuais. O isolamento de recursos e importante porque evita anegacao de servicos entre redes virtuais, ja que uma rede virtual nao consegue exaurir osrecursos de outras. O isolamento da comunicacao das redes virtuais, por sua vez, garanteque a comunicacao de uma rede virtual so alcance os nos que de fato pertencam a essa redevirtual, mesmo que duas redes virtuais distintas usem o mesmo espaco de enderecamentoIP. O isolamento da comunicacao e essencial em meios de comunicacao em difusao, comoo Ethernet [Perlman et al. 2011]. Um pacote em difusao (broadcast), ou com multiplasdestinacoes (multicast), deve ser acessıvel somente pelos nos que pertencam a uma mesmarede virtual, enquanto que os nos de outras redes virtuais nao devem receber tais paco-tes [Huang 2005, Barabash et al. 2011]. O isolamento da comunicacao das redes virtuaise importante tambem por seguranca, uma vez que impede uma rede virtual de bisbilhotar(eavesdropping) os pacotes de outras redes virtuais. Outro ponto importante do isola-mento da comunicacao e liberdade de uso de espacos de enderecamento e limitacao do es-copo de enderecos somente para o alcance dos nos de uma rede virtual. Assim, garantir oisolamento da comunicacao e isolamento de recursos, mantendo o desempenho das redesvirtuais e um desafio da virtualizacao de redes [Egi et al. 2007, Fernandes et al. 2010].

Este artigo propoe um mecanismo de isolamento da comunicacao e tambem deisolamento de recursos entre redes virtuais. A proposta se baseia no paradigma daseparacao de planos, no qual o encaminhamento e o controle da rede sao desacopla-dos [Pisa et al. 2010, Wang et al. 2008]. A ideia central da proposta e que os pacotesde uma rede virtual sejam encaminhados diretamente no plano de dados, sejam acessıveissomente pelos nos dessa rede e nao interfiram no funcionamento das demais. Para tanto,o mecanismo de isolamento proposto estende o sistema hıbrido de virtualizacao de re-des XenFlow [Mattos et al. 2011, Mattos and Duarte 2012], que combina a ferramenta devirtualizacao de computadores Xen com a interface de programacao de aplicacao (API)para redes OpenFlow. Assim, as principais contribuicoes da proposta sao: i) a garantia deisolamento da comunicacao entre redes virtuais; ii) o mapeamento de funcoes de isola-mento de redes virtuais para primitivas do plano de dados; e iii) a combinacao da solucaode isolamento da comunicacao com a proposta de isolamento de recursos, proposto nosistema QFlow [Mattos and Duarte 2012], garantindo a virtualizacao de redes em um am-biente em que haja garantia da reserva de recursos para redes virtuais e, ao mesmo tempo,garantia de que os pacotes de uma dada rede sejam somente entregues aos nos de destino.

As principais propostas para prover o isolamento de redes virtuais visam so-mente o isolamento de recursos [Mattos and Duarte 2012, Fernandes and Duarte 2010,Fernandes and Duarte 2011] ou visam o o isolamento da comunicacao das redes virtu-ais, baseando-se no encapsulamento dos pacotes das redes virtuais [Barabash et al. 2011,Perlman et al. 2011, Nakagawa et al. 2012, Sridharan et al. 2013]. O mecanismo pro-posto, no entanto, usa o paradigma da separacao de planos para garantir o maximo desem-penho do encaminhamento de pacotes no plano de dados e realiza tanto o isolamento de



recursos quanto o isolamento da comunicacao. O isolamento da comunicacao e alcancadoatraves da marcacao dos pacotes de cada rede virtual com uma etiqueta que indica a qualrede o pacote pertence. O padrao 802.1Q, que define o funcionamento de VLANs (VirtualLocal Area Network), e usado para marcar os pacotes de acordo com as regras que saodefinidas pela aplicacao OpenFlow e traduz as regras do plano de controle para o plano dedados. A proposta deste artigo conjuga a separacao de planos do XenFlow, adicionandoa marcacao de pacotes por VLAN como esquema de isolamento de redes virtuais. Umprototipo da proposta foi implementado e a sua avaliacao revelou que a abordagem pro-posta executa tanto o isolamento da comunicacao quanto o isolamento do uso de recursosentre redes virtuais.

O restante do artigo esta organizado da seguinte forma. A Secao 2 discute ostrabalhos relacionados. A Secao 3 apresenta as principais propostas de virtualizacao deredes no Xen e suas limitacoes. A Secao 4 detalha o mecanismo de isolamento segurode redes virtuais proposto. O modelo de atacante considerado e apresentado na Secao 5,seguido pela avaliacao do mecanismo proposto que e discutida na Secao 6. A Secao 7conclui o artigo.

2. Trabalhos RelacionadosO isolamento da comunicacao das redes virtuais associado a separacao

de planos e a garantia de recursos para cada rede virtual e um desafio paraas propostas de virtualizacao de redes [Mattos and Duarte 2012, Pisa et al. 2010,Fernandes and Duarte 2011, Fernandes et al. 2010]. Uma forma de baixo custo de sealcancar a virtualizacao de redes e usar uma plataforma de virtualizacao de hardwarepara computadores pessoais em que as maquinas virtuais executam funcoes de elementosde rede [Wang et al. 2008, Egi et al. 2007].

Uma abordagem comum de virtualizacao em centros de dados e o uso ferramentasde virtualizacao de servidores, como o Xen, e o agrupamento de maquinas virtuais emuma mesma VLAN isolando o trafego de cada inquilino do centro de dados em uma redevirtual [Bari et al. 2013]. Contudo, outras propostas defendem o uso de mecanismos maiscomplexos para alcancar o isolamento de recursos e de comunicacao na rede de centrosde dados [Mudigonda et al. 2011, Greenberg et al. 2009, Hao et al. 2010].

A proposta NetLord [Mudigonda et al. 2011] introduz um agente em software emservidor fısico de cada servidor fısico que encapsula o quadro de uma maquina virtual emum novo pacote IP cuja semantica dos enderecos das Camadas 2 e 3 e sobrecarregada paraindicar a qual rede virtual os quadros pertencem. Na proposta NetLord, o marcador deVLAN e usado para identificar um dos multiplos caminhos que o pacote pdoe seguir narede do centro de dados. De forma semelhante, a proposta VL2 [Greenberg et al. 2009]encapsula os pacotes IP de uma rede virtual em outro pacote IP. Nesse caso, a semanticados enderecos IP dos pacotes e sobrecarregada. O IP mais externo e usado para multi-plexar a qual rede virtual o pacote pertence. A proposta SEC2 [Hao et al. 2010] dividea rede de centro de dados em domınio de um nucleo e multiplos domınios de borda.Nos domınios de borda, uma rede virtual e identificada com uma etiqueta de VLAN. Acomunicacao entre dois domınios de borda distintos e realizada atraves do domınio denucleo por meio de um elemento de encaminhamento que adiciona um cabecalho extra deCamada 2 nos quadros, entre domınios, para realizar a multiplexacao das redes virtuais.

Distributed Overlay Virtual Ethernet (DOVE) e uma proposta de virtualizacao deredes que prove isolamento [Barabash et al. 2011], permitindo a criacao de redes virtuaisdinamicas, com espacos de enderecamentos isolados sobre uma infraestrutura fısica co-mum. O funcionamento do DOVE baseia-se no encapsulamento de pacotes e, portanto,



na criacao de uma rede de sobrecamada para permitir a separacao entre rede virtual e arede fısica subjacente. O isolamento de redes virtuais e alcancado pelo uso de um identi-ficador de rede que e adicionado ao cabecalho do envelope da rede sobrecamada DOVE.Assim, os pacotes com um dado identificador so sao entregues as maquinas virtuais quecompartilhem o mesmo identificador de rede virtual.

O isolamento na comunicacao tambem pode ser alcancado usando o encapsula-mento VXLAN [Nakagawa et al. 2012]. Para tanto, sao adicionados um cabecalho maisexterno Ethernet, seguido de um cabecalho externo IP, UDP e VXLAN. O cabecalho IPdesigna as extremidades do tunel VXLAN. O cabecalho VXLAN inclui 24 bits para iden-tificar a rede a qual o quadro Ethernet, encapsulado, pertence. No caso de um pacote demultidestinacao ou em difusao, o cabecalho IP mais externo tem como endereco de des-tino um IP multicast e cada rede virtual e representada por um grupo multicast. O padraoNetwork Virtualization Generic Routing Encapsulation (NVGRE) [Sridharan et al. 2013]tambem se serve da tecnica de encapsulamento para prover uma virtualizacao de re-des controlada por software para permitir multiplos inquilinos (multitenancy) em nuvenspublicas ou privadas. Os quadros Ethernet das redes virtuais sao encapsulados em umtunel GRE que conecta duas estacoes. O cabecalho GRE apresenta um campo para amarcacao de a qual inquilino tal quadro pertence. Esse campo e chamado TNI (TenantNetwork Identifier), composto por 24 bits para a identificacao da rede virtual.

O isolamento da comunicacao de redes virtuais pode ser alcancado usando o OpenvSwitch [Pfaff et al. 2009], um comutador de software projetado tanto para ser usado emambientes virtualizados, quanto para transformar um computador pessoal em um comuta-dor programavel. O Open vSwitch e um comutador por software que realiza a comutacaodos pacotes entre maquinas virtuais e a rede fısica. O Open vSwitch realiza o isolamentoda comunicacao de redes virtuais atraves da marcacao de etiquetas de VLAN nos pacotesprovindos das maquinas virtuais. Dessa forma, um pacote so e entregue a maquina virtualse sua interface pertencer a VLAN que esta marcada no pacote. Contudo, o Open vSwitchnao realiza o roteamento entre VLANs com separacao de planos e, tambem, depende deuma logica de marcacao de VLANs definida pelo administrador da rede. O mecanismoproposto, por sua vez, permite a configuracao dinamica da rede com separacao de planos.

As propostas XNetMon [Fernandes and Duarte 2010] e XNet-Man [Fernandes and Duarte 2011] usam o Xen como ferramenta de virtualizacaode redes e executam algoritmos para o controle do uso de recursos por cada rede virtual.Contudo, tais propostas nao garantem o completo isolamento de trafego entre redesvirtuais, pois a separacao do trafego apenas se baseia na classificacao de pacotes deacordo com o endereco IP da rede virtual a que se destinam. Assim, o isolamentose restringe a redes virtuais com espacos de enderecamento disjuntos. O sistema devirtualizacao de redes XenFlow [Mattos et al. 2011] aplica o conceito de separacao deplanos [Pisa et al. 2010], mas nao realiza o isolamento de recursos ou da comunicacaode redes virtuais. Ja a proposta QFlow [Mattos and Duarte 2012] estende o XenFlow eprove somente o isolamento do compartilhamento de recursos atraves do mapeamento derequisitos de Qualidade de Servico em recursos disponıveis no plano de encaminhamentoOpenFlow. No entanto, nem o XenFlow nem o QFlow isolam a comunicacao das redesvirtuais.

Todas as propostas acima apresentadas, para prover o isolamento do espaco deenderecamento e da comunicacao das redes virtuais, realizam o encapsulamento dos pa-cotes das redes virtuais e, assim, criam uma rede sobrecamada que interconecta os nos darede virtual. Assim, essas propostas falham ao se considerar o paradigma da separacaode planos, em que o encaminhamento e realizado no plano de dados, na camada Ether-



net, enquanto que os protocolos de roteamento sao executados no plano de controle, nacamada de rede, e sao responsaveis por gerenciar as rotas do plano de dados. O me-canismo proposto neste artigo isola redes virtuais ainda na camada Ethernet mesmo nocenario de separacao de planos. A proposta insere uma etiqueta de VLAN nos pacotesde cada rede virtual, eliminando a necessidade de criar uma rede sobrecamada. A pro-posta estende o sistema XenFlow [Mattos et al. 2011] e aplica o isolamento de recursosdo sistema QFlow [Mattos and Duarte 2012]. A principal contribuicao do artigo e realizaro isolamento da comunicacao de redes virtuais atraves de primitivas do plano de dados,como a marcacao da VLAN. Vale ressaltar que o mecanismo proposto mantem todo oencaminhamento dos pacotes na camada de enlace, Ethernet, ja que nao ha o encapsu-lamento dos quadros por protocolos de camada de rede, deixando todos os campos dopacote original da rede virtual visıveis para o controlador OpenFlow, enquanto propos-tas como NVGRE ou VXLAN escondem os campos do pacote original em um pacoteencapsulado cuja destinacao sao as extremidades dos tuneis criados.

3. O Encaminhamento de Pacotes em Redes VirtuaisO sistema de virtualizacao Xen permite, por padrao, tres modos principais para

realizar o encaminhamento de pacotes entre as interfaces das diferentes maquinas virtuaise as interfaces da maquina fısica: o modo bridge, o modo router e o modo NAT (NetworkAddress Translation). Esses mecanismos multiplexam (comutam ou roteiam) o trafego desaıda dos pacotes originados pelas diferentes maquinas virtuais e demultiplexam (comu-tam ou roteiam) o trafego de chegada de pacotes de uma (ou diversas) interface de entradacom destino as diferentes maquinas virtuais [Egi et al. 2007, Figueiredo et al. 2013].

O modo bridge permite que as maquinas virtuais se comuniquem como se estives-sem em uma mesma LAN (Local Area Network). Ja o modo router permite a agregacaode rotas para um determinado conjunto de maquinas virtuais que estao sobre uma mesmamaquina fısica, diminuindo os requisitos de memoria sobre os dispositivos de encaminha-mento da infraestrutura fısica [Barabash et al. 2011], ja que as rotas divulgadas na redefısica enderecam grupos de maquinas virtuais, ao inves da divulgacao dos enderecos detodas as maquinas virtuais de forma plana e nao agregada, como ocorre no modo bridge.Contudo, essas arquiteturas de rede nao sao plenamente suficientes para a virtualizacaode redes. Os modos bridge e router falham na arquitetura com separacao dos planos decontrole e de dados. A separacao de planos e essencial para prover desempenho as redesvirtuais [Pisa et al. 2010, Mattos et al. 2011].

Na separacao de planos, o plano de controle e responsavel por calcular as rotas,ja o plano de dados e responsavel por encaminhar os pacotes de acordo com essas rotas.A separacao de planos depende de informacoes da camada de rede e, portanto, o modobridge nao atende. Por outro lado, no modo router, a separacao e viavel [Pisa et al. 2010],pois sao criadas tabelas de roteamento no plano de encaminhamento do Domınio 0 quesao copias das tabelas dos roteadores virtuais. Assim, os pacotes de cada rede virtualsao encaminhados de acordo com a tabela de rotas do roteador virtual correspondenteatraves dos mecanismos nativos do kernel do Linux. No entanto, a separacao de pla-nos usando o modo router apresenta alguns desafios. O principal desafio e o isolamentoda comunicacao das redes virtuais, que se divide em dois problemas: identificar a qualrede virtual o pacote pertence e tratar os pacotes com multiplas destinacoes, por exem-plo, a difusao (broadcast) e a destinacao multipla ou difusao seletiva (multicast). Aidentificacao trivial de qual rede um pacote pertence e atraves de seu endereco IP dedestino. A identificacao trivial falha se duas redes virtuais distintas usarem o mesmoespaco de enderecamento IP. Dessa forma, nao ha isolamento de comunicacao entre asredes virtuais.



O segundo problema consiste no encaminhamento de pacotes com enderecos mul-tidestinatarios ou de difusao (multicast/broadcast), pois neste caso um unico endereco deIP se refere a um grupo de hospedeiros, ou seja, pacote multidestinatario ou de difusaopossuem um endereco especıfico que designa a multidestinacao. A multidestinacao nao euma lista de enderecos individuais, mas sim um endereco de grupo e isto ocasiona perdana semantica hierarquica de qual rede um IP pertence. Assim, os pacotes sao destinadosa enderecos IP padroes e nao e possıvel diferenciar entre uma rede ou outra apenas peloseu endereco IP. A solucao de usar espacos de enderecamentos isolados para identificar asredes virtuais falha, pois o IP multicast nao pertence a faixa de IP destinado as redes virtu-ais e, consequentemente, nao pode ser encaminhado pelas tabelas de rotas do Domınio 0.O problema de encaminhamento do pacote de broadcast e ainda mais complexo, pois hacasos em que o pacote de broadcast nem possui cabecalho IP, como no caso do ARP (Ad-dress Resolution Protocol). Dessa forma, a definicao de qual rede o pacote pertence deveser feita na camada de enlace. Contudo, o modo router nativo trata somente a camada derede. Assim, a virtualizacao de redes introduz alguns desafios cuja solucao depende deacoes que considerem o enderecamento da camada de enlace, no caso Ethernet, e permitao encaminhamento pelo enderecamento da camada de rede, o IP.

Uma possıvel solucao para separar o trafego de uma rede virtual do trafego dasdemais e realizar a multiplexacao e demultiplexacao de pacotes entre interfaces de redevirtuais e fısicas atraves marcacao de pacotes com etiquetas, ou tags, de VLAN, comoprovido pelo Open vSwitch [Pfaff et al. 2009]. O Open vSwitch age como uma ponteEthernet, porem com algumas opcoes especiais, como por exemplo o uso de VLAN, quee o acrescimo de uma informacao para a multiplexacao/demultiplexacao no cabecalhodo pacote. Assim, a ideia basica ao se usar o Open vSwitch e marcar as interfaces derede virtuais com uma etiqueta (tag) comum as interfaces que pertencam a um mesmodomınio de broadcast. Essa etiqueta, com o identificador da VLAN, e aplicada a todosos pacotes que saem da interface de rede virtual marcada com ela. A etiqueta, nessecaso, e usada como um identificador do enlace virtual ou do domınio de broadcast virtualao qual o pacote pertence. Dessa forma, duas redes virtuais podem possuir a mesmafaixa de enderecamento sem que uma interfira na outra, garantido o isolamento do espacode enderecamento e dos pacotes de broadcast. No entanto, como o Open vSwitch agecomo uma ponte Ethernet, as mesmas limitacoes do modo bridge do Xen se aplicam, naopermitindo que seja realizado o paradigma da separacao de planos.

O Open vSwitch oferece o modo OpenFlow de comutacao de fluxos. A definicaode fluxo OpenFlow considera campos das camadas de enlace, de rede e superiores paradefinir as regras de encaminhamento dos pacotes. O Open vSwitch e capaz de realizar oprocessamento de pacotes em diversas camadas seguindo a interface de programacao deaplicacao (API – Application Programming Interface) OpenFlow [McKeown et al. 2008].Logo, uma solucao para fazer a separacao de planos com o isolamento de redes virtuaise usar o Open vSwitch se comportando como um comutador programavel OpenFlowrealizando separacao de planos com isolamento. Essa e a ideia basica da arquitetura deredes do XenFlow, com a proposta de isolamento seguro desse artigo.

4. O Mecanismo PropostoO mecanismo proposto marca os pacotes de cada rede virtual com uma etiqueta

de VLAN para executar o isolamento da comunicacao e de recursos. O desempenho domecanismo e garantido executando as operacoes de marcacao e roteamento diretamenteno plano de dados, de acordo com as informacoes calculadas pelo plano de controle nosroteadores virtuais.



Na maquina virtual, executa o Client que e um aplicativo que verifica se haatualizacao na tabela de rotas e na tabela ARP da maquina virtual e as envia para oServer1 no Domınio 0 da maquina fısica que a hospeda. O Server e um procura-dor, proxy, que recebe as conexoes de todos os clientes, trata as mensagens, as respondee repassa as informacoes de todos os clientes concentradas e resumidas para a aplicacaoque executa sobre o POX 2, um controlador de comutadores OpenFlow que permite o de-senvolvimento de aplicacoes escritas em Python. A aplicacao desenvolvida sobre o POXe a que mantem a estrutura de dados para armazenar as tabelas de rota de cada maquinavirtual e, tambem, faz a traducao das rotas em fluxos OpenFlow. Contudo, como o OpenvSwitch nao e capaz de marcar os pacotes com a etiqueta de VLAN, padrao 802.1Q,ao mesmo tempo em que permite o controle pelo OpenFlow, um elemento importanteda arquitetura proposta e o marcador de VLAN que se insere entre as interfaces de rededas maquinas virtuais e o comutador Open vSwitch que implementa o plano de dadosOpenFlow. Os componentes da arquitetura proposta estao explicitados na Figura 1.

Figura 1. A nova arquitetura XenFlow proposta com o marcador de VLANs, ocomutador Open vSwitch, a aplicacao POX para a construcao das tabelas e oServer para a comunicacao das tabelas de rotas do roteador virtual para oDomınio 0.Toda comunicacao de controle e encriptada e autenticada atraves doprotocolo SSL.

A ideia chave da proposta se baseia no uso do Open vSwitch como um comutadorOpenFlow, para ter ao mesmo tempo informacoes da Camada Ethernet, de VLAN e daCamada IP atraves dos 12 campos da especificacao OpenFlow, e tambem na insercaodo marcador de VLAN entre as interfaces virtuais e o comutador OpenFlow. Assim,o pacote que entra ou sai de uma maquina virtual obrigatoriamente deve ser marcado,ou desmarcado, com a etiqueta da VLAN a qual ele pertence. O marcador de VLANe configurado no momento de criacao das maquinas virtuais com o identificado (ID) darede virtual que a interface de rede virtual pertence. A funcao do marcador de VLAN e

1A comunicacao entre o Client e o Server ocorre atraves de interfaces de redes dedicadas a comunicacaoentre maquinas virtuais e Domınio 0. Todas as comunicacoes de controle sao encriptadas e autenticadasatraves da troca de certificados, usando o protocolo SSL v3.0 (Secure Socket Layer).

2http://www.noxrepo.org/pox/about-pox/.



inserir a etiqueta de VLAN em todo o pacote que saia da maquina virtual em direcao aocomutador por software e de retirar a etiqueta de VLAN de todos os pacotes que saemdo comutador em direcao a maquina virtual. Esse funcionamento torna a marcacao eo encaminhamento por VLAN transparente para as maquinas virtuais. O marcador deVLAN tambem e o responsavel por garantir que os pacotes que nao pertencam a umadada rede virtual cheguem a maquinas virtuais de outras redes, pois o marcador de VLANdescarta os pacotes que chegam ate ele, mas que nao tem a etiqueta de VLAN com oidentificador correto.

A traducao de uma rota em fluxo ocorre da seguinte forma. Ao chegar um pacoteno comutador por software (Open vSwitch) de um Domınio 0, se nao existir um fluxo aoqual o pacote se adeque, o pacote e enviado ao POX, conforme o funcionamento normaldo OpenFlow. No POX, o pacote e processado pela aplicacao e verifica a qual maquinavirtual o pacote se destina de acordo com o seu endereco MAC de destino. Uma vezidentificada a maquina virtual, o endereco IP de destino do pacote e verificado. Se oendereco IP de destino do pacote se adequar a alguma rota daquela maquina virtual, aaplicacao extrai o IP do proximo salto atraves da rota na tabela de rotas da maquina virtualidentificada que melhor se adeque ao endereco do pacote, algoritmo de best match. Aposextrair o IP do proximo salto do pacote na rede, a aplicacao do POX verifica a copia databela ARP da maquina virtual para a qual o pacote se destina e verifica se a maquinavirtual ja conhece o mapeamento do endereco IP no endereco MAC do proximo salto.Conhecendo o endereco MAC, a aplicacao POX define um novo fluxo no plano de dadosOpenFlow. Contudo, o roteamento ocorre entre redes distintas e, assim, entre VLANsdiferentes. Ao identificar a interface de saıda do roteador virtual em que o pacote deveser encaminhado, a aplicacao POX identifica tambem a VLAN de saıda do pacote. Paratanto, a aplicacao POX consulta qual o marcador de VLAN esta associado a interfacevirtual de rede, pela qual o pacote seria encaminhado caso realmente fosse encaminhadopela maquina virtual, recupera o novo identificador de VLAN do pacote e adiciona o novofluxo no plano de dados OpenFlow. O novo fluxo e introduzido de acordo com os camposdo pacote que dispararam o seu calculo e as acoes associadas a esse novo fluxo sao trocaros enderecos MAC de origem e destino do pacote, a troca do identificador de VLAN dopacote e, por fim, encaminhar o pacote na porta de saıda adequada.

As acoes configuradas para cada fluxo no comutador OpenFlow correspondemao roteamento do pacote. A troca dos enderecos MAC marca a troca do enlace peloqual o pacote esta sendo encaminhado. Nesse sentido, as acoes sao colocar o enderecoMAC de origem do pacote como sendo o endereco da interface pelo qual o pacote seriaencaminhado pela maquina virtual e colocar como MAC de destino do pacote o enderecoMAC consultado na tabela ARP da maquina virtual, este endereco e a traducao do IP doproximo salto para o MAC do proximo salto do pacote na rede. A troca do identificadorde VLAN corresponde a troca do segmento Ethernet em que o pacote e difundido.

A descoberta de em qual porta fısica do comutador OpenFlow o pacote modi-ficado deve ser encaminhado e feita pelo mecanismo de aprendizagem do comutador.Assim, quando um pacote chega ao comutador, este armazena o endereco MAC de ori-gem do pacote, por qual porta aquele pacote chegou e um temporizador associado a essaentrada. Desde que o temporizador esteja valido, o comutador sempre sabe em qual portaum endereco MAC esta disponıvel. Se qualquer uma dessas fases falhar, a aplicacao POXencaminha o pacote como se fosse um comutador comum, mantendo o mesmo identifi-cador de VLAN. Esse comportamento faz com que o mecanismo proposto se comportetanto como um roteador, quando conhece uma rota para o pacote, ou como um comu-tador, quando alguma das etapas de processamento do pacote falha. No caso de o nofısico da rede nao conhecer nenhuma rota para o pacote em processamento e, tambem,



nao conhecer em que porta o MAC de destino e acessıvel, o pacote e inundado na rede.O comportamento de inundacao e o comportamento padrao de um comutador que aindanao conhece como alcancar um endereco MAC de destino.

Considerando o mecanismo proposto, os responsaveis por garantirem o isola-mento da comunicacao, mesmo em um cenario de separacao de planos, sao o marcadorde VLAN e a aplicacao de controle do POX, pois todo pacote encaminhado recebe umaetiqueta de VLAN e a troca da etiqueta ocorre sempre que houver o roteamento do pacoteno plano de dados. Ja o isolamento de recursos e obtido mapeando-se os fluxos de cadarede virtual em filas com garantia de banda. O mapeamento de fluxos em filas e realizadoconsiderando o identificador da etiqueta de VLAN como o criterio de classificacao defluxos adotado pelo sistem QFlow [Mattos and Duarte 2012].

5. O Modelo de AtacanteAs redes virtuais sao administradas por entidades diferentes e todas compartilham

os mesmos recursos fısicos. Assim, nao e possıvel assumir que todas as redes virtuais saoconfiaveis e bem comportadas, ou que nao tentariam comprometer as demais, seja inten-cionalmente ou nao. Dessa forma, dois modelos de rede virtual atacante sao consideradosnesse artigo. O primeiro consiste em um no atacante, pertencente a uma dada rede vir-tual, que gera pacotes a uma taxa superior a reservada para a sua rede virtual, para outrono de sua mesma rede virtual. Assim, o atacante aumenta a taxa de geracao de pacotesna tentativa de degradar o desempenho do encaminhamento de pacotes nas demais redesvirtuais que compartilham os mesmos nos fısicos com o no malicioso. O segundo modeloe baseado na quebra da privacidade da rede virtual. O no atacante assume o enderecoIP de um no de outra rede virtual e tenta escutar os pacotes dessa outra rede virtual. Oscomportamentos de degradar o desempenho de outras redes virtuais que compartilhemrecursos e bisbilhotar o trafego de outra rede virtual sao definidos como comportamentosprejudiciais e o no, ou a rede, que adotarem esses comportamentos sao maliciosos.

6. ResultadosO prototipo desenvolvido utiliza o hipervisor Xen 4.0 para prover os domınios vir-

tuais que hospedam os planos de controle dos elementos de rede virtuais e utiliza o comu-tador programavel Open vSwitch 1.2.2 para prover a funcao de encaminhamento no planode dados do sistema. O Open vSwitch [Pfaff et al. 2009] e configurado para ser usado pelocontrolador POX do OpenFlow. As ferramentas Iperf3, Tcpdump4 e httperf5 foramusadas para realizar as medidas de avaliacao de desempenho do prototipo. Dois compu-tadores pessoais compoem o cenario dos experimentos. Ambos executam o prototipo daarquitetura proposta. Nos computadores pessoais foram instanciadas tres maquinas vir-tuais que apresentam a funcao de emissor, encaminhador e receptor de pacotes. Todosos computadores possuem processadores Intel Core 2 Quad 2.4 GHz e 4 GB de memoriaRAM. Cada computador possui, no mınimo, 2 interfaces de rede sendo que todas sao con-figuradas para funcionarem a 100 Mb/s, uma vez que havia tambem interfaces de 1 Gb/s.As tres maquinas virtuais que realizam a funcao de roteador sao configuradas com umaCPU virtual, 128 MB de memoria RAM e executa o Debian Linux 2.6-32-5. Duranteos testes, foram configuradas rotas estaticas entre as maquinas virtuais. Os resultadosapresentados sao medias, com intervalo de confianca de 95%.

O primeiro experimento avalia a negacao de servico devido a baixo desempenhode processamento na construcao de tabelas de fluxos. Assim, avalia-se a capacidade do

3http://iperf.sourceforge.com.4http://www.tcpdump.org.5http://www.hpl.hp.com/research/linux/httperf/.



(a) Taxa de fluxos configurados com su-cesso em relacao a taxa de novos fluxos sub-metidos ao sistema.

(b) Isolamento de recursos. Atacante tentaexaurir recursos de rede.

Figura 2. Os experimentos foram realizados entre duas maquinas virtuais hospe-dadas no no fısico 1 se comunicando com duas outras maquinas virtuais hospe-dadas no no fısico 2. Cada par, geradora/receptora, pertence a uma rede virtual.

mecanismo proposto em reagir a definicao de fluxos em rajadas, uma vez que optou-sepelo uso do OpenFlow. Deve ser ressaltado que o OpenFlow envia o cabecalho do pri-meiro pacote de todo fluxo para seja inserido este novo fluxo na tabela de fluxos. Esseprocedimento e um gargalo do OpenFlow e, portanto, e importante avaliar se o desem-penho do mecanismo proposto nessas condicoes e pior que o do OpenFlow. Para tanto,a rede de testes foi configurada para uma maquina virtual hospedada no no fısico 1 secomunicar com outra maquina virtual hospedada no no fısico 2, atraves de um roteadorvirtual tambem hospedado no no fısico 2. A geracao de novos fluxos foi realizada peloaplicativo httperf para gerar uma taxa fixa de conexoes HTTP por segundo. O resul-tado do teste avalia a taxa de conexoes atendidas. Cada conexao bem sucedida resultana instanciacao de dois novos fluxos. A Figura 2(a) evidencia que a proposta de iso-lamento seguro de redes virtuais alcanca, nesse cenario, uma taxa de aproximadamente700 fluxos/s, que e superior ao cenario em que o encaminhamento em Camada 2 do Open-Flow padrao, executado pela aplicacao de comutacao forwarding.l2 learning doPOX. O cenario OpenFlow foi testado sob duas hipoteses: usando a marcacao de VLANs,referenciado na figura como OpenFlow com Isolamento; e sem a marcacao deVLANs, OpenFlow sem Isolamento. Em ambos os casos o desempenho do Open-Flow foi inferior ao do mecanismo proposto. A melhora introduzida pela proposta deve-sea implementacao da separacao entre planos de controle e dados que processa todos os pa-cotes, inclusive o primeiro pacote, no Domınio 0, enquanto no OpenFlow age como umcomutador somente, enviando os pacotes para o roteador virtual.

O segundo experimento evidencia o isolamento dos recursos de rede provido pelomecanismo proposto. O experimento avalia o comportamento do mecanismo sob o ataquede negacao de servico de um no virtual que tenta exaurir os recursos de rede do no fısico.Para tanto, o experimento mostra a diferenciacao de qualidade de servico entre redesvirtuais. Esse experimento consiste em criar duas redes virtuais, Rede 1 e Rede 2,cada uma com, respectivamente, banda passante garantida de 20 Mb/s e 80 Mb/s. Para arealizacao do experimento, cada rede virtual e composta por duas maquinas virtuais, umageradora e uma receptora para cada rede virtual, sendo que as duas maquinas virtuaisgeradoras estao no no fısico 1, enquanto as duas maquinas virtuais receptoras estao no nofısco 2. O gerador de cada uma das redes transmite, a uma taxa constante, 100 Mb/s detrafego UDP de pacotes de 1472 B para cada rede virtual6. Ambas as redes tem capacidade

6A carga util dos pacotes gerados e de 1472 B, que somados aos cabecalhos do UDP e do IP gera um



de exaurir os recursos do no fısico. A banda total requerida pelas duas redes virtuaise entao de 200 Mb/s e, portanto, superior a capacidade dos enlaces de 100 Mb/s. AFigura 2(b) mostra a protecao do mecanismo proposto ao ataque de negacao de servicoentre redes virtuais. Ate 30 s de teste nao ha o isolamento de recursos, assim, as duas redesvirtuais disputam igualmente os recursos do enlace. Apos 30 s, o controlador de recursose ativado, redirecionando os pacotes de cada rede virtual para uma fila e configurandoos limites de banda de cada fila. A Figura 2(b) evidencia que o isolamento de banda ealcancado pelo mecanismo proposto.

(a) Primeiro pacote do fluxo. (b) Demais pacotes do fluxo.

Figura 3. Comparacao dos atrasos introduzidos pelo encaminhamento a) do pri-meiro pacote de um fluxo e b) dos demais pacotes de um fluxo.

O terceiro experimento tem como objetivo avaliar o atraso introduzido pelo me-canismo proposto ao encaminhar os pacotes. A avaliacao do atraso baseia-se no tempode ida e volta (RTT - Round Trip Time) de pacotes ICMP Echo Request e Echo Reply.A Figura 3 compara o atraso introduzido pelo roteamento proposto, referenciado comoIsolado, com o encaminhamento sem a marcacao de VLANs, referenciado como NaoIsolado, e o atraso do Open vSwitch atuando como comutador, referenciado comoOVS. Na figura, a curva do Open vSwitch se refere a configuracao para somente comu-tar os pacotes entre as interfaces do no encaminhador, agindo semelhante a uma bridge;enquanto o mecanismo de isolamento seguro proposto tambem usa o mecanismo OpenvSwitch, mas realiza tambem a separacao de planos, isolando a comunicacao de redesvirtuais com base na aplicacao POX desenvolvida para controlar o plano de dados Open-Flow. O experimento do atraso do primeiro pacote considera somente o atraso do pacoteque gera a instanciacao do fluxo no plano de dados OpenFlow. Os resultados de atrasomostrados na Figura 3(a) revelam que o atraso introduzido pelo controle da aplicacaoPOX, mesmo sem isolamento, e da ordem de 20 ms. Quando o tratamento do pacote en-volve a definicao da VLAN em que o pacote deve ser encaminhado, o atraso do primeiropacote chega a aproximadamente 30 ms. Esse atraso e referente ao encaminhamento doprimeiro pacote de cada fluxo para o POX, para que esse processe as informacoes dopacote e instale um novo fluxo no comutador OpenFlow do plano de dados. No encami-nhamento dos demais pacotes, o atraso introduzido e o mesmo para as tres abordagens, oque evidencia que esse atraso e devido somente ao encaminhamento do Open vSwitch.

O proximo experimento verifica a eficacia do mecanismo isolamento dacomunicacao de redes virtuais, quando um atacante tenta bisbilhotar a comunicacao deoutra rede virtual (eavesdropping) ou injetar trafego em outra rede. A ideia central desseexperimento e definir duas redes virtuais e, entao, uma rede tentar injetar trafego na outra.A Rede Virtual 1 e composta por uma maquina virtual hospedada no Roteador Fısico 1. A

tamanho total de 1500 B, que corresponde ao tamanho maximo de conteudo de um quadro Ethernet.



(a) Sem isolamento de comunicacao. (b) Com isolamento da comunicacao.

Figura 4. Encaminhamento de pacotes para a Rede Virtual 1 e para Rede Virtual 2que possuem o mesmo endereco IP: a) redes nao isoladas - as duas redes rece-bem os pacotes encaminhados para o IP comum, pois a Rede 2 recebe a soma(80 Mb/s) da taxa relativa aos pacotes da Rede 1 (30 Mb/s) mais a taxa de pacotesda Rede 2 (50 Mb/s); b) redes isoladas - cada rede virtual so recebe os pacotesque lhe sao destinados, pois a Rede 2 so recebe a taxa de 50 Mb/s.

Rede Virtual 2 e composta por uma maquina virtual hospedada no Roteador Fısico 1 e ou-tra hospedada no Roteador Fısico 2. Ambos os nos do Roteador Fısico 1 sao emissores dedados UDP de 1472 B. Todas as maquinas virtuais foram configuradas para pertenceremao mesmo espaco de enderecamento IP e enviam dados para um mesmo IP de destino.No entanto, como as redes virtuais sao isoladas, espera-se que o fluxo da Rede Virtual 1nao interfira no fluxo da Rede Virtual 2. A Figura 4(a) mostra que no cenario sem isola-mento, o no receptor da Rede Virtual 2 recebe tanto os pacotes da Rede Virtual 2, comoos pacotes da Rede Virtual 1, comprovando a inexistencia de isolamento da comunicacaode redes virtuais e sendo capaz de bisbilhotar os fluxos da Rede Virtual 1. Ja a Figura 4(b)demonstra que o mecanismo proposto isola o espaco de enderecamento de cada rede vir-tual, pois o trafego da Rede Virtual 1 nao interfere no trafego da Rede Virtual 2, ja que oreceptor da Rede Virtual 2 so recebe os pacotes pertencentes a sua rede.

(a) Sem isolamento de comunicacao. (b) Com isolamento da comunicacao.

Figura 5. Encaminhamento de pacotes para um endereco de um grupo IP mul-ticast: a) redes nao isoladas - as duas redes recebem os pacotes encaminha-dos para o grupo multicast comum, pois a Rede 2 recebe a soma (80 Mb/s) dataxa relativa aos pacotes da Rede 1 (30 Mb/s) mais a taxa de pacotes da Rede 2(50 Mb/s); b) redes isoladas - cada rede virtual so recebe os pacotes que lhe saodestinados, pois a Rede 2 so recebe a taxa de 50 Mb/s.

A Figura 5 mostra o isolamento da comunicacao entre redes virtuais no cenario deuma comunicacao multicast. Nesse caso, o cenario e semelhante ao do experimento ante-



rior. No entanto, ao inves de os nos emissores enviarem pacotes para um dado enderecoIP unicast, os nos agem como fontes de dados multicast para um dado grupo. O noreceptor age como sorvedouro desse grupo. A eliminacao desta vulnerabilidade e sig-nificativa, pois os protocolos de roteamento, como o OSPF (Open Shortest Path First),usam comunicacao multicast para descoberta de topologia, logo, e importante que os pa-cotes multicast de uma dada rede virtual nao sejam encaminhados para outras redes, nemseja possıvel que outras redes injetem trafego multicast em uma dada rede virtual. AFigura 5(a) mostra que no caso sem isolamento de comunicacao, o no receptor da RedeVirtual 2 recebe tanto os pacotes de sua rede, quanto os da Rede Virtual 1. A Figura 5(b)comprova que, ao usar o mecanismo de isolamento de comunicacao de redes proposto,o no receptor da Rede Virtual 2 so recebe os pacotes enviados pelo no emissor de suamesma rede.

7. Conclusao

O isolamento seguro do espaco de enderecamento e o tratamento apropriado dospacotes multidestinatarios e fundamental para garantir que uma rede virtual maliciosanao seja capaz de bisbilhotar (eavesdropping) ou injetar pacotes em outras redes virtuais.Este artigo propos um mecanismo de isolamento para a virtualizacao de redes que proveisolamento completo entre redes virtuais, isolando tanto a comunicacao de redes virtuaisquanto o consumo de recursos de cada rede virtual. O mecanismo proposto baseia-seno sistema hıbrido de virtualizacao de redes XenFlow, em que o plano de controle exe-cuta em uma maquina virtual Xen e o plano de dados e realizado em um comutador porsoftware programavel OpenFlow. A principal contribuicao desse artigo e a garantia deisolamento de redes virtuais empregando o paradigma de separacao de planos que resultatambem em um alto desempenho do encaminhamento de pacotes. Assim, um dos desa-fios da proposta e rotear os pacotes entre as VLANs, sem que o pacote deixe o plano dedados. A proposta, entao, adiciona a identificacao da VLAN de destino, associando umidentificador de VLAN (Virtual Local Area Network) a cada segmento de rede virtual, asacoes tomadas no plano de dados ao rotear pacotes. Logo, a ideia chave da proposta sebaseia no uso do Open vSwitch, como um comutador OpenFlow, para obter ao mesmotempo informacoes da Camada Ethernet, de VLAN e da Camada IP atraves dos campos daespecificacao OpenFlow, e tambem na insercao do marcador de VLAN entre as interfacesvirtuais e o comutador OpenFlow.

Um prototipo da arquitetura foi implementado e avaliado. Os resultados demons-tram que o mapeamento dos pacotes em VLANs introduz um atraso no encaminhamentono primeiro pacote. Contudo, o atraso nao afeta os demais pacotes do fluxo. O mecanismoproposto alcancou uma taxa de definicao de fluxos por segundo superior a alcancada pelaaplicacao padrao de comutacao do OpenFlow. Por fim, os resultados mostram que oisolamento da comunicacao entre redes virtuais e alcancado mesmo no cenario em queas redes virtuais executam aplicacoes em multicast ou compartilham o mesmo espacode enderecamento IP. Os experimentos demonstram a seguranca do mecanismo propostoa dois modelos de atacante: (i) capaz de bisbilhotar redes virtuais que compartilham omesmo substrato; (ii) capaz de exaurir recursos de rede compartilhados.

Como trabalhos futuros a etiqueta de VLAN sera substituıda por uma marcacaoMPLS (Multiprotocol Label Switching), cuja semantica do identificador de circuitos vir-tuais sera sobrecarregada. Nessa abordagem, e possıvel usar ate 23 bits para a marcacaoda rede virtual mantendo as vantagens do sistema proposto. Assim, o mecanismo pro-posto poderia identificar ate 8 milhoes de redes virtuais em vez das atuais 4 mil possıveiscom VLAN, o que e um requisito para centros de dados de grande porte.



8. Referencias[Barabash et al. 2011] Barabash, K., Cohen, R., Hadas, D., Jain, V., Recio, R., and Rochwerger, B. (2011). A

case for overlays in dcn virtualization. In Proceedings of the 3rd Workshop on Data Center-Convergedand Virtual Ethernet Switching, pages 30–37. ITCP.

[Bari et al. 2013] Bari, M., Boutaba, R., Esteves, R., Granville, L., Podlesny, M., Rabbani, M., Zhang, Q., andZhani, M. (2013). Data center network virtualization: A survey. Communications Surveys Tutorials,IEEE, 15(2):909–928.

[Egi et al. 2007] Egi, N., Greenhalgh, A., Handley, M., Hoerdt, M., Mathy, L., and Schooley, T. (2007).Evaluating Xen for router virtualization. In Computer Communications and Networks, 2007. ICCCN2007. Proceedings of 16th International Conference on, pages 1256–1261. IEEE.

[Feamster et al. 2007] Feamster, N., Gao, L., and Rexford, J. (2007). How to lease the Internet in your sparetime. ACM SIGCOMM Computer Communication Review, 37(1):61–64.

[Fernandes and Duarte 2010] Fernandes, N. and Duarte, O. (2010). XNetMon: Uma arquitetura comseguranca para redes virtuais. Anais do X Simposio Brasileiro em Seguranca da Informacao e de Siste-mas Computacionais, pages 339–352.

[Fernandes et al. 2010] Fernandes, N., Moreira, M., Moraes, I., Ferraz, L., Couto, R., Carvalho, H., Campista,M., Costa, L., and Duarte, O. (2010). Virtual networks: Isolation, performance, and trends. Annals ofTelecommunications, pages 1–17.

[Fernandes and Duarte 2011] Fernandes, N. C. and Duarte, O. C. M. B. (2011). Provendo isolamento e qua-lidade de servico em redes virtuais. In XXIX Simposio Brasileiro de Redes de Computadores e SistemasDistribuıdos - SBRC’2011.

[Figueiredo et al. 2013] Figueiredo, U., Lobato, A., Mattos, D. M. F., Ferraz, L. H. G., and Duarte, O. C.M. B. (2013). Analise de desempenho de mecanismos de encaminhamento de pacotes em redes virtuais.In Simposio Brasileiro de Redes de Computadores e Sistemas Distribuıdos 2013 - XVIII Workshop deGerencia e Operacao de Redes e Servicos (WGRS).

[Greenberg et al. 2009] Greenberg, A., Hamilton, J. R., Jain, N., Kandula, S., Kim, C., Lahiri, P., Maltz, D. A.,Patel, P., and Sengupta, S. (2009). Vl2: a scalable and flexible data center network. In Proceedings ofthe ACM SIGCOMM 2009, SIGCOMM ’09, pages 51–62, New York, NY, USA. ACM.

[Hao et al. 2010] Hao, F., Lakshman, T. V., Mukherjee, S., and Song, H. (2010). Secure cloud computingwith a virtualized network infrastructure. In Proceedings of the 2nd USENIX conference on Hot topicsin cloud computing, HotCloud’10, Berkeley, CA, USA. USENIX Association.

[Huang 2005] Huang, M. (2005). Vnet: Planetlab virtualized network access. Technical report, Tech. Rep.PDN–05–029, PlanetLab Consortium.

[Mattos and Duarte 2012] Mattos, D. M. F. and Duarte, O. C. M. B. (2012). QFlow: Um sistema com garantiade isolamento e oferta de qualidade de servico para redes virtualizadas. In XXX Simposio Brasileiro deRedes de Computadores e Sistemas Distribuıdos - SBRC’2012.

[Mattos et al. 2011] Mattos, D. M. F., Fernandes, N. C., and Duarte, O. C. M. B. (2011). XenFlow: Um sis-tema de processamento de fluxos robusto e eficiente para migracao em redes virtuais. In XXIX SimposioBrasileiro de Redes de Computadores e Sistemas Distribuıdos - SBRC’2011.

[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford,J., Shenker, S., and Turner, J. (2008). OpenFlow: enabling innovation in campus networks. ACMSIGCOMM Computer Communication Review, 38(2):69–74.

[Mudigonda et al. 2011] Mudigonda, J., Yalagandula, P., Mogul, J., Stiekes, B., and Pouffary, Y. (2011). Ne-tlord: a scalable multi-tenant network architecture for virtualized datacenters. In Proceedings of theACM SIGCOMM 2011, SIGCOMM ’11, pages 62–73, Toronto, Ontario, Canada. ACM.

[Nakagawa et al. 2012] Nakagawa, Y., Hyoudou, K., and Shimizu, T. (2012). A management method of ipmulticast in overlay networks using openflow. In Proceedings of the first workshop on Hot topics insoftware defined networks, HotSDN ’12, pages 91–96, Helsinki, Finland. ACM.

[Perlman et al. 2011] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and Ghanwani, A. (2011). RoutingBridges (RBridges): Base Protocol Specification. RFC 6325 (Proposed Standard). Updated by RFCs6327, 6439.

[Pfaff et al. 2009] Pfaff, B., Pettit, J., Koponen, T., Amidon, K., Casado, M., and Shenker, S. (2009). Exten-ding networking into the virtualization layer. Proc. HotNets.

[Pisa et al. 2010] Pisa, P., Fernandes, N., Carvalho, H., Moreira, M., Campista, M., Costa, L., and Duarte, O.(2010). OpenFlow and Xen-based virtual network migration. In Pont, A., Pujolle, G., and Raghavan, S.,editors, Communications: Wireless in Developing Countries and Networks of the Future, volume 327 ofIFIP Advances in Information and Communication Technology, pages 170–181. Springer Boston.

[Sridharan et al. 2013] Sridharan, M., Duda, K., Ganga, I., Greenberg, A., Lin, G., Pearson, M., and Thaler,P. (2013). NVGRE: Network Virtualization using Generic Routing Encapsulation. NVGRE.

[Wang et al. 2008] Wang, Y., Keller, E., Biskeborn, B., van der Merwe, J., and Rexford, J. (2008). Virtual rou-ters on the move: live router migration as a network-management primitive. ACM SIGCOMM ComputerCommunication Review, 38(4):231–242.



um mecanismo para isolamento seguro de redes virtuais ... · xen virtual machines. in the plane...

Documents