UmaRedeSobrepostanoNívelde Sistemas Autônomos para Rastreamento de ... · UmaRedeSobrepostanoNívelde Sistemas Autônomos para Rastreamento de Tráfego IP∗ André O. Castelucio

Uma Rede Sobreposta no Nível deSistemas Autônomos paraRastreamento de Tráfego IP∗

André O. Castelucio1, Ronaldo M. Salles1 & Artur Ziviani2

1Instituto Militar de Engenharia - IMEPraça General Tibúrcio, 80

CEP 22290-270 - Rio de Janeiro - RJ - [email protected]

[email protected]

2Laboratório Nacional de Computação Científica - LNCCAv. Getúlio Vargas, 333

CEP 25651-075 - Petrópolis - RJ - [email protected]

AbstractDistributed Denial of Service (DDoS) attacks cur-

rently represent a serious threat to the appropriate opera-tion of Internet services. We propose an overlay networkthat provides an IP traceback system to be deployed atthe level of Autonomous Systems (ASes) to deal with thisthreat. Our proposed AS-level IP traceback system con-trasts with previous work as it requires a priori no knowl-edge of the network topology while allowing single packettraceback and incremental deployment. We also investi-gate and evaluate the strategic placement of our system,showing that the partial deployment offered by our pro-posed system provides relevant results in IP traceback,rendering it feasible for large-scale networks such as theInternet.Keywords: IP Traceback, Denial of Service, AS-level

Packet Traceback

ResumoAtaques distribuídos de negação de serviço (DDoS)

atualmente representam uma grande ameaça à operaçãoadequada de serviços na Internet. Nós propomos umsistema que cria uma rede sobreposta de rastreamentode tráfego IP a ser implementada no nível de Sistemas∗A proposta preliminar deste trabalho foi apresentada em [10], sendo opresente artigo uma versão estendida de [12].

Autônomos (SAs) para lidar com essa ameaça. Nossosistema de rastreamento de tráfego IP no nível de SAscontrasta com os trabalhos anteriores, pois ele não re-quer conhecimento prévio da topologia da rede enquantopermite o rastreamento de um único pacote bem comouma instalação parcial e incremental. Nós também in-vestigamos e avaliamos a implementação estratégica dosistema proposto, mostrando que a possibilidade de insta-lação parcial ofertada pelo nosso sistema provê resulta-dos relevantes de rastreamento IP, tornando-o viável pararedes de larga escala como a Internet.Palavras-chave: Rastreamento IP, Ataques de ne-

gação de serviço, Rede Sobreposta

1. INTRODUÇÃOA Internet atual é vulnerável a ataques distribuídos de

negação de serviço (DDoS) [14, 20, 29, 30]. Ataquesdesse tipo tem como objetivo fazer com que uma rede ouserviço oferecido por ela fiquem inacessíveis a usuárioslegítimos, o que geralmente é alcançado quando um at-acante envia pacotes a uma taxa maior do que a vítimapode processar; e nos dias atuais tipicamente ocorre commúltiplas fontes enviando pacotes para a mesma vítima.Identificar a origem de ataques DDoS é uma tarefa de-

safiadora. Alguns motivos que contribuem para isto são:(i) o roteamento dos pacotes na rede é feito baseado ape-

André O. Castelucio, Ronaldo M. Salles eArtur Ziviani

Uma Rede Sobreposta no Nível de SistemasAutônomos para Rastreamento de Tráfego IP

nas no endereço de destino do pacote IP; (ii) os pacotesIP não são autenticados nomomento do encaminhamento,permitindo que pacotes com endereços forjados sejam uti-lizados em ataques DDoS [13, 22]; (iii) os pacotes tam-bém podem ser enviados por máquinas chamadas zumbis,cujos proprietários não sabem que estão participando deum ataque; (iv) nenhuma informação sobre o encam-inhamento dos pacotes é mantida nos roteadores inter-mediários devido a restrições de escalabilidade; (v) aidentificação da origem de um ataque não significa neces-sariamente encontrar o atacante, pois ele pode estar pro-tegido por um firewall ou por endereços privados e destaforma o rastreamento só será realizado até a borda da redede onde os pacotes são provenientes.Todos estes fatos deixam ao atacante uma garantia vir-

tual de anonimato e indicam claramente a necessidade decriação de mecanismos para identificar, mesmo que par-cialmente, a rota dos pacotes de ataque – os sistemas derastreamento de tráfego IP têm esta finalidade – e o de-senvolvimento de ferramentas para bloquear os ataquesao menos em alguns pontos estratégicos nesta rota.Em geral, a defesa contra ataques possui 3 fases:

(i) a detecção da ocorrência de um ataque, que é usual-mente feita por sistemas de detecção e prevenção de in-trusão [32]; (ii) a identificação da origem dos pacotes deataque, ou seja, o rastreamento dos atacantes; e (iii) a fil-tragem e bloqueio dos pacotes de ataque. Ressaltamosque o sistema aqui proposto é focado na segunda fase,ou seja, no rastreamento dos pacotes de ataque e conse-quentemente, na identificação ao menos parcial da rotautilizada pelos pacotes de ataque.Trabalhos relacionados na área de rastreamento de

tráfego (discutidos mais profundamente na Seção 2) pos-suem como requisito típico a necessidade do sistemaproposto por cada um deles ser instalado em todos osroteadores da rede monitorada. Isto ocorre devido amaneira como o rastreamento se realiza, onde o resultadoesperado é o caminho completo por onde os pacotes pas-saram. Esse requisito claramente limita muito a possi-bilidade desses sistemas serem amplamente utilizados emuma rede de larga escala como a Internet.Neste artigo é proposta e avaliada uma rede sobre-

posta para rastreamento de tráfego IP que trabalha nonível de Sistemas Autônomos (SAs) e que pode ser in-stalada parcialmente em redes de larga escala como aInternet. A instalação desse sistema de rastreamento éfeita nos roteadores de borda de alguns SAs, que apósa troca de algumas informações transportadas pelo pro-tocolo BGP (Border Gateway Protocol) [34], constroemuma rede sobreposta para rastreamento de tráfego IP.Através de simulações é mostrado que o sistema aqui

proposto pode ser instalado apenas em alguns SAs darede e de forma incremental, permitindo que os SAs quequeiram se juntar a qualquer momento à tarefa de ras-

treamento possam fazê-lo, aumentando assim a eficiên-cia na identificação do caminho reverso do ataque. Alémdisso, os resultados indicam que mesmo com um númerorelativamente pequeno de SAs com o sistema instalado –desde que escolhidos estrategicamente – o rastreamentopode ser realizado de forma eficiente em redes de largaescala.O restante do artigo está organizado da seguinte

forma: na Seção 2, são discutidos os trabalhos rela-cionados. O sistema proposto é apresentado na Seção 3.Na Seção 4, o problema do posicionamento é abordadoatravés de simulações. Finalmente, na Seção 5 são apre-sentadas as conclusões e os trabalhos futuros.

2. TRABALHOS RELACIONADOSVários sistemas de rastreamento de tráfego IP foram

propostos nos últimos anos [3, 5]. Savage et al. [36] pro-puseram um sistema baseado em marcação probabilísticade pacotes, a medida que estes passam pelos roteadores.Essa marcação contém informações sobre a rota atraves-sada pelo pacote e é feita no campo de fragmentação dopacote IP. Depois de uma quantidade expressiva de pa-cotes ser recebida pela vítima, esta é capaz de reconstruiro caminho de ataque.Bellovin et al. [6] introduziram um outro sistema

baseado em marcação probabilística de pacotes. Paracada pacote selecionado, uma mensagem ICMP é enviadapara o mesmo destino do pacote escolhido, carregando in-formações sobre o pacote selecionado e sobre o roteadorque gerou esta mensagem ICMP, incluindo próximo salto,salto anterior, uma marcação de tempo e o TTL do pacote.Tal informação é usada pela vítima no momento da recon-strução da rota.Snoeren et al. [37] propuseram o sistema

SPIE (Source Path Isolation Engine), que tem comocaracterística principal o armazenamento do resumo dospacotes em Filtros de Bloom [7], a medida que estessão encaminhados pelos roteadores. Uma visão geralda aplicabilidade de Filtros de Bloom em rede podeser consultada em [9]. Esses resumos são gerados earmazenados por dispositivos chamados DGA (DataGeneration Agent), acoplados aos roteadores. Outrosdispositivos chamados SCAR (SPIE Collection andReduction Agent) são responsáveis pela execução de con-sultas em DGAs específicos de algumas regiões da redepor onde o pacote passou para identicar os roteadores queos encaminharam. Dessa forma, cada SCAR da rede écapaz de gerar um grafo parcial do ataque. Em seguida,outro dispositivo denominado STM (SPIE TracebackManager) fica responsável por criar o grafo final doataque com as informações de grafos parciais recolhidasnos SCARs. Diferentemente dos sistemas baseados em

62



marcação probabilística de pacotes, através do uso deFiltros de Bloom este sistema pode rastrear um pacote IPindividual.Laufer et al. [24] introduziram um outro sistema

baseado em Filtros de Bloom. Nesse sistema, quando umpacote atravessa um roteador, é inserida uma marca den-tro de um Filtro de Bloom Generalizado (FBG) [25], pre-sente no cabeçalho do pacote IP. Essa marca é o resultadode uma função de hash do endereço IP da interface desaída do roteador. Quando o pacote alcança o destino, elecarrega dentro do FBG a marca de todos os roteadores poronde passou. Para iniciar o rastreamento, a vítima verificaquais dos roteadores vizinhos possuem a marca no FBGe envia um pacote de reconstrução de rota para ele. Porsua vez, este roteador também verifica o FBG a procurada marca de um de seus vizinhos. Este procedimento érepetido até que o último roteador no caminho reverso doataque seja descoberto – ou que nenhum roteador tenhasua marca encontrada no FBG. Finalmente, para finalizaro rastreamento, o último roteador encontrado no processoenvia uma mensagem de volta a vítima com a rota poronde o pacote passou. De forma similar ao SPIE, estesistema pode rastrear um único pacote.Analisando os sistemas discutidos até o momento, ob-

servamos que dificilmente eles podem ser adotados deforma efetiva em redes de larga escala, como a Inter-net. Algumas razões que contribuem para este argumentoincluem: (i) a necessidade de se adquirir novos disposi-tivos; (ii) o aumento do processamento na rede, tanto nosroteadores intermediários quanto na vítima no momentoem que o rastreamento é feito; (iii) a escalabilidade lim-itada; (iv) a necessidade de mecanismos de autenticação;(v) e a necessidade de conhecimento prévio da topolo-gia da rede. Além de todos esses motivos, foi observadoque todos os sistemas analisados necessitam que sua in-stalação seja feita em todos os roteadores da rede moni-torada, desta forma contribuindo para que a instalação dosistema na Internet seja inviável – e limitando sua eficáciacontra ataques DDoS de larga escala.É importante ressaltar que a instalação de um sistema

de rastreamento em todos os roteadores da rede moni-torada pode não ser necessária para garantir um rastrea-mento eficiente. Em realidade, se faz necessário apenasidentificar alguns pontos críticos no caminho por onde ospacotes de ataque são encaminhados (por exemplo no sis-tema autônomo que encaminha uma grande quantidadede pacotes de ataque) para que providências contra osatacantes possam ser tomadas de forma eficaz. Os sis-temas que são desenvolvidos levando em consideraçãoeste argumento tipicamente operam no nível de SistemasAutônomos. Durresi et al. [18] propuseram um sistemade rastreamento no nível de SA usando a técnica de mar-cação probabilística de pacotes. Contudo, diferente deoutros sistemas que usam esta técnica, a informação é in-

serida nos pacotes pelos roteadores de borda dos SAs us-ando o número identificador do SA ao invés do endereçoIP do roteador, desta forma necessitando de um espaçomenor de armazenamento no cabeçalho do pacote. En-tretanto, sistemas baseados em marcação probabilísticade pacotes podem ser enganados por um atacante que in-sere marcações nos pacotes criando falsos positivos. Paratratar este problema, os autores introduzem um esquemade autenticação utilizando criptografia de chave simétricaque deve ser usada por todos os roteadores de borda dosSAs.

Korkmaz et al. [23] propõem o sistema AS-SPT (AS-level Single Packet Traceback), em um cenário de insta-lação parcial. Cada SA possui um ASTS (AutonomousSystem Traceback Server) responsável por monitorar osroteadores de borda e armazenar resumos dos pacotes.O ASTS também serve como ponto principal de contatopara as requisições de rastreamento vindas de usuários lo-cais ou remotos. Os autores basicamente definem a ar-quitetura do sistema sem propor um novo mecanismo derastreamento para ser usando nos ASTSes – eles sugeremo SPIE [37] como possível candidato dada sua popular-idade. Embora a arquitetura proposta permita instalaçãoparcial do sistema, ela tem como necessidade o conhec-imento prévio da topologia da rede para seu funciona-mento. Além disso, ela apresenta algumas vulnerabili-dades, já que o atacante pode usar um endereço IP for-jado de forma a executar requisições de rastreamento nosASTSes como se fosse um ASTS válido, e os ASTSespodem ser atacados se tornando incapazes de executar orastreamento. Para diminuir estes problemas, os autorespropõem a utilização de um mecanismo qualquer exis-tente contra ataques em que os atacantes utilização en-dereços IP forjados, a utilização de um protocolo para acomunicação entre os ASTSes ou até mesmo uma formados ASTSes que estão realizando o rastreamento saltaremos ASTSes que estão sendo atacados. Vale ressaltar que amaneira como isso pode ser feito não foi determinada notrabalho.

Em um trabalho anterior [11], nós avaliamos o de-sempenho de uma possível instalação parcial de um sis-tema de rastreamento de tráfego, sem a criação de umarede sobreposta. A partir dos resultados promissores en-contrados nesse trabalho anterior, houve a concepção e aproposição do sistema de rede sobreposta no nível de Sis-temas Autônomos para rastreamento de tráfego IP apre-sentado no presente artigo. Em contraste com os demaistrabalhos na literatura sobre rastreamento de tráfego IP,a rede sobreposta no nível de SAs para rastreamento detráfego IP proposta neste artigo não requer conhecimentoprévio da topologia da rede enquanto permite o rastrea-mento de um único pacote bem como uma instalação par-cial e incremental.

63



3. REDE SOBREPOSTA PARA RASTREA-MENTO DE TRÁFEGO IP NO NÍVEL DE SASNo sistema proposto neste trabalho, a marcação dos

pacotes é feita de forma similar ao originalmente propostopor Laufer et al. [24]. Os dados inseridos no FBG de cadapacote carregammarcas dos roteadores por onde o pacotepassou. Desta forma, quando o pacote chega ao destino,o FBG contém a rota do pacote. O sistema aqui proposto,no entanto, utiliza o protocolo de roteamento BGP [34]como veículo de comunicação entre os SAs que possuemo sistema de rastreamento instalado. Essa comunicaçãopermite que seja formada a rede sobreposta para rastrea-mento de tráfego IP e com sua utilização seja descobertoqual o próximo salto no caminho reverso ao utilizado pe-los pacotes de ataque para alcançarem a vítima. Sendoassim, o sistema está apto a operar em larga escala e nonível de SAs, eliminando a necessidade de ser instaladoconsecutivamente em todos os roteadores da rede. Emoutras palavras, a instalação do sistema proposto pode serrealizada de forma parcial e incremental na Internet.Vale ressaltar que a utilização dos Filtros de Bloom

em sistemas de rastreamento já foi amplamente discu-tida [24] e, portanto, preferimos exaltar as diferenças,vantagens e contribuições do nosso sistema quando com-parado aos demais.Ao longo desta seção, apresentaremos os mecanismos

através dos quais o sistema proposto: utiliza o protocoloBGP para suas finalidades, estabelece a rede sobrepostapara rastreamento de tráfego IP no nível de SAs, marcaos pacotes e realiza o rastreamento de tráfego.

3.1. USO DO BGP COMO VEÍCULO DE COMUNI-CAÇÃO DO SISTEMA PROPOSTOOs roteadores BGP usam a mensagem Update para

trocar informações de roteamento entre si – os roteadoresvizinhos são conhecidos como peers BGP. Essa men-sagem Update possui um atributo chamado PathAttribute, que é uma coleção de atributos associa-dos às rotas que podem influenciar no processo de seleçãodas mesmas. Um desses atributos, chamadoCommunityAttribute, definido na RFC 1997 [15], é usado por umgrupo de SAs que possuem características comuns. Esseatributo mostra-se bastante versátil [33, 1, 8] e pode serutilizado com diferentes propósitos, tais como roteamentomulti-home [16], engenharia de tráfego [21], suporte paraVPNs [35] e coleta de dados do BGP [28].Para o sistema de rastreamento de tráfego IP pro-

posto neste trabalho, é criado um novo CommunityAttribute chamado IP Traceback Communityque contém informações sobre a presença do sistema nosSAs, indicando que estes estão aptos a formar a rede so-breposta e realizar o rastreamente de tráfego no nível deSAs.

Uma característica importante sobre o CommunityAttribute refere-se a ele ser um atributo BGP op-cional e transitivo. Isso significa que se a implementaçãodo BGP operando no roteador de um SA não reconheceum atributo opcional presente na mensagem Updaterecebida, uma verificação se o flag transitive está ati-vado ou não para este atributo é realizada. Em casopositivo, o atributo é repassado nas mensagens Updateseguintes enviadas pelo roteador do SA para seus peers.Essa característica permite que a informação sobre oIP Traceback Community seja repassada de formatransparente pelos SAs que não possuam o sistema de ras-treamento instalado. Ao final de uma seqüência de men-sagens Update, a rede sobreposta de rastreamento, in-cluindo todos os SAs que possuem o sistema proposto in-stalado, é estabelecida ou atualizada. Nesse ponto, cadaSA com o sistema instalado contém uma tabela, chamadatabela de overlay, com a lista de todos os SAs com osistema instalado que são conhecidos pelo SA dono databela, ou seja, os seus vizinhos na rede sobreposta derastreamento de tráfego IP no nível de SAs.

3.2. CRIAÇÃO DA REDE SOBREPOSTA PARA RAS-TREAMENTO DE TRÁFEGO IPA rede sobreposta permite que o rastreamento de

tráfego seja realizado entre os roteadores dela partici-pantes (não necessariamente contíguos no nível de rota-mento) por onde o pacote passou. O rastreamento é por-tanto realizado salto a salto na rede sobreposta no níveldos SAs. Isso elimina a necessidade, comum em muitaspropostas anteriores, do sistema de rastreamento ser in-stalado em todos os roteadores das redes monitoradas.Um exemplo da criação de uma rede sobreposta pode

ser visto na topologia da Figura 1. Os SAs marcados comuma bandeira possuem o sistema de rastreamento insta-lado. Inicialmente, suas tabelas de overlay estão vazias.Quando SA1 envia uma mensagem Update para seuspeers (passo (1)), SA3 insere na sua tabela de overlayo SA1 como seu vizinho. Por outro lado, como SA2não possui o sistema instalado, ele simplesmente faz aatualização na sua tabela de rotas com as informaçõesrecebidas do SA1 na mensagem Update e, ao geraruma nova mensagem Update, repassa de forma trans-parente a informação recebida anteriormente sobre o IPTraceback Community para seus peers SA4 e SA3(passo (2)) por esta ser uma informação assinalada comotransitiva na mensagem Update recebida. SA3 recebea mensagem Update vinda de SA2 e simplesmente at-ualiza sua tabela de overlay que já possuía a informaçãosobre SA1. Por sua vez, SA4 insere SA1 como seu viz-inho em sua tabela de overlay. Ao criarem uma novamensagem Update, SA3 e SA4 inserem seus dados so-bre a IP Traceback Community e enviam a men-sagem para seus vizinhos (passos (3) e (4) respectiva-

64



mente). Após o recebimento da mensagem Update deSA3, SA4 o insere como vizinho na tabela de overlay.O mesmo procedimento é feito por SA3 após receber amensagem Update de SA4. Esse processo se repete portodos os SAs da rede.

Figura 1. Troca de mensagens Update do BGP.

Vale relembrar que as informações sobre a IPTraceback Community não geram nenhuma sobre-carga adicional na rede devido as trocas de mensagens,pois as informações são carregadas dentro das mensagensUpdate do BGP são trocadas periodicamente entre ospeers.Uma observação importante é que quando o SA pos-

sui o sistema instalado, ele armazena na tabela de over-lay a informação sobre qual SA gerou os dados sobre oIP Traceback Community e, ao enviar uma novamensagem Update, ele sobreescreve esta informaçãocom seus próprios dados, conforme nos exemplos doSA3 (passo (3)) e do SA4 (passo (4)). Entretanto, comoocorrido no exemplo do SA2, quando um SA não pos-sui o sistema instalado, ele repassa a informação tran-sitiva recebida sobre o IP Traceback Communityde forma transparente em uma nova mensagem Updatepara seus peers (passo (2)). Ao final das trocas das men-sagens Update, cada SA com o sistema proposto instal-ado possui na sua tabela de overlay seus vizinhos na redesobreposta recém atualizada. A Tabela 1 é um exemplodas tabelas de overlay para a topologia utilizada. Cadacoluna representa a tabela de overlay individual de cadaSA que possui o sistema proposto instalado. Por exem-plo, o SA1 tem como vizinhos na rede sobreposta o SA3e o SA4.

Tabela 1. Tabela de overlay dos SAs.

SA8SA8

SA4SA3SA4SA4

SA3SA1SA1SA3

SA8SA8

SA4SA3SA4SA4

SA3SA1SA1SA3

Vizinhos

Sistemas Autônomos

SA1 SA3 SA4 SA8

A rede sobreposta resultante é ilustrada na Figura 2,onde as linhas de maior espessura representam suasconexões.

Figura 2. Rede sobreposta resultante da troca de mensagens Update doBGP.

3.3. MARCAÇÃO DE PACOTESO processo de marcação de pacotes proposto original-

mente por Laufer et al. [24] foi modificado para operar deacordo com o sistema proposto neste trabalho. No pro-cesso original, quando um pacote passa pelo roteador, esteinsere uma marca no FBG de forma que o pacote chegueao destino com as marcas de todos os roteadores por ondepassou. Porém, quando um roteador está fazendo o pro-cesso de reconstrução do caminho do ataque, ele pode en-contrar a marca de mais de um de seus roteadores vizinhosno FBG. Este problema pode ser observado na Figura 3 –as setas indicam o caminho do ataque – onde o roteadorRT1 verifica que existem as marcas dos roteadores RT2 eRT3, ambos seus vizinhos, no FBG, pois ambos partici-param da rota tomada pelos pacotes de ataque. Note que,nesse caso, RT1 não possui um critério claro para decidirse o próximo roteador no caminho reverso de ataque é oseu vizinho RT2 ou RT3. Logo, se o roteador RT1 en-viar o pacote de reconstrução de rota para RT2, o rastrea-mento tende a ser concluído sem problemas. Entretanto,se o pacote de reconstrução de rota é enviado para RT3, oproblema volta a ocorrer, pois RT3 encontrará as marcasde RT2 e RT5. No caso de RT3 enviar o pacote de recon-strução de rota para RT2, o rastreamento pode pode ter-minar inesperadamente sem que seja completamente re-alizado ou gerar mensagens repetidas desnecessárias narede.No sistema proposto neste artigo, para se evitar prob-

lemas como o citado acima, antes do FBG ser preenchidocom a marca de um roteador, é proposta uma marcaçãoda seqüência dos roteadores dos SAs. A marcação da se-qüência dos roteadores dos SAs é feita da seguinte forma:ao receber um pacote, o roteador do SA que possui osistema de rastreamento instalado realiza uma operaçãológica XOR entre número identificador do SA (AS num-

65



Vítima

Atacante

RT1

RT4

RT6

RT5

RT3

RT2

?

?

Caminho dos pacotesde ataque

Dúvida na reconstruçãoFBG {RT6, RT5, RT3, RT2, RT1}

Figura 3. Problema de identificação de duas marcas no FBG.

ber – 16 bits de tamanho) e um valor de 16 bits formadopelo TTL do pacote naquele momento (8 bits de tamanho)mapeado nos 8 bits mais significativos deste valor e com-pletado de bits de valor 1 nos 8 bits menos significativos.Após este processo, é feita a marcação do pacote propri-amente dita, onde o resultado da operação XOR é sub-metido à função hash, gerando a marca a ser feita no FBG.Esse processo é realizado em todos os SAs que possuem osistema instalado. Assim quando o pacote chega ao des-tino, ele possui a marca de todos os SAs que possuemo sistema proposto por onde o pacote passou. Essa mar-cação elimina a incerteza no momento da reconstrução docaminho reverso dos pacotes de ataque como discutido napróxima Seção, ao descrevermos o processo de rastrea-mento de tráfego na rede sobreposta.

3.4. PROCESSO DE RASTREAMENTO DE TRÁFEGOO administrador de um SA que possui o sistema pro-

posto instalado que deseja realizar o rastreamento deveiniciar o processo buscando no FBG as marcas dos SAspor onde o pacote passou. Para fazer esta busca, oroteador de borda do SA por onde o processo é iniciadofaz o procedimento inverso da marcação de pacotes. Amedida que as marcas do FBG são descobertas e o cam-inho reverso é delineado, o SA que está efetuando o ras-treamento naquele momento envia um pacote de recon-strução de rota para o SA que teve sua marca encontradanos pacotes de ataque. Este pacote de reconstrução con-tém uma lista de SAs por onde passou, sendo iniciada peloSA que gerou o pedido de rastreamento, o TTL do pacotede ataque no momento que chegou à vítima e o FBG dopacote de ataque.O processo de rastreamento é ilustrado na Figura 4.

As setas indicam o caminho do ataque e a numeraçãoindica o TTL do pacote IP naquele momento. O sis-tema autônomo da vítima (SA8) inicia o rastreamento doataque. Primeiramente, o roteador de borda do SA8 ver-ifica sua tabela de overlay (ver Tabela 1) e assim con-stata que deve buscar no FBG pelas marcas de SA3 ouSA4, seus vizinhos na rede sobreposta (Figura 2). En-tão, é realizada uma operação XOR entre um valor con-stituído pelo número identificador do SA3 com TTL do

pacote no SA8 (251) acrescido de 1 (252) mapeado nos8 bits mais significativos deste valor, completado de bitsde valor 1 nos 8 bits menos significativos. Após este pro-cesso, é feito o hash deste resultado e verificado que amarca do SA3 não está presente no FBG. O mesmo pro-cesso é feito com o número identificador do SA4. Como aresposta é negativa para ambos, o mesmo procedimento énovamente realizado incrementando-se de 1 o TTL (253).Nesta nova realização do procedimento, a marca é pos-itiva para SA4. Portanto, SA8 envia um pacote de re-construção de rota para SA4 (passo (1)), que por sua vezincrementa o TTL (254) e faz o mesmo processo, bus-cando pelas marcas de SA1 e SA3, sendo esta positivapara SA3 (passo (2)). O mesmo processo é repetido noSA3 e termina quando o pacote de reconstrução de rotachega ao SA1 (passo (3)) – neste caso, a origem do ataqueestá além do SA1. Vale lembrar que o processo de rastrea-mento pode ser terminado de duas formas: quando o TTLchega a 256 ou quando um SA não consegue encontrar amarca de nenhum outro vizinho no FBG.Utilizando como exemplo o ocorrido com SA8 e pos-

teriormente com SA4, pode-se perceber que mesmo o pa-cote tendo passado por dois SAs vizinhos da rede sobre-posta em relação ao SA atual, o problema de indecisãosobre o encaminhamento a ser dado ao pacote de recon-strução não ocorre no sistema proposto, pois o TTL tam-bém armazenado no FBG auxilia a indicação da seqüênciade roteadores pelos quais os pacotes de ataque passaram.

SA1

SA5

SA7

SA6

SA4

SA3

SA2

SA8

VítimaAtacante

255

254

253252

251

Caminho dos pacotesde ataque

FBG {SA1, SA3, SA4, SA8}

(3)

Pacote de reconstrução de rota

(2)

(1)

Figura 4. Funcionamento do processo de rastreamento.

Ao final do processo de rastreamento, os roteadorespertencentes à rede sobreposta que fazem parte da rota deataque estão cientes disso, inclusive o SA mais próximoda origem dos pacotes de ataque. Os SAs com o sistemade rastreamento instalado que se encontram mais próxi-mos da origem dos ataques podem então iniciar procedi-mentos de filtragem para conter o ataque o mais próximopossível de sua origem, evitando assim, além do ataqueem si, também o consumo de recursos de rede para o en-caminhamento dos pacotes até a vítima. A técnica de fil-tragem a ser adotada para bloquear o ataque em curso está

66



fora do escopo deste trabalho em particular, que é focadona etapa de rastreamento de tráfego.

4. AVALIAÇÃO DO SISTEMANesta seção, é investigado o problema de posiciona-

mento do sistema de rastreamento IP proposto. Foramtestadas duas abordagens de colocação do sistema narede: (i) posicionamento estratégico, onde os SAs commaior número de conexões com outros SAs tiveram o sis-tema de rastreamento instalado primeiro; (ii) posiciona-mento aleatório, onde a instalação do sistema de rastrea-mento foi feita aleatoriamente entre SAs.A abordagem estratégica foi delineada com base em

análises feitas recentemente sobre a topologia da Inter-net [19, 27, 4], que mostram a tendência de que, con-forme a rede aumenta, novos nós se conectem a outrosnós que possuem um alto grau de conectividade. Estatendência ajuda a explicar porque a topologia da Internetpossui poucos nós com um grande número de conexões,enquanto muitos nós possuem poucas conexões. Os re-sultados de simulação confirmam que o posicionamentoestratégico do sistema proposto em um número relativa-mente reduzido de nós em uma topologia com estas carac-terísticas – similar a da Internet – é suficiente para realizarum rastreamento eficiente.

4.1. CONFIGURAÇÃO DA SIMULAÇÃOPara executar as simulações, foi usado o gerador de

topologia Nem [26] com o modelo Barabási-Albert [2] eo simulador de rede NS-2 [31] modificado pelo móduloBGP++ [17] (uma implementação do Zebra bgdp, que éuma implementação do BGP para plataformas Unix).Em todas as simulações realizadas neste trabalho,

considerou-se que vários atacantes podem estar localiza-dos no mesmo SA e que se o último SA no caminho re-verso do pacote for encontrado, significa que o atacantetambém foi encontrado, uma vez que o rastreamento den-tro do SA não pode ser realizado e que a filtragem dospacotes que partem deste SA pode ser feita.Um dos propósitos das simulações é analisar o desem-

penho da instalação parcial (e incremental) do sistemaproposto. Em outras palavras, a intenção é avaliar o com-promisso entre a quantidade de SAs com o sistema insta-lado e a acurácia no rastreamento. Para isto, foram obser-vadas características no caminho reverso dos pacotes in-dicado pelo sistema proposto, variando-se a porcentagemde instalação do sistema na rede, respeitando os dois tiposde estratégia utilizados.No posicionamento estratégico, os SAs foram classifi-

cados de acordo com a quantidade de conexões existentescom outros SAs. A ordem de instalação do sistema derastreamento respeitou esta classificação. Por outro lado,

no posicionamento aleatório, o sistema de rastreamentofoi instalado sem levar em consideração qualquer tipo declassificação. A única regra foi que um SA só poderia sersorteado para ter o sistema de rastreamento instalado umavez por rodada de simulação, de forma a garantir que aofinal de cada rodada todos os SAs possuiriam o sistemainstalado.Outro objetivo das simulações é verificar o compor-

tamento do sistema de acordo com o crescimento donúmero de atacantes. Neste caso, foi variada a quantidadede atacantes na rede, de forma a analisar a eficiência dosistema em redes com um volume diversificado de camin-hos entre as origens e o destino dos ataques, considerandoque a filtragem ou bloqueio dos pacotes deve ser feita daforma mais distribuída possível.

4.2. RESULTADOSPara as primeiras simulações, que têm como resulta-

dos os gráficos da Figura 5, da Figura 6 e da Figura 7,foram utilizadas topologias de redes no nível de SAs con-tendo 300, 600 e 900 SAs. Para cada amostra, foramsimuladas sete diferentes topologias com cinco conjun-tos aleatórios de atacantes (10% de SAs) enviando tráfegopara uma vítima, escolhida de forma aleatória para cadarodada da simulação. Os resultados das simulações pos-suem um intervalo de confiança de 99%, com valoresmédios de ±2.1% para o posicionamento estratégico e±3.8% para o posicionamento aleatório. Devido a simi-laridade que foi percebida nos resultados das simulações,mesmo com a variação do número de SAs participantes eao fato de que as topologias utilizadas preservam as carac-terísticas de serem livres de escala, acreditamos que sim-ulações com maiores quantidades de SAs também apre-sentem resultados similares.Na Figura 5 é apresentado o percentual de caminho de

ataque descoberto dependendo da quantidade de SAs darede com o sistema de rastreamento instalado. Os resulta-dos mostram que usando o posicionamento estratégico,são descobertos quase 100% do caminho reverso dosataques no nível de SAs com aproximadamente 70% dosSAs da rede com o sistema instalado. Por outro lado, paraalcançar os mesmos resultados usando o posicionamentoaleatório, o sistema deve estar instalado em quase 100%dos SAs da rede. Relaxando-se a exigência de encontrar-se todo o caminho percorrido pelo ataque, o posiciona-mento estratégico permite encontrar, por exemplo, 70%,80% e 90% da rota percorrida pelo tráfego de ataque nonível de SAs com aproximadamente 15%, 22% e 40% dosSAs com o sistema de rastreamento proposto instalado.Isto significa que com uma porção relativamente pequenados SAs possuindo o sistema proposto instalado – desdeque escolhidos estrategicamente – é possível identificar-se uma grande porção da rota no nível de SAs tomadapelos pacotes de ataque.

67



Figura 5. Descoberta do caminho de ataque.

Figura 6. Quantidade de SAs identificados – até um salto do SA do atacante.

Figura 7. Quantidade de SAs identificados – a dois saltos do SA do atacante.

68



Figura 8. Posicionamento estratégico - Descoberta do caminho do ataque de acordo com o crescimento do número de atacantes.

Figura 9. Posicionamento estratégico - Quantidade de SAs identificados – até um salto do SA do atacantes – de acordo com o crescimento do númerode atacantes.

Na Figura 6 é observado que usando o posicionamentoestratégico, para que o sistema descubra quase 100%dos SAs a 1 salto de distância do atacante, é necessárioinstalá-lo em aproximadamente 65% dos SAs da rede.Para conseguir estes resultados utilizando o posiciona-mento aleatório, aproximadamente 95% dos SAs devemter o sistema de rastreamento instalado.Na Figura 7, pode-se observar que se o sistema de

rastreamento é instalado no posicionamento estratégicoem aproximadamente 68% dos SAs da rede, aproximada-mente 100% dos SAs a 2 saltos dos atacantes são de-scobertos. Para que resultados similares sejam alcançadosno posicionamento aleatório, é necessário instalar o sis-tema de rastreamento proposto em 95% dos SAs da rede.Para as simulações que originaram os resultados dos

gráficos da Figura 8, da Figura 9, da Figura 10 e da

Figura 11 foram usadas topologias no nível de SAs com300 SAs. Para cada ponto do gráfico, foram utilizadosdez conjuntos aleatórios de atacantes extraídos de quatrotopologias diferentes, enviando pacotes para uma vítima,também escolhida de forma aleatória para cada rodada dasimulação. Nestas simulações a quantidade de atacantesutilizada foi 30, 60, 120, 180 e 240, ou seja, respectiva-mente 10%, 20%, 40%, 60% e 80% da rede. Os resul-tados das simulações possuem um intervalo de confiançade 99% com valores médios de ±3.2% e ±2.3% para osgráficos do posicionamento estratégico e±5.1% e±2.9%para os gráficos do posicionamento aleatório.

A Figura 8 se refere ao posicionamento estratégico emostra que a medida que o número de atacantes cresce, aeficiência do sistema tende a cair um pouco quando a redepossui uma porcentagem relativamente baixa de SAs com

69



Figura 10. Posicionamento aleatório - Descoberta do caminho do ataque de acordo com o crescimento do número de atacantes.

Figura 11. Posicionamento aleatório - Quantidade de SAs identificados – até um salto do SA do atacantes – de acordo com o crescimento do númerode atacantes.

o sistema instalado (entre 10% e 35%). Como exemplo,se 30% dos SAs da rede possuírem o sistema de rastrea-mento instalado e a quantidade de atacantes for 10% darede, o sistema consegue rastrear aproximadamente 86%do caminho; com 80% de atacantes na rede, é rastreadoaproximadamente 63% do caminho, ou seja, uma difer-ença de 23%. Este comportamento ocorre porque os sis-temas são instalados de forma estratégica e os atacantessão selecionados de forma aleatória. Sendo assim, a me-dida que a quantidade de atacantes na rede aumenta, al-guns atacantes podem estar mais longe dos SAs que pos-suem o sistema instalado do que outros, fazendo comque a porcentagem do caminho descoberto seja reduzida.Pode-se observar também que a medida que a quanti-dade de SAs com o sistema instalado aumenta, mesmo

que a quantidade de atacantes na rede também aumente, adiferença na porcentagem do caminho rastreado diminui,sendo praticamente igual a partir do momento que 70%dos SAs da rede possuem o sistema instalado. Isto ocorreporque mais caminhos passam a ser rastreados quando aquantidade de sistemas de rastreamento na rede aumenta.O mesmo comportamento pode ser observado na

Figura 9, que ilustra a quantidade de SAs descobertos a1 salto de distância do atacante, ainda que os caminhoscompletos dos pacotes de ataque não sejam descobertos.As Figuras 10 e 11 referem-se ao posicionamento

aleatório e mostram respectivamente a porcentagem docaminho rastreado e os SAs descobertos a 1 salto de dis-tância do atacante mesmo que o caminho completo nãoseja rastreado, dependendo da quantidade de SAs da rede

70



com o sistema instalado. O comportamento dos gráfi-cos é similar aos gráficos do posicionamento estratégico,mostrando uma certa independência quanto a eficiênciado sistema em relação ao aumento do número de ata-cantes.Os resultados das simulações sugerem que se o sis-

tema proposto for instalado estrategicamente em aprox-imadamente 45% dos SAs da rede, providências e con-tramedidas contra ataques DDoS podem ser realizadaseficientemente, já que com esta taxa de instalação do sis-tema, por volta de 90% do caminho de ataques no nívelde SAs é descoberto. Com uma taxa similar a esta, o sis-tema de rastreamento proposto pode descobrir um poucomais de 86% dos SAs a 1 salto de distância dos atacantes,além de apontar mais de 90% dos SAs a 2 saltos deles.Além disto, mesmo que uma quantidade pequena de SAstenham o sistema instalado – em torno de 25% – o pro-cesso de rastreamento pode ainda sinalizar mais de 75%do caminho reverso do ataque, mais de 78% e 82% dosSAs a 1 e 2 saltos de distância do atacantes, respecti-vamente. Estes dados sugerem que medidas eficientespodem ser tomadas de forma distribuída, uma vez quequando um atacante não é descoberto, existe uma grandechance de um SA a 2 saltos dele ter sido identificado, alémde outros SAs no caminho reverso do ataque.Pode-se concluir também, que mesmo que a quanti-

dade de atacantes na rede seja muito grande, aproximada-mente 80%, se o sistema for instalado estrategicamente,ele ainda pode rastrear uma grande quantidade de ata-cantes sem que sua eficiência seja muito comprometida.

5. CONCLUSÃONeste artigo é proposto um sistema de rastreamento

de tráfego IP no nível de SAs, que considera as carac-terísticas do protocolo de roteamento BGP, para permitira criação de uma rede sobreposta no nível de SAs, queé utilizada pelos SAs participantes do rastreamento. Éproposta a criação de um novo Community Attribute parao protocolo BGP, que é responsável por identificar qualSA possui o sistema de rastreamento IP proposto insta-lado. Estas características permitem que o sistema sejainstalado parcialmente e incrementalmente na rede, deforma independente da topologia, eliminando a necessi-dade da sua instalação em todos os roteadores da rede.Além disto, o problema da exposição da topologia internados SAs, que fazem parte das desvantagens de outros sis-temas de rastreamento também é eliminado.É proposto também um mecanismo de marcação de

sequência dos roteadores, a ser usado antes do pacoteser marcado por um roteador de borda de um SA. Estemecanismo utiliza o TTL do pacote no momento quepassa pelo roteador de borda do SA para identificar a or-

dem de passagem dos pacotes. É importante que esta or-dem seja conhecida no momento da reconstrução da rota,de forma que os roteadores que fazem parte do rastrea-mento não tenham dúvidas de qual vizinho na rede sobre-posta deve receber o pacote de reconstrução de rota.O sistema de rastreamento de tráfego proposto neste

trabalho, portanto, possui algumas vantagens quandocomparado aos trabalhos anteriores, vantagens estas quecaracterizam as contribuições da proposta.São realizadas simulações para avaliar a implemen-

tação parcial e incremental do sistema, além de seu com-portamento com o crescimento do número de atacantesna rede. Utiliza-se dois tipos de posicionamento paraavaliar o sistema: estratégico, que leva em consideraçãoa quantidade de conexões entre os SAs no momento daescolha de qual SA teria o sistema de rastreamento instal-ado primeiro; e aleatório, onde os SAs escolhidos para tero sistema instalado são simplesmente sorteados.Os resultados das simulações mostram que através do

posicionamento estratégico do sistema proposto, pode-seter informação suficiente para bloquear ou filtrar de formadistribuída ataques de larga escala – DDoS – perto de suasfontes, suavizando seus efeitos antes que os pacotes al-cancem o SA da vítima. Os resultados sugerem que taisbloqueios ou filtragens podem ser efetuadas se o sistemaproposto for instalado estrategicamente em aproximada-mente 45% dos SAs da rede, já que com esta taxa de in-stalação do sistema, aproximadamente 93% do caminhode ataques no nível de SAs é descoberto. Com uma taxasimilar a esta, o sistema de rastreamento proposto desco-bre aproximadamente 90% dos SAs a 1 salto de distânciado atacante, isto é, os SAs de onde os pacotes de ataquesão originados, além de apontar mais de 92% dos SAs a 2saltos dos atacantes. Além disto, mesmo que uma quan-tidade pequena de SAs tenham o sistema instalado – emtorno de 25% – o processo de rastreamento pode aindasinalizar mais de 78% do caminho reverso do ataque, per-mitindo que medidas eficientes sejam tomadas de formadistribuída.A instalação do sistema proposto no posicionamento

estratégico claramente apresenta melhores resultados doque no posicionamento aleatório, mostrando a tendênciade que através do conhecimento da topologia da rede,o sistema pode ser melhor posicionado, sendo mais efi-ciente em sua execução. Porém, isso não quer dizer que osistema não tem bons resultados se for instalado de formaaleatória. O conhecimento da topologia da rede influenciadiretamente na acurácia do rastreamento, mas não é umfator mandatório para a operação do sistema, conformevisto em [23].Como trabalhos futuros pretende-se estudar a possi-

bilidade de integrar o sistema proposto neste trabalhocom um sistema de rastreamento que opera no nível deroteadores. Desta forma pode-se realizar um rastreamento

71



em dois níveis, onde em um primeiro momento o SA deonde são originados os pacotes de ataque é descoberto,e em um segundo momento haja a descoberta do ata-cante dentro deste SA, aumentado assim as chances de sechegar mais perto do atacante, realizando uma filtragemainda mais eficiente.

AgradecimentosOs autores gostariam de agradecer a Timothy G.

Griffin (Universidade de Cambridge, Reino Unido), co-autor de [1], e Xenofontas Dimitropoulos (GeorgiaT-ech, EUA), co-autor de [17], por fornecerem expli-cações detalhadas respectivamente sobre a operação doCommunity Attribute do BGP e a utilização domódulo de simulação BGP++. Este trabalho foi parcial-mente financiado pela CAPES, CNPq e FAPERJ.

Referências[1] Sharad Agarwal and TimothyG. Griffin. BGP Proxy

Community Community. IETF Internet Draft, Jan-uary 2004.

[2] Reka Albert and Albert-Laszlo Barabasi. Topologyof evolving networks: local events and universality.Physical Review Letters, 85:5234, 2000.

[3] Hassan Aljifri. IP traceback: A new denial-of-service deterrent? IEEE Security and Privacy,1(3):24–31, 2003.

[4] Nilton Alves, Márcio Portes de Albuquerque,Marcelo Portes de Albuquerque, and Joaquim Teix-eira de Assis. Topologia e modelagem relacionalda Internet Brasileira. In XXVI Iberian LatinAmerican Congress on Computational Methods inEngineering- CILAMCE’05, Guarapari, Brasil, Oc-tober 2005.

[5] A. Belenky and N. Ansari. On IP traceback. IEEECommunications Magazine, 41(7), July 2003.

[6] Steve Bellovin, Marcos Leech, and Tom Taylor.ICMP Traceback messages. IETF Internet Draft,February 2003.

[7] Burton Bloom. Space/time tradeoffs in hash codingwith allowable errors. Communications of the ACM,13(7):422–426, 1970.

[8] O. Bonaventure and B. Quoitin. Common utiliza-tions of the BGP community attribute. IETF InternetDraft, June 2003.

[9] Andrei Broder andMichaelMitzenmacher. Networkapplications of Bloom filters: A survey. InternetMathematics, 1(4):485–509, 2004.

[10] André O. Castelucio, Ronaldo M. Salles, and Ar-tur Ziviani. An AS-level IP traceback system. InProceedings of the 3rd International Conference onemerging Networking EXperiments and Technolo-gies - CoNEXT’07, New York, NY, USA, December2007. Poster.

[11] André O. Castelucio, Ronaldo M. Salles, and Ar-tur Ziviani. Evaluating the partial deployment ofan AS-level IP traceback system. In Proceedings ofthe ACM Symposium on Applied Computing – ACMSAC’08, Fortaleza, Brasil, March 2008.

[12] André O. Castelucio, Ronaldo M. Salles, and Ar-tur Ziviani. Uma rede sobreposta no nível de sis-temas autônomos para rastreamento de tráfego IP.In Simpósio Brasileiro de Redes de Computadores -SBRC’08, Rio de Janeiro, Brasil, Maio 2008.

[13] CERT. CERT Advisory CA-1996-21 TCP SYNflooding and IP spoofing attacks. Technical re-port, CERT- Computer Emergency Response Team,1996.

[14] CERT. Denial of service attacks. Technical re-port, CERT- Computer Emergency Response Team,2001.

[15] R. Chandra, P. Traina, and T. Li. BGP Communi-ties Attribute. Internet Engineering Task Force. RFC1997, 1996.

[16] E. Chen and T. Bates. An Application of the BGPCommunity Attribute in Multi-home Routing. Inter-net Engineering Task Force. RFC 1998, 1996.

[17] Xenofontas Dimitropoulos, PatrickVerkaik, and George Riley. BGP++http://www.ece.gatech.edu/research/labs/MANIACS/BGP++ , 2006.

[18] Arjan Durresi, Vamsi Paruchuri, Leonard Barolli,Rajgopal Kannan, and S. Sitharama Iyengar. Ef-ficient and secure autonomous system based trace-back. Journal of Interconnection Networks,5(2):151–164, 2004.

[19] Michalis Faloutsos, Petros Faloutsos, and ChristosFaloutsos. On power-law relationships of the inter-net topology. In SIGCOMM ’99: Proceedings of theconference on Applications, technologies, architec-tures, and protocols for computer communication,pages 251–262, New York, NY, USA, 1999. ACMPress.

72



[20] Alefiya Hussain, John Heidemann, and Christos Pa-padopoulos. A framework for classifying denial ofservice attacks. In SIGCOMM ’03: Proceedings ofthe 2003 conference on Applications, technologies,architectures, and protocols for computer communi-cations, pages 99–110, New York, NY, USA, 2003.ACM Press.

[21] G. Huston. NOPEER Community for Border Gate-way Protocol (BGP) Route Scope Control. InternetEngineering Task Force. RFC 3765, 2004.

[22] ISS. Distributed denial of service attack tools. Tech-nical report, ISS- Internet Security Systems, 2000.

[23] Turgay Korkmaz, Chao Gong, Kamil Sarac, andSandra Dykes. Single packet IP traceback in AS-level partial deployment scenario. InternationalJournal of Security and Networks, 2(1/2):95–108,2007.

[24] Rafael P. Laufer, Pedro B. Velloso, Danielde O. Cunha, Igor M. Moraes, Marco D. D. Bicudo,and Otto Carlos M. B. Duarte. A new IP tracebacksystem against denial-of-service attacks. In 12thInternational Conference on Telecommunications -ICT’2005, Capetown, South Africa, May 2005.

[25] Rafael P. Laufer, Pedro B. Velloso, and Otto CarlosM. B. Duarte. Generalized bloom filters, gta-05-43.Technical report, COPPE/UFRJ, September 2005.

[26] Damien Magoni. Network manipulator. https://dpt-info.u-strasbg.fr/ magoni/nem, 2002.

[27] AlbertoMedina, IbrahimMatta, and John Byers. Onthe origin of power laws in internet topologies. SIG-COMMComput. Commun. Rev., 30(2):18–28, 2000.

[28] D. Meyer. BGP Communities for Data Collection,2006.

[29] Jelena Mirkovic and Peter Reiher. A taxonomy ofDDoS attack and DDoS defense mechanisms. SIG-COMMComput. Commun. Rev., 34(2):39–53, 2004.

[30] David Moore, Colleen Shannon, Douglas J. Brown,Geoffrey M. Voelker, and Stefan Savage. Infer-ring internet denial-of-service activity. ACM Trans.Comput. Syst., 24(2):115–139, 2006.

[31] Network Simulator 2. http://www.isi.edu/nsnam/ns,1995.

[32] NIST. Guide to Intrusion Detection and PreventionSystems - (IDPS). Technical report, NIST- NationalInstitute of Standards and Technology, 2007.

[33] B. Quoitin and O. Bonaventure. A survey of the uti-lization of the BGP community attribute. IETF In-ternet Draft, March 2002.

[34] Y. Rekhter and T. Li. A border gateway protocol 4(BGP-4). RFC 1771, March 1995.

[35] E. Rosen and Y. Rekhter. BGP/MPLS IP VirtualPrivate Networks (VPNs), 2006. Updated by RFCs4577, 4684.

[36] Stefan Savage, David Wetherall, Anna Karlin, andTom Anderson. Practical network support for IPtraceback. In Proceedings of the 2000 conference onApplications, technologies, architectures, and pro-tocols for computer communications (SIGCOMM),pages 295–306, Stockholm, Sweden, August 2000.

[37] Alex C. Snoeren, Craig Partridge, Luis A. Sanchez,Christine E. Jones, Fabrice Tchakountio, BeverlySchwartz, Stephen T. Kent, andW. Timothy Strayer.Single-packet IP traceback. IEEE/ACM Trans.Netw., 10(6):721–734, December 2002.

73

Documents

UmaRedeSobrepostanoNívelde Sistemas Autônomos para Rastreamento de ... · UmaRedeSobrepostanoNívelde Sistemas Autônomos para Rastreamento de Tráfego IP∗ André O. Castelucio