Autores:  (1) Vinod S. Khandkar e Manjesh K. Hanawal, Instituto Indiano de Tecnologia de Engenharia Industrial e Pesquisa Operacional de Bombaim, Mumbai, Índia e {vinod.khandkar, mhanawal}@iitb.ac.in.  Tabela de links   Resumo e introdução   Trabalho Relacionado e Histórico   Desafios no desenvolvimento de configurações de medição de detecção de TD   Estudo de caso: Wehe - Ferramenta de detecção de TD para ambiente móvel   Deficiência do Wehe no tráfego HTTPS   Detecção TD de tráfego HTTPS   Conclusão e Referências  V. Deficiência do WEHE NO TRÁFEGO HTTPS  Nosso estudo se concentra na validação das respostas da rede para os fluxos de tráfego repetidos, detecção de TD e viabilidade operacional em diversas configurações de rede. Embora a viabilidade operacional seja validada usando o aplicativo Android “Wehe” disponível publicamente no Google Playstore, os cenários de detecção de TD são validados usando argumentos teóricos. A validação das respostas da rede requer análise de largura de banda do fluxo de tráfego recebido. Esta análise requer os logs de rede para a reprodução específica realizada de acordo com o cenário de validação. O replay feito no dispositivo e vários outros streamings   Figura 6. Classificação de tráfego do tráfego repetido do YouTube  serviços executados em paralelo é um desses cenários. O aplicativo Wehe não fornece imediatamente esses registros de rede para os replays após a conclusão dos testes. Assim, implementamos o usuário-cliente e servidor que imita o comportamento da ferramenta Wehe.  Usamos uma configuração cliente-servidor semelhante à configuração mostrada na Fig. 3 para validar o Wehe. Na configuração atual, substituímos o servidor do serviço original pelo servidor de reprodução. O userclient e o servidor de reprodução são conectados por meio de um modelador de tráfego comercial. Além disso, nossa configuração permite realizar vários replays em paralelo. Nossa configuração de validação não precisa de canais administrativos e despesas gerais, por exemplo, canais secundários. Nosso servidor sempre precisa oferecer suporte a um cliente de usuário único. A validação de cenários com múltiplos clientes utiliza diretamente a App Wehe devido à não exigência de análise de tráfego associada.  O lembrete desta seção descreve os resultados da validação.   A. Emulação de tráfego do serviço original  As respostas da rede dependem da aplicação de políticas de rede baseadas na classificação correta do tráfego de sondagem pelas caixas intermediárias da rede, conforme mencionado na Seção III-A. Validamos a classificação do tráfego emulado de Wehe usando um modelador de tráfego comercial. A classificação do tráfego emulado é observada utilizando a interface do usuário do modelador de tráfego comercial.  Para realizar o experimento, os dados do aplicativo YouTube são reproduzidos do servidor de reprodução para o usuário-cliente por meio do modelador de tráfego comercial. Durante a transferência de dados, a janela da interface do usuário do modelador de tráfego comercial é observada quanto à presença de tráfego do YouTube. Também acessamos o tráfego do YouTube usando um navegador da Internet e observamos o resultado da classificação do modelador de tráfego para basear nossas observações de classificação de tráfego.  A Figura 6 mostra o resultado da classificação de tráfego conforme mostrado pela janela de interface de usuário do modelador de tráfego comercial para tráfego acessado diretamente usando um navegador de internet a partir de um servidor do YouTube. Mostra a atividade da Internet na janela esquerda e a classificação do tráfego correspondente na janela direita.  A Figura 6(a) mostra que o tráfego acessado através do navegador de internet é corretamente classificado como YouTube. Isto está alinhado com o comportamento pretendido do modelador de tráfego comercial.  A Figura 6(b) mostra o resultado da classificação do tráfego acessado usando usuário-cliente. Mostra a evidência de que nenhum tráfego do YouTube foi transferido pelo link de comunicação. Além disso, classifica o mesmo tráfego como tráfego HTTPS. O resultado deste experimento mostra que nem todos os middleboxes de rede podem classificar corretamente o tráfego repetido do Wehe.   B. Efeito da taxa de dados no script de reprodução  A geração de tráfego de sondagem impacta a resposta da rede conforme esperado pelo algoritmo de detecção TD. Ele usa o rastreamento de tráfego do serviço original para gerar scripts de repetição que preservam os dados da aplicação e seu relacionamento de temporização. Este script de reprodução é usado na rede original e também em redes com localização geográfica diferente. Como a taxa de modelagem de tráfego varia entre redes para o mesmo serviço (como mencionado em [32]), a taxa de tráfego preservada no script de repetição pode ser diferente da taxa de modelagem de tráfego da rede atualmente considerada. A taxa de tráfego de repetição pode ser inferior à taxa de modelagem de tráfego.  A metodologia Wehe não detecta diferenciação de tráfego se a taxa de tráfego do script de repetição for inferior à taxa de modelagem da rede, pois não afeta o fluxo de tráfego. Esses scripts de repetição nunca podem detectar a modelagem de tráfego nessas redes. Assim, a capacidade de detecção de TD da ferramenta Wehe é limitada pela taxa de tráfego de sondagem do script de repetição.   C. Uso da porta número 80  As respostas da rede são orientadas pela percepção das caixas intermediárias da rede sobre o tráfego de sondagem (consulte a Seção III-A). O script de reprodução preserva os dados no rastreamento de rede original dos aplicativos. Os servidores de aplicativos originais usam a porta 80 para dados de texto simples e a porta 443 para transferência de dados criptografados. O script de reprodução Wehe usa diretamente os dados criptografados do rastreamento de rede do aplicativo e os transmite na porta 80. Nesses casos, Wehe espera que seu fluxo de tráfego de reprodução original seja classificado corretamente pelos dispositivos de rede usando dados criptografados do aplicativo. É impossível para esses dados na porta 80, pois os dados de tráfego criptografados não podem expor sua identificação ao dispositivo de rede. Assim, a ferramenta Wehe não pode gerar os fluxos de tráfego necessários para serviços executados na porta número 443 devido ao uso padrão da porta 80 para execução de reprodução.   D. Comportamento de rede governado pela carga de tráfego  Observe que a escassez de recursos leva as redes a aplicarem certos gerenciamentos de tráfego de rede, especialmente em cenários de carga de rede pesada, que são benéficos para todos os serviços ativos em sua rede, por exemplo, gerenciamento de tráfego baseado em QoS (consulte a Seção III-A). Validamos o efeito desse gerenciamento de tráfego   Figura 7. Efeito da carga da rede no desempenho do fluxo de tráfego de Wehe  sobre o desempenho dos replays de controle e originais. A validação usa os três cenários a seguir para a validação,  • Repetindo apenas os dois fluxos de tráfego de Wehe sem qualquer carga na rede (Fig 7(a))  • Repetição dos três fluxos de tráfego do Wehe com um serviço de streaming adicional rodando em paralelo (Fig. 7(b))  • Repetição dos três fluxos de tráfego do Wehe com 2 serviços de streaming adicionais rodando em paralelo (Fig. 7(c))  O desempenho na Figura 7 (a) mostra que o desempenho dos fluxos de tráfego gerados pela ferramenta Wehe é o mesmo sem condições adicionais de carga de rede. À medida que a carga da rede aumenta, o desempenho da reprodução de controle se desvia daquele da reprodução original e em um nível superior (Fig. 7 (b)). Embora o desempenho do replay de controle se desvie ainda mais do replay original no lado inferior, dois replays originais ainda mostram desempenhos semelhantes, como mostrado na Fig. Isso invalida a expectativa da ferramenta Wehe de que a reprodução do controle não seja diferenciada. Também invalida a afirmação da ferramenta de detectar o TD devido à largura de banda total.   E. Testamos vários dispositivos na mesma sub-rede  Os canais laterais são introduzidos no design Wehe para oferecer suporte a vários clientes de usuários simultaneamente. Os canais laterais também auxiliam na identificação do mapeamento entre usuário-cliente e uma combinação de endereços IP e portas. É útil no caso de redes que utilizam NATs [33]. Validamos o suporte do Wehe para vários clientes e redes habilitadas para NAT usando dois testes diferentes. Primeiro, conectamos dois clientes-usuários de dentro da mesma sub-rede, ou seja, clientes compartilhando o mesmo endereço IP público. Em um teste, a ferramenta Wehe testa o mesmo serviço em ambos os dispositivos, por exemplo, o aplicativo Wehe em ambos os dispositivos testa o YouTube. O resultado mostra que o teste Wehe foi concluído em apenas um dispositivo, enquanto o aplicativo Wehe fechou abruptamente em outro dispositivo. Repetimos o mesmo cenário, mas desta vez Wehe testa serviços diferentes, por exemplo, Wehe em um dispositivo testando o YouTube enquanto outro testa o Netflix. Descobrimos que o teste Wehe em um dispositivo é concluído corretamente enquanto o teste Wehe em outro dispositivo gera um erro na tela, informando ao usuário que outro cliente já está realizando o teste, conforme mostrado na Fig. não oferece suporte a vários dispositivos se eles compartilharem o mesmo endereço IP. Embora um canal lateral seja útil para identificar cada replay de um usuário-cliente conectado diretamente ao servidor de replay Wehe, ele não é útil na rede que usa dispositivos NAT. Vários usuários compartilham o mesmo endereço IP no caso de NAT. Nesses casos, o canal lateral não pode mapear exclusivamente cada repetição executada para um cliente. Ele limita o uso do Wehe a apenas um cliente ativo por servidor de reprodução, ISP e aplicativo. Esta limitação também é documentada pelos desenvolvedores do Wehe.   F. Efeito da carga da rede do dispositivo na detecção de TD  O servidor de repetição do Wehe usa os mesmos intervalos entre a transferência de dados do aplicativo e o tráfego original do aplicativo. Espera-se que tal estratégia de transmissão não esgote a largura de banda disponível. Portanto, o efeito da modulação da taxa de origem devido ao excesso da taxa de tráfego acima da largura de banda disponível é improvável. Isso faz com que os replays originais e de controle mostrem desempenhos de tráfego semelhantes, a menos que sejam modificados deliberadamente por políticas de rede, ou seja, TD.  No entanto, esta expectativa nem sempre é satisfeita, pois a taxa de tráfego de dados é modulada pela carga da rede no dispositivo do usuário durante a realização dos testes Wehe. Tais perturbações criam discrepâncias, pois o efeito da carga atual da rede, variável no tempo, sobre o tráfego de sondagem também varia no tempo e pode nem sempre ser o mesmo. A estratégia de repetição consecutiva do Wehe garante que ambos os fluxos de tráfego de sondagem (reprodução original e de controle) sejam afetados de maneira diferente pela carga atual da rede. Sob tal carga de rede no lado do dispositivo, a noção de serviços que não esgotam a largura de banda disponível deixa de existir juntamente com os seus benefícios para a detecção de TD. É necessário normalizar tais fatores de confusão (consulte a Seção III-B) antes da detecção de DT.  Este artigo está   sob licença CC 4.0. disponível no arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

NetNeutrality

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

Compreendendo as deficiências do Wehe na detecção de tráfego HTTPS

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Telegram: a ponte da Crypto Island para o continente

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Telegram: a ponte da Crypto Island para o continente

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps