RevPing: Suporte de Rede para Reverse Traceroute

Prévia do material em texto

PROPOSTA DE INICIAÇÃO CIENTÍFICA OU PROJETO ORIENTADO EM COMPUTAÇÃO 1
RevPing: Suporte de Rede para Reverse Traceroute
Prof. Marcos Augusto M. Vieira (ICEx sala 4017, mmvieira@dcc.ufmg.br)
Prof. Ítalo Cunha (ICEx sala 3024, cunha@dcc.ufmg.br)
I. INTRODUÇÃO
Informações sobre a topologia da Internet, a
sequência de enlaces e roteadores utilizada em cada
caminho, são úteis para várias aplicações como
gerenciamento de redes e identificação de falhas.
A ferramenta usual para mapear a topologia da
Internet no nível de roteadores é o traceroute. O
traceroute identifica uma sequência de interfaces dos
roteadores no caminho entre dois nós na Internet.
Infelizmente, o traceroute só consegue identificar
interfaces de roteadores no caminho de ida, da
origem até o destino; o traceroute não consegue
medir o caminho reverso. Na Fig. 1, um traceroute
executado deA paraD identifica os roteadores de
1 a 4, mas não os roteadores de 5 a 8.
Medir caminhos reversos na Internet é importante
pois políticas de roteamento e engenharia de tráfego
geralmente resultam em caminhos assimétricos [1].
Medir caminhos reversos, por exemplo, é neces-
sário para identificar a localização de falhas na
Internet [2]. A solução atual para medir caminhos
reversos na Internet é o sistema Reverse Trace-
route [3]. Infelizmente, o Reverse Traceroute tem
problemas de precisão, escalabilidade e cobertura.
Em particular, ele requer coordenação entre vá-
rios nós distribuídos geograficamente e usa duas
funcionalidades comumente desativadas na Internet:
suporte a IP Record Route e falsificação da origem
de pacotes (spoofing).
A D
1
8
2
7
3
6
4
5
Figura 1. Ilustração de rotas assimétricas.
II. OBJETIVO
Neste projeto pretendemos estender o protocolo
ICMP (Internet Control Message Protocol) com uma
requisição de ping remoto,RevPing (Remote ICMP
Echo Request). Um requisito para requisições de
ping remoto é permitir a medição de caminhos
reversos na Internet; evitando a necessidade de siste-
mas complexos como o Reverse Traceroute [3]. Os
desafios para o desenvolvimento de pings remotos
incluem segurança e escalabilidade. Em particular,
precisamos garantir que pings remotos não possam
ser usados para causar ataques de negação de ser-
viço e que não requiram armazenamento de estado
em nós intermediários.
Esperamos que pings remotos deem suporte à
medição de caminhos reversos e propiciem a criação
de novas ferramentas de monitoramento, facilitando
mapeamento topológico da Internet e ajudando ope-
radores de rede a identificar causas e de problemas
de desempenho.
III. D ESENVOLVIMENTO E AVALIAÇÃO
Avaliaremos o RevPing implementando um pro-
tótipo no kernel do Linux e fazendo experimentos
locais controlados. Avaliação na Internet é difícil
devido à necessidade de trocar o kernel dos compu-
tadores; para contornar este problema podemos criar
pacotes para as principais distribuições Linux (e.g.,
Ubuntu) e usar computadores de voluntários. Outra
alternativa é implementar nosso protótipo como uma
aplicação e avaliá-lo no PlanetLab.
IV. COMPETÊNCIAS
Será útil no desenvolvimento do trabalho experi-
ência com C, Linux, captura e construção de pacotes
de rede (libnet, libpcap eraw sockets).
REFERÊNCIAS
[1] Y. He, M. Faloutsos, S. Krishnamurthy, and B. Huffaker, “On
Routing Asymmetry in the Internet,” inProc. IEEE GLOBE-
COM, 2005.
[2] E. Katz-Bassett, C. Scott, D. R. Choffnes, I. Cunha, V. Valancius,
N. Feamster, H. V. Madhyastha, T. Anderson, and A. Krish-
namurthy, “LIFEGUARD: Practical Repair of Persistent Route
Failures,” inProc. ACM SIGCOMM, 2012.
[3] E. Katz-Bassett, H. Madhyastha, V. Adhikari, C. Scott, J. Sherry,
P. van Wesep, A. Krishnamurthy, and T. Anderson, “Reverse
Traceroute,” inProc. USENIX NSDI, 2010.