Autenticação no LDP (Label Distribution Protocol)

Transcrição

1 IEEE LATIN AMERICA TRANSACTIONS, VOL. 1, NO. 1, OCTOBER Autenticação no LDP (Label Distribution Protocol) Morvan D. Müller, Msc.; Carlos B. Westphall, Dr. e Carla M. Westphall, Dra. Resumo-- Este artigo propõe uma solução de autenticação para o protocolo LDP (Label Distribution Protocol) da arquitetura MPLS (Multiprocol Label Switch). O objetivo é autenticar, em um escopo fim a fim, o estabelecimento de um LSP (Label Switching Path) entre um LSR (Label Switching Router) de Ingresso e o seu respectivo LSR de Egresso, de modo a suprir a deficiência do protocolo LDP de não possuir um mecanismo de autenticação fim a fim definido para LSRs não-adjacentes. A solução provê autenticação, controle de integridade e proteção contra ataques de repetição. Abstract-- This article propose a solution for the LDP (Label Distribution Protocol) protocol from the MPLS (Multiprocol Label Switch) architecture. The objective is authenticate, on an end to end basis, the establishment of an LSP (Label Switching Path) between the Ingress LSR (Label Switching Router) and its Egress, to supply the LDP protocol deficiency that doesn't have one end to end authentication mechanism defined for non-adjacent LSRs. The solution provide authentication, integrity control and protection against replay attacks. Termos de Índice-- autenticação, criptografia, hash, integridade, LDP, LSP, LSR, MPLS, nonce, segurança. autenticação fim a fim para LDP, sugerida como draft (atualmente expirada) ao IETF. Através de uma análise aprofundada conclui-se a proposta apresenta um erro arquitetural, fato reconhecido pelos seus autores, por considerar erroneamente que ao enviar uma mensagem LDP solicitando um LSP para uma determinada FEC (Forward Equivalency Class), o LSR de origem (ingresso) sabe qual é olsrdedestino(egresso)quevaiprocessararequisição. Na maioria dos casos isso não é uma verdade dentro da forma padrão de operação do protocolo LDP. Dessa forma, a aplicação da solução fica drasticamente reduzido, podendo ser aplicada apenas a uma minoria de casos no LDP, onde o LSR de ingresso sabe antes de requisitar o LSP quem será o LSR egresso para a FEC. [3] aborda a segurança do MPLS e levanta a problemática da autenticação fim a fim no estabelecimento de LSPs no LDP. [15] descreve uma solução que depende da confiabilidade dos LSPs criados entre LSRs não-adjacentes no LDP. [7] sugere uma arquitetura (S-BGP) para o BGP (Border Gateway Protocol) e compara com outras soluções de segurança para o BGP, que inclui a autenticação TCP baseada em MD5 [5], definida para o LDP na RFC I. NOMENCLATURA FEC (Forward Equivalency Class), LDP (Label Distribution Protocol), LER (Label Egress Router), LIB (Label Information Base), LSP (Label Switching Path), LSR (Label Switching Router), MPLS (Multiprotocol Label Switching), TLV (Type-Length-Value). M II. INTRODUÇÃO PLS (Multiprotocol Label Switching), RFC 3031 [13], é uma técnica de comutação de pacotes baseada em etiquetas (labels). O protocolo LDP (Label Distribution Protocol) é responsável pela distribuição dessas etiquetas e pelo estabelecimento dos caminhos lógicos, LSPs (Label Switched Paths) no MPLS. Uma lacuna na segurança do LDP pode comprometer todo o ambiente MPLS, pois a distribuição das etiquetas realizada pelo LDP é o que determina quem pode participar ou não do domínio MPLS. Existe uma autenticação definida para o LDP [2] baseada em TCP/MD5 [5], porém a mesma é restrita a LSRs adjacentes pois depende de uma conexão TCP estabelecida entre os LSRs envolvidos. No caso de LSPs entre LSRs não-adjacentes, especialmente durante o estabelecimento do primeiro LSP, não existe uma conexão TCP fim a fim entre estes LSRs. A. Trabalhos Correlatos Os autores de [4] descrevem uma proposta de III. A SOLUÇÃO DE AUTENTICAÇÃO FIM A FIM PARA O LDP A solução proposta faz uso de um mecanismo de autenticação baseado em criptografia assimétrica (chave pública e privada), anexado as mensagens LDP, o que possibilita ao LSR receptor verificar e autenticar o emissor das mensagens. Provê integridade às informações através de um mecanismo de resumo de mensagens (hash) e adicionalmente protege contra ataques de repetição através da inserção de um nonce as mensagens LDP. A solução não prove confidencialidade aos dados e foi planejada para ambientes onde LSPs atravessam múltiplos domínios externos, não confiáveis entre si, que por esse motivo necessitam de uma forma para autenticar as extremidades do LSP durante o seu estabelecimento. Como requisito a solução exige que o LDP esteja operando no modo de controle Ordenado, ou seja, é incompatível com o modo de controle Independente. Quanto aos modos de distribuição do LDP, "Sob Demanda" e "Não Solicitado", ambos são compatíveis com a solução proposta. A. Estabelecimento de um LSP entre LSRs Não-adjacentes Esta seção explica como o protocolo LDP opera para estabelecer um LSP entre dois LSRs não-adjacentes LERA elerb(fig.1)econtextualizaaaplicaçãodasolução deste trabalho. Considere o LDP operando no modo de distribuição Sob Demanda e no modo de controle Ordenado. Via informações de roteamento IP o LERA

2 58 IEEE LATIN AMERICA TRANSACTIONS, VOL. 1, NO. 1, OCTOBER 2003 conhece o prefixo de endereços IP ( /8) que está "atrás" do LERB e deseja criar um LSP para esta FEC. Nesta rede MPLS, LERA e LERB são respectivamente, Ingresso e Egresso do LSP para a FEC /8 e são LSRs não-adjacentes entre si. LERA e LSR1, LSR1 e LSRN, LSRN e LERB são LSRs adjacentes entre si. 1 LabelRequest Label=? Consultar Tabela 2 Manter Request LabelRequest Label=? Consultar Tabela 3 Manter Request LabelRequest Label=? 7 LER A LSR 1 LSR N LER B Sessão LDP Sessão LDP Sessão LDP LabelMap Label = L3 TCP Atribuir Label 6 LabelMap Label = L2 TCP Atribuir Label 5 TCP LabelMap Label = L1 Fig. 1. Estabelecimento de um LSP entre LSRs Não-adjacentes 4 Atribuir Label Quando o LDP é iniciado, em duas etapas são estabelecidas primeiro conexões TCP e em seguida sessões LDP sobre as conexões TCP, entre os LSRs ADJACENTES, fazendo com que se tornem pares LDP e entrem na "fase ativa do LDP" onde é possível realizar operações com etiquetas MPLS. Após esta fase o LERA pode solicitar o LSP para a FEC /8: a) no passo 1, (sobre a sessão TCP/LDP entre o LERA e o LSR1) o LERA envia um LABEL REQUEST para o LSR1 (next-hop para a rota /8 extraído da sua tabela IP) solicitando uma etiqueta (label) para a FEC /8; b) No passo 2, O LSR1 faz uma consulta em sua tabela de etiquetas local (LIB - Label Information Base) e percebe que não possui uma etiqueta para esta FEC. O LSR1 então altera o status da requisição recebida para "pendente" e baseado nesta requisição codifica e envia uma nova mensagem LDP LABEL REQUEST para o seu par adjacente LSRN, solicitando uma etiqueta para a FEC /8 (sobre a sessão TCP entre o LSR1 e o LSRN). O mesmo ocorre entre o LSRN e o LERB (sobre a sessão TCP entre ambos) no passo 3. c) No passo 4, O LERB reconhece a FEC /8 e percebe que é o LSR de egresso para o LSP em relação a esta FEC. Então gera uma etiqueta L1 para a FEC /8 e envia um LABEL MAPPING para o LSRN, informando esta etiqueta (sobre a sessão TCP/LDP entre o LERB e o LSRN). d) No passo 5, o LSRN insere a etiqueta recebida em sua LIB e percebe que possui uma requisição pendente para a FEC originada pelo LSR1. Então gera e envia a etiqueta L2 para o LSR1 através de um LABEL MAPPING (sobre a sessão TCP/LDP entre o LSRN e o LSR1). No passo 6, entre o LSR1 e o LERA (etiqueta L3) ocorre o mesmo. Quando o LERA recebe a etiqueta (L3) do LSR1 percebe que é o LSR de ingresso para a FEC e neste ponto o LSP é estabelecido entre o LERA e o LERB (passo 7). A partir deste ponto a FEC /8 está mapeada para o LSP criado e todos pacotes com destino a endereços do prefixo /8 serão roteados através através do MPLS, usando etiquetas e não mais através do roteamento IP, da camada de rede. O que a atual forma de autenticação definida para o LDP na RFC 3036, baseada em TCP/MD5 nos oferece é que, por exemplo, o LERB pode autenticar a etiqueta L1 em relação ao seu par adjacente LSRN, ou seja, apenas permite autenticar um LSR adjacente, pois depende de uma sessão TCP/LDP direta entre eles. Entre o LERA e o LERB, no momento do estabelecimento do primeiro LSP, não existe uma sessão TCP/LDP fim a fim estabelecida, assim a solução da RFC 3036 não se aplica. B. TLVs e Tipos Definidos ao LDP pela Solução de Autenticação Foram definidos dois novos TLVs (Type-Length-Value) ao LDP para prover a autenticação: "TLV de Nonce" e "TLV de Hash", e um novo "Código de Status" com o valor "Authentication Failed" para o TLV de Status do LDP, usado nas mensagens LDP Notification para anunciar que um Mapping ou Request falhou na autenticação. Os TLVs da autenticação são inseridos (no envio de mensagens) e processados (no recebimento de mensagens) apenas em mensagens do tipo LABEL MAPPING, LABEL REQUEST ou LDP NOTIFICATION, se o LSR estiver na condição de EGRESSO ou INGRESSO para a(s) FEC(s) da mensagem LDP. Nos LSRs INTERMEDIÁRIOS os TLVs da autenticação são repassados ao próximo LSR (next hop), mantendo a ordem da mensagem original. 1) TLV de Hash Fig. 2. TLV de Hash Este TLV transporta hash cifrado. U-bit e F-bit: (1 bit cada) Atribuído em "1" indica ao LDP que ignore este TLV se o mesmo não for reconhecido e o repasse para o próximo LSR do caminho. Hash: (14 bits) Este campo define o tipo do TLV, "TLV de Hash". Length: (2 bytes)

3 MULLER et al.: AUTHENTICATION ON LDP (LABEL 59 indica o tamanho total em bytes dos seguintes campos: LSR Identifier: (6 bytes) identifica o LSR que originou a mensagem LDP, composto pelo LSR-ID (Identificador do LSR) e pelo espaço de etiquetas em uso pelo LSR. Hash Digest: (20 bytes) contém um valor hash gerado a partir de uma mensagem LDP, cifrado com a chave privada do LSR remetente. Na definição do tamanho deste campo foram considerados os algoritmos de hash (sha-1/160 bits) e de criptografia assimétrica "Curvas Elípticas", discutido na seção G. 2) TLV de Nonce Fig. 3. TLV de Nonce Este TLV transporta um valor nonce. U-bit e F-bit seguem a mesma descrição do TLV de hash. Nonce: (14 bits) Este campo define o tipo do TLV, "TLV de Nonce". Length: (2 bytes) indica o tamanho em bytes do campo Nonce Value. Nonce Value: (8 bytes) armazena um valor nonce usado para detectar ataques de repetição. C. Modelo de Autenticação Proposto Considerando o mesmo cenário ilustrado na (Fig. 1), onde o LERA deseja criar um LSP para a FEC /8, a (Fig. 4) ilustra o cenário onde o LERB (EGRESSO) autentica positivamente a requisição LDP (Label Request) enviada pelo LERA (INGRESSO) e retorna uma mensagem LDP (Label Mapping) autenticada ao LERA, utilizando a solução de autenticação fim a fim. LER A Request LDP Assinado Mapping LDP Assinado LSR 1 LSR N LER B Request LDP Assinado Mapping LDP Assinado Fig. 4. Diagrama da autenticação fim a fim. Para SOLICITAR o LSP aplicando a autenticação fim a fim, o LERA executa os seguintes passos: a) codifica uma mensagem LDP LABEL REQUEST solicitando uma etiqueta para a FEC /8, cuja rota de destino é conhecida via seu roteamento IP; b) gera um valor nonce, codifica o TLV de Nonce (Fig. 3) e anexa o mesmo ao final da mensagem LDP. c) codifica o TLV de Hash (Fig. 2) baseado no conteúdo da mensagem LDP. No campo "LSR Identifier", o LERA insere o seu LSR-ID e o espaço de etiquetas (labels) que está usando. Codifica o campo Hash Digest que depende do tipo da mensagem LDP. Para mensagens LABEL REQUEST e LABEL MAPPING a entrada de dados é formada por um string de bytes conforme a (Fig. 5) e para mensagens LDP NOTIFICATION uma string de bytes conforme a (Fig. 6) Fig. 5. Entradas do hash para mensagens LDP LABEL REQUEST e LABEL MAPPING Fig. 6. Entrada do hash para mensagens LDP NOTIFICATION Como o LERA esta enviando uma mensagem LABEL REQUEST, forma uma cadeia de bytes conforme citado na Fig. 5 e aplicada uma função hash (esta proposta considera o algoritmo sha-1/160 bits ) sobre estes dados. Sobre o resultado da função hash aplica um algoritmo de criptografia assimétrica (esta proposta considera o algoritmo de Curvas Elípticas ) usando a sua (LERA) chave privada para a cifragem. O resultado destas operações forma o valor do campo Hash Digest. Então o LERA anexa o TLV de Hash ao final da mensagem LDP e a partir desse passo a mensagem esta pronta para ser enviada. d) o LERA envia a mensagem LDP ao próximo LSR do caminho LSR1 (next hop), descoberto via informações do roteamento IP; Os LSRs INTERMEDIÁRIOS do caminho não podem atender a requisição solicitada (não possuem uma etiqueta para a FEC e não são Ingresso ou Egresso para a FEC), assim repassam os campos da autenticação transparentemente até que cheguem a algum LSR que possa atendê-la, neste caso o LER B, pois o mesmo é o LSR de EGRESSO para a FEC solicitada. Quando o LERB recebe a requisição LDP verifica que é o EGRESSO para a FEC então deve processar os TLVs da autenticação. Para PROCESSAR os Tlvs da autenticação fim a fim o LERB executa os seguintes passos: a) identifica que o LERA é o emissor examinando o campo "LSR Identifier" do TLV de Hash; b) verifica em sua configuração local se este LSR (LERA) está autorizado a estabelecer LSPs, e em caso positivo seleciona a chave pública do LERA. (As chaves públicas dos LSRs autorizados são informadas via configuração local nos LSRs do ambiente); c) decifra/valida o campo "Hash Digest", do TLV de Hash recebido, usando a chave pública do remetente (LERA). Caso obter sucesso significa que o remetente é AUTÊNTICO; d) nos mesmos moldes do LERA (Fig. 5), o LERB gera um hash sobre a mensagem recebida e compara com o valor do campo "Hash Digest", do TLV de Hash recebido, assim pode verificar se mensagem recebida está ÍNTEGRA; e) o valor do campo nonce recebido do LERA no campo "Nonce Value", do TLV de Nonce, deve ser copiado e retornado na mensagem Label Mapping de resposta para confirmar ao emissor (LERA) que esta resposta é uma informação nova referente a um pedido feito por ele.

4 60 IEEE LATIN AMERICA TRANSACTIONS, VOL. 1, NO. 1, OCTOBER 2003 Se a autenticação ocorrer com sucesso, o LERB gera uma mensagem LDP LABEL MAPPING, incluindo os TLVS de autenticação nos mesmos moldes do LERA, atribui uma etiqueta MPLS a FEC solicitada e envia a mensagem de volta, a qual será encaminhada ao LERA através dos LSRs intermediários com o status de requisição pendente em relação a FEC. Se a autenticação falhar, uma mensagem de notificação (LDP NOTIFICATION) com o código de status Authentication Failed será enviada em resposta para reportar a falha de autenticação (esta notificação opcionalmente também pode ser autenticada). Para codificar a mensagem de resposta (Label Mapping), o LERB executa os mesmos passos que o LERA, porém ao invés de gerar um novo nonce, apenas devolve o nonce recebido na mensagem Label Request, gera um hash da mensagem, cifra-o com a sua chave privada (LERB) e envia a resposta. A resposta é encaminhada através dos LSRs intermediários, os quais geram um par de etiquetas (entrada/saída) a cada hop, até alcançar o LERA. Este por sua vez detecta que é o LSR de INGRESSO para FEC da mensagem ( /8) e procede a autenticação do LERB. Para isso verifica se o LERB está autorizado a estabelecer LSPs, verifica a autenticidade do remetente e a integridade da mensagem recebida. Para averiguar que a resposta é nova e não uma ataque de repetição, o nonce recebido deve corresponder a um nonce que foi associado a uma requisição gerada pelo LERA. Para inferir um controle de tempo vida máximo para o nonce, o LERA pode gerar um timestamp no recebimento da resposta e comparar com o timestamp que foi associado ao nonce na requisição. Se o tempo de vida ultrapassou a um valor controlado vida política do LSR ele pode decidir descartar a resposta. Baseado no resultado da autenticação o LERA finalmente cria/estabelece ou não o LSP com o LERB. Observe, através dos cenários ilustrados (Fig. 3 e 4), que quando o LERA solicita o LSP, os dados por ele conhecidos são: a FEC ( /8) para a qual pretende criar um LSP e o IP do próximo LSR no caminho (next hop) para esta FEC, informações que obteve da sua tabela IP. Ele não sabe quem será o LSR de egresso do domínio MPLS para esta FEC. Observe também que as mensagens LABEL REQUEST e LABEL MAPPING que criam o LSP, são trocadas via roteamento IP (camada de rede). Somente após o estabelecimento do LSP que os pacotes subseqüentes serão roteados via MPLS, através das etiquetas (labels) geradas pelo LDP. IV. MECANISMOS ADOTADOS PARA PROVER A SOLUÇÃO DE A. Controle de Autorização AUTENTICAÇÃO Cada LSR que implementa a autenticação fim a fim possui em sua configuração local uma lista de controle de acesso a qual contém o LSR-ID e a chave pública correspondente dos LSRs autorizados a estabelecer LSPs com este LSR. O LSR só aceita mensagens LDP (Label Request, Label Mapping ou LDP Notification) de LSRs autorizados e que se autenticarem positivamente frente a ele. B. Autenticação da Origem O emissor cifra o campo "Hash Digest" do TLV de Hash usando a sua chave privada e anexa seu LSR-ID no campo "LSR Identifier". Com base nesse campo "LSR Identifier" o receptor da mensagem pode selecionar a chave pública correspondente ao emissor (a qual deve estar inserida um sua lista de controle de autorização) e decifrar o valor hash recebido. Se conseguir decifrar/validar a mensagem com sucesso, comprova que o emissor é autêntico. C. Integridade das Mensagens O emissor codifica a mensagem LDP e gera um resumo (hash) da mesma. Este valor hash é inserido no campo "Hash Digest" do TLV de Hash. O receptor executa o mesmo procedimento sobre a mensagem recebida e compara com o valor hash recebido do emissor. O valor hash não pode ser alterado durante a comunicação, pois o mesmo está cifrado com a chave privada do emissor. D. Controle contra Ataques de Repetição O mecanismo de controle contra ataques de repetição é provido através de um valor nonce, que é inserido na mensagem LDP pelo emissor dentro do campo "Nonce Value" do TLV de Nonce. Uma vez que o TLV de Nonce está incluso no hash da mensagem (campo Hash Digest do TLV de Hash), ele não pode ser modificado durante a comunicação. O nonce é um controle que o emissor adota para verificar se a resposta (Label Mapping) que ele está recebendo é nova referente a uma requisição (Label Request) que ele gerou e não uma repetição de uma resposta anteriormente já recebida. Existem várias formas de implementar mecanismos de nonce [1], dessa forma preferiu-se não definir um mecanismo específico Na implementação do protótipo em linux adotou-se o seguinte mecanismo de nonce: o LSR requisitante (Label Request) gera um número aleatório grande (64bits) e associa um timestamp a este nonce, o receptor quando responde (Label Mapping) apenas copia e insere o nonce recebido na requisição em sua resposta. Quando o requisitante recebe a resposta, para averiguar que a resposta é nova e não uma ataque de repetição, o nonce recebido deve corresponder a um nonce que foi associado a uma requisição pendente do LSR requisitante. Para inferir um controle de tempo vida máximo para o nonce, o LSR gerar um novo timestamp no recebimento da resposta e comparar com o timestamp que foi associado ao nonce na requisição. Através de um tempo de vida máximo controlado via política local do LSR, este pode decidir descartar a resposta por considerar a mesma muito antiga. E. Distribuição de Chaves Como a solução é baseada em criptografia assimétrica, cada LSR envolvido precisa gerar e conhecer seu próprio par de chaves (pública e privada) e ambas as entidades LSR das extremidades do LSP (Ingresso e Egresso), que desejam se comunicar, devem conhecer a chave pública do LSR da extremidade oposta e inseri-la em sua lista de controle de autorização dessa forma autorizando que este LSR possa estabelecer LSPs. Sugere-se duas alternativas para distribuir as chaves públicas no ambiente: a) Distribuição Manual -

5 MULLER et al.: AUTHENTICATION ON LDP (LABEL 61 informar as chaves públicas dos LSRs autorizados manualmente na configuração local de cada LSR. Na implementação em Linux desta proposta foi adotada esta solução de distribuição de chaves. b) Distribuição de chaves usando Certificação Digital esta solução está descrita em [9] e não será abordada neste documento. F. Discussão sobre o Método de Autenticação Adotado O método de autenticação adotado foi baseado em criptografia de chave pública por dois motivos: a) ao solicitar um LSP para uma FEC o LSR requisitante não sabe quem será o Ingresso (em caso de Label Mapping) ou Egresso (em no caso de Label Request), ou seja, não conhece o destinatário final.. A criptografia de chave pública resolveu essa problemática pois de posse da chave pública do LSRs autorizados, mantida na lista de controle de autorização em cada LSR, o LSR receptor pode verificar a assinatura do LSR remetente. b) como o MPLS objetiva comutação rápida e alto desempenho, procurou-se evitar uma troca de mensagens adicional/inicial apenas para negociação de chaves de sessão e algoritmos para a autenticação, o que faria dobrar o tempo de estabelecimento do LSP. A solução adotada utiliza campos de controle ( TLV de Hash e TLV de Nonce ) de carona nas mensagens Label Request ou Label Mapping que o LDP usa para criar o LSP, assim não introduz mensagens adicionais para prover a autenticação. G. Algoritmos de Função Hash e Criptografia Assimétrica Recomendados 1) Algoritmos de função Hash Para função hash, sugere-se como o mais apropriado o algoritmo SHA-1 (Secure Hash Algorithm) [14], com digest de 160 bits. O algoritmo gera como saída uma string com 20 bytes de tamanho. O SHA-1 é um padrão difundido e atualmente considerado aceitável quanto aos padrões de segurança. Uma alternativa para ganho de desempenho, não muito significativa, é a utilização do algoritmo MD5 para a função hash, pois como o valor hash fica cifrado durante a transmissão, a segurança fornecida pela função hash quase não é exigida. Para implementações futuras sugere-se uma análise dos algoritmos SHA-256 e SHA-512 [10]. 2) Algoritmos de Criptografia Assimétrica Para as funções de criptografia assimétrica sugere-se o algoritmo Curvas Elípticas [14] como o mais indicado para a solução. O objetivo é gerar o mínimo overhead possível ao protocolo LDP. O algoritmo de Curvas Elípticas é rápido e trabalha com blocos pequenos, dessa forma é favorável ao ambiente da solução. Considerando que a entrada será uma string com 20 bytes de tamanho, resultado da aplicação do algoritmo SHA-1/160 bits como função hash, o resultado da função de criptografia assimétrica aplicando o algoritmo de Curvas Elípticas será uma string com o mesmo tamanho da entrada, ou seja, 20 bytes. A principal vantagem é que ele não acrescenta overhead na criptografia. H. Implementação do Protótipo em Linux Foi realizada a implementação de um protótipo da autenticação fim a fim descrita neste trabalho, utilizando um projeto de código fonte aberto que implementa o LDP e MPLS na plataforma linux. O projeto utilizado foi o MPLS for Linux ( [8] o qual está vinculado ao grupo "source forge" ( Este projeto está subdividido em dois módulos principais MPLS-LINUX, que implementa o MPLS no kernel do linux, e LDP-PORTABLE, que implementa as funcionalidades do LDP. No módulo LDP-PORTABLE foi inserido o código necessário para implementar as funcionalidades da autenticação fim a fim apresentada neste trabalho. A linguagem de programação utilizada foi o "C ANSI" (compilador gcc) e manteve-se a mesma interface original do módulo LDP-PORTABLE. As versões das ferramentas utilizadas na implementação do protótipo foram: Linux RedHat 7.2, linux kernel , LDP-PORTABLE (versão 0.200), MPLS-LINUX (versão 1.170) e ZEBRA (versão 0.96) [16]. Maiores detalhes a respeito da implementação estão descritos em [9]. V. CONCLUSÃO A solução apresentada traz incrementos importantes com relação à segurança do LDP. Uma forma de autenticação fim a fim, para viabilizar a autenticação mútua entre os LSRs de Ingresso e Egresso durante o estabelecimento de um novo LSP é de fundamental importância para a segurança LDP, principalmente em ambientes MPLS multi-domínio onde os domínios não são confiáveis entre si. Um exemplo clássico de ambiente multi-domínio MPLS é o provimento de VPNs baseadas em BGP/MPLS onde vários provedores VPN fornecem o serviço VPN a um cliente baseados em acordos (SLA s) que possuem entre si [11][12]. A solução apresentada possui um escopo de aplicação genérico e abrangente dentro do LDP. Como perspectivas futuras, sugere se avaliar vantagens e desvantagens em prover confidencialidade as informações transportadas pelo protocolo LDP.. VI. AGRADECIMENTOS Agracedemos aos autores de [4] pelas contribuições prestadas em seu trabalho, especialmente ao autor Jeremy De Clercq da Alcatel Networks, pelas discussões técnicas mantidas por . VII. REFERÊNCIAS BIBLIOGRÁFICAS [1] ABADI, M.; NEEDHAM, R. Prudent Engineering. Practice for Cryptographic Protocols (1996). IEEE Transactions on Software Engineering, v. 22, n. 1, p Disponível: [2] ANDERSSON, L.; Doolan, P., Feldman, N., et al. (2001) LDP Specification. RFC 3036, Janeiro. Disponível: [3] BUDA, G.; CHOI, D.; et. al.. Security Standards for the Global Information Grid. IFIP/IEEE International Symposium on Integrated Network Management, Seatle, Maio, [4] DE CLERCQ, J.; PARIDAENS, O.; T'JOENSET Y., SCHRIJVER, P. End to End Authentication for LDP. Draft-schrijvp-mpls-ldp-endto-end-auth-03.txt, (Cópia Disponível: Draft do IETF expirada cf.: Contatos com o Autor: jeremy.de_clercq@alcatel.be).

6 62 IEEE LATIN AMERICA TRANSACTIONS, VOL. 1, NO. 1, OCTOBER 2003 [5] HEFFERNAN, A. Protection of BGP Sessions via the TCP MD5 Signature Option. RFC 2385, Agosto, Disponível: [6] JAMOUSSI, B, et al. Constraint-Based LSP Setup using LDP. RFC 3212, Janeiro, Disponível: [7] KENT, S.; LYNN, C.; SEO, K. Secure Border Gateway Protocol (S- BGP). IEEE Journal on Selected Areas In Communications, VOL. 18, NO. 4, Abril, [8] LEU, J; et. al. (2000) Project: MPLS for Linux. Grupo Source Forge, Novembro, Disponível: (Trabalho em progresso). [9] MÜLLER, M. "Uma Solução de Autenticação Fim a Fim para o LDP (Label Distribution Protocol)". Dissertação de Mestrado, Universidade Federal de Santa Catarina (UFSC), Centro Tecnológico (CTC), Florianópolis-SC, Brasil, Dezembro, [10] NIST - National Institute for Standards and Technology. Descriptions of SHA-256, SHA-384, and SHA-512. Outubro, Disponível: pdf [11] ROSEN, E.; REKHTER, Y. BGP/MPLS VPNs. RFC 2547, Março, Disponível: [12] ROSEN, E.; REKHTER, Y. BGP/MPLS VPNs. Draft-ietf-ppvpnrfc2547bis-02, julho, Disponível: [13] ROSEN, E; VISWANATHAN, A.; CALLON, R. Multiprotocol Label Switching Architecture. RFC 3031, Janeiro, Disponível: [14] STALLINGS, William. Cryptography and Network Security: Principles and Pratice. New Jersey, editora Prentice-Hall, Inc., 2ª ed., [15] WU, Chun-Te; LIU,Huey-Ing; et. al. Supporting Virtual Private Dial-Up Services Over Label Switching Based Networks. IEEE/IFIP Network Operation and Management Symposium, Hawai, Maio, [16] ZEBRA versão 0.96 ( LDP-PORTABLE versão ( MPLS-LINUX versão ( tar.gz?download). Computação da Universidade Federal de Santa Catarina. Seus interesses de pesquisa são Segurança em Sistemas Distribuídos, Modelos de Controle de Acesso e Autorização Distribuída. VIII. BIOGRAFIA Morvan D. Müller: Nascido em Santa Cruz do Sul, Brasil, em 14 de abril, Graduado em Ciência da Computação pela Universidade de Santa Cruz do Sul, em 1988 e Mestre (Segurança de Redes) pela Universidade Federal de Santa Catarina, em No momento auta como administrador de redes na empresa Softplan Cia. Ltda (Desenvolvimento de Software). Seus principais campos de interesse são Soluções de Redes e Segurança. Carlos Becker Westphall: Graduado em Engenharia Elétrica em 1985 e Mestre em 1988, ambos pela Universidade Federal do Riogrande do Sul, Brasil. Doutor em Ciência da Computação (Gerência de Redes) pela Universidade Paul Sabatier University, França, em No presente ele é professor do Departamento de Ciência da Computação da Universidade Federal de Santa Catarina, onde é Responsável pelo Laboratório de Gerência de Redes. Carla Merkle Westphall: Graduada em Ciência da Computação em 1994 e Mestre em Ciência da Computação (Sistemas de Computação) em 1996, ambos pela Universidade Federal de Santa Catarina. Doutora em Engenharia Elétrica, área de Segurança em Sistemas Distribuídos, pela Universidade Federal de Santa Catarina (UFSC-PGEEL), em No momento ela é professora do Departamento de Ciência da Computação da Universidade do Vale do Itajaí (UNIVALI), atuando no curso de graduação. Também atua no Curso de Pós-Graduação em Ciência da