BRPI0410612B1 - método de remeter pacotes de protocolo de internet, roteador de acesso para uso em uma rede de acesso comutada por pacote, e, nó móvel para uso no método - Google Patents

método de remeter pacotes de protocolo de internet, roteador de acesso para uso em uma rede de acesso comutada por pacote, e, nó móvel para uso no método Download PDF

Info

Publication number
BRPI0410612B1
BRPI0410612B1 BRPI0410612A BRPI0410612A BRPI0410612B1 BR PI0410612 B1 BRPI0410612 B1 BR PI0410612B1 BR PI0410612 A BRPI0410612 A BR PI0410612A BR PI0410612 A BRPI0410612 A BR PI0410612A BR PI0410612 B1 BRPI0410612 B1 BR PI0410612B1
Authority
BR
Brazil
Prior art keywords
access router
mobile node
address
new
care
Prior art date
Application number
BRPI0410612A
Other languages
English (en)
Inventor
Arkko Jari
Kikander Pekka
Original Assignee
ERICSSON TELEFON AB L M (publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ERICSSON TELEFON AB L M (publ) filed Critical ERICSSON TELEFON AB L M (publ)
Publication of BRPI0410612A publication Critical patent/BRPI0410612A/pt
Publication of BRPI0410612B1 publication Critical patent/BRPI0410612B1/pt
Publication of BRPI0410612B8 publication Critical patent/BRPI0410612B8/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0011Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0016Hand-off preparation specially adapted for end-to-end data sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/02Communication route or path selection, e.g. power-based or shortest path routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/02Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/34Modification of an existing route
    • H04W40/36Modification of an existing route due to handover
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Abstract

"método de remeter pacotes de protocolo de internet, roteador de acesso para uso em uma rede de acesso comutada por pacote, e, nó móvel para uso no método". um método de remeter pacotes de ip, enviados para um cuidado de endereço antigo de um nó móvel, ao nó móvel seguindo uma transferência de passagem do nó móvel de um primeiro roteador de acesso antigo para um segundo novo roteador de acesso. o método inclui, antes de conclusão de dita transferência de passagem, prover dito primeiro roteador ou outro nó de procuração com informação necessária para determinar o novo cuidado de endereço de ip a ser usado pelo nó móvel quando o nó móvel é transferido ao segundo roteador de acesso. em dito primeiro roteador ou dito nó de procuração, o novo cuidado de endereço para o nó móvel é determinado usando dita informação e propriedade do novo cuidado de endereço pelo nó móvel confirmado, e subseqüentemente, pacotes recebidos em dita primeira rede de acesso e destinados para dito cuidado de endereço antigo são remetidos ao endereço de cuidado de endereço predito.

Description

“MÉTODO DE REMETER PACOTES DE PROTOCOLO DE INTERNET, ROTEADOR DE ACESSO PARA USO EM UMA REDE DE ACESSO COMUTADA POR PACOTE, E, NÓ MÓVEL PARA USO NO MÉTODO” Campo da Invenção A presente invenção relaciona-se a mecanismos de transferência de passagem rápida para terminais móveis dentro de uma rede de acesso comutada por pacote.
Fundamento da Invenção No protocolo de IPv6 Móvel (padronizado pelo IETF), um nó móvel em trânsito é responsável por informar a seu agente doméstico e nós correspondentes seu cuidado de endereço atual. Sempre que um nó móvel muda seu cuidado de endereço, ele envia uma mensagem de Atualização de Ligação para seu agente doméstico, executa um procedimento de Dirigibilidade de Retomo com os nós correspondentes, e envia fmalmente Atualizações de Ligação aos nós correspondentes. Durante o tempo quando o nó móvel já se moveu, mas as ligações não foram atualizadas, pacotes destinados para o nó móvel continuam a serem entregues ao cuidado de endereço antigo e são perdidos de modo prefixado.
Em uma situação típica, o nó móvel, o agente doméstico e/ou os nós correspondentes (pelo menos alguns) podem estar longe um do outro, por exemplo em continentes deferentes. Conseqüentemente, a latência de comunicação entre os nós pode ser alta, tipicamente pelo menos dezenas de milissegundos e freqüentemente na ordem de 100 ms ou mais. Devido ao procedimento de Dirigibilidade de Retomo, leva 1,5 vezes a viagem de ida e volta para atualizar a ligação nos nós correspondentes, e pelo menos 0,5 vezes a viagem de ida e volta para atualizar a ligação no agente doméstico. Dadas estas latências, o atraso em atualizar as ligações pode ser até algumas centenas de milissegundos ou até mais tempo. Enquanto um tal atraso e perda de pacote podem ser bem aceitáveis para algumas aplicações, é claramente inaceitável para outras tais como multimídia de conversação e outras aplicações em tempo real.
Para superar o problema de perda de pacote, é possível remeter os pacotes destinados para o cuidado de endereço antigo ao novo cuidado de endereço. Esta função pode ser executada pelo roteador prefixado prévio do nó móvel. Um modo possível de estabelecer o procedimento de remessa é especificado pelo Grupo de Trabalho de IP móvel de IETF [Koodli, R., "Fast Handovers for Mobile IPv6, draft-ietf-mobileip-fast-mipv6-06 (trabalho em progresso), março de 2003]. Remessa de pacote pode ser estabelecida antes que a transferência de passagem ocorra, mas só se o nó móvel souber a identidade do novo roteador de acesso e for capaz de passar um identificador correspondente ao roteador prefixado prévio. Caso contrário, a remessa deve ser estabelecida depois de transferência de passagem e é provável resultar em alguma perda de pacote.
Qualquer solução para este problema deve ser segura e simples. Criação de estado deveria ser evitada onde já possível como, entre outras desvantagens, criar estados na rede é sempre um risco de segurança potencial. Qualquer solução também deve ser graduável. Infra-estruturas de segurança explícitas, tais como AAA ou PKI deveríam ser evitadas, desde que estas são prováveis de criar gargalos de capacidade de graduação.
Sumário da presente invenção De acordo com um primeiro aspecto da presente invenção, é provido um método de remeter pacotes de IP, enviados para um cuidado de endereço antigo de um nó móvel, para o nó móvel seguindo uma transferência de passagem do nó móvel de um primeiro roteador de acesso antigo para um segundo novo roteador de acesso, o método incluindo: antes de conclusão de dita transferência de passagem, prover dito primeiro roteador ou outro nó de procuração com informação necessária para determinar o novo cuidado de endereço de IP a ser usado pelo nó móvel quando o nó móvel é transferido ao segundo roteador de acesso > em dito primeiro roteador ou dito nó de procuração, determinar o novo cuidado de endereço para o nó móvel usando dita informação, e confirmar a propriedade do novo cuidado de endereço pelo nó móvel; e remeter subsequentemente pacotes recebidos em dita primeira rede de acesso e destinados para dito cuidado de endereço antigo, para o endereço de cuidado de endereço predito.
Onde um nó de procuração está envolvido, isto pode atuar como um procurador de nível de Protocolo de Internet para o nó móvel, fazendo dito primeiro roteador de acesso acreditar que o nó móvel ainda não se moveu.
Preferivelmente, dita etapa de determinar um novo cuidado de endereço para o nó móvel inclui predizer esse endereço na base de um ou mais componentes. Dita etapa de predizer o novo cuidado de endereço é executada em resposta ao nó móvel notificar o primeiro roteador ou nó de procuração que se moveu ou está prestes a se mover, o nó móvel enviando a notificação ao primeiro roteador de acesso da ligação conectada ao roteador de acesso antigo. Altemativamente, o nó móvel pode enviar a notificação ao primeiro roteador de acesso da ligação conectada ao segundo roteador de acesso. O primeiro roteador de acesso ou nó de procuração pode confirmar a oportunidade de dita notificação antes de remeter pacotes ao novo cuidado de endereço. Isto inclui determinar a oportunidade de dita notificação usando um marco enviado periodicamente pelo primeiro roteador de acesso e ecoado de volta na notificação. O método pode incluir enfileirar, no segundo roteador de acesso, pacotes de IP remetidos do primeiro roteador de acesso até que o nó móvel apareça na nova ligação e a resolução de endereço necessária e outros procedimentos tenham sido completados para assegurar que o segundo roteador de acesso e o nó móvel possam trocar pacotes. O método pode incluir enfileirar, no primeiro roteador de acesso, pacotes destinados ao cuidado de endereço antigo do nó móvel até que o primeiro roteador de acesso seja capaz de determinar o novo cuidado de endereço do nó móvel.
Uma fila pode ser estabelecida para o nó móvel em um roteador de acesso dependendo da relação de confiança existindo entre esse roteador de acesso e o outro roteador de acesso e/ou o nó móvel. O tamanho máximo da fila depende de ditas relações de confiança. A etapa de predizer o novo cuidado de endereço pode ser probabilística e pode falhar. A etapa de predizer o novo cuidado de endereço pode incluir aplicar um procedimento que é conhecido e compreendido por nós móveis e roteadores de acesso. Este procedimento usa endereços gerados através de criptografia. Mais particularmente, o procedimento pode fazer uso de certificados. A etapa de determinar um novo cuidado de endereço pode incluir usar a chave pública de um par de chaves pública-privada pertencendo ao nó móvel para gerar o novo cuidado de endereço, e dita etapa de confirmar a propriedade do novo cuidado de endereço pelo nó móvel inclui gerar uma mensagem assinada no nó móvel com a chave privada, e enviar essa mensagem assinada ao primeiro roteador de acesso. O novo cuidado de endereço pode ser um de uma pluralidade de cuidado de endereços preditos pelo primeiro roteador de acesso, o primeiro roteador de acesso remetendo pacotes para cada um dos cuidado de endereços preditos. O método pode incluir, seguindo a predição do novo cuidado de endereço pelo primeiro roteador ou pelo nó de procuração, enviar um pedido de estabelecimento de túnel do primeiro roteador para o segundo roteador, e remeter subseqüentemente pacotes pelo túnel estabelecido. O segundo roteador de acesso pode verificar a relevância de pedidos de estabelecimento de túnel enviando periodicamente um marco para escutar nós móveis, dito nó móvel ouvindo este marco quando varre uma nova ligação e o incluindo em sua notificação para o primeiro roteador de acesso, o primeiro roteador de acesso incluindo o marco na mensagem de estabelecimento de túnel.
De acordo com um segundo aspecto da presente invenção, é provido um roteador de acesso para uso em uma rede de acesso comutada por pacote e incluindo: meio para determinar um cuidado de endereço futuro para um terminal móvel conectado atualmente ou recentemente ao roteador de acesso e para confirmar a propriedade do novo cuidado de endereço pelo nó móvel; meio para remeter pacotes enviados ao terminal móvel em um cuidado de endereço associado com o roteador de acesso, para dito cuidado de endereço. O roteador de acesso pode incluir meio para estabelecer um túnel entre o roteador de acesso e um segundo roteador de acesso associado com o cuidado de endereço futuro predito.
De acordo com um terceiro aspecto da presente invenção é provido um nó móvel para uso no primeiro aspecto acima da invenção e incluindo meio para notificar o primeiro roteador de acesso que o nó móvel tem, ou está prestes a se transferir para um novo roteador de acesso.
De acordo com um quarto aspecto da presente invenção, é provido um método de remeter pacotes de IP, enviados a um cuidado de endereço antigo de um nó móvel, para o nó móvel seguindo uma transferência de passagem do nó móvel de um primeiro roteador de acesso antigo para um segundo novo roteador de acesso, o método incluindo: antes de conclusão de dita transferência de passagem, prover dito primeiro roteador ou outro nó de procuração com informação necessária para predizer o novo cuidado de endereço de IP a ser usado pelo nó móvel quando o nó móvel é transferido ao segundo roteador de acesso; em dito primeiro roteador ou dito nó de procuração, predizer o novo cuidado de endereço para o nó móvel usando dita informação; e remeter subsequentemente pacotes recebidos em dita primeira rede de acesso e destinados para dito cuidado de endereço antigo, para o endereço de cuidado de endereço predito.
Breve Descrição dos Desenhos Figura 1 ilustra sinalização associada com uma primeira concretização da invenção;
Figura 2 ilustra um túnel de remessa de pacote de um roteador de acesso antigo para um novo;
Figura 3 ilustra a estrutura de um pacote de IP antes e durante a remessa pelo túnel da Figura 2;
Figura 4 ilustra a estrutura de uma nova mensagem de ICMP (criação de túnel);
Figura 5 ilustra os conteúdos da mensagem de ICMP da Figura 4.
Descrição Detalhada de Certas Concretizações O procedimento apresentado aqui provê um novo método para estabelecer remessa de um cuidado de endereço antigo para um novo cuidado de endereço para um nó móvel vagando em uma rede visitada. Em um cenário de exemplo, o nó móvel é um terminal móvel sem fios e a rede visitada é uma rede de acesso comutada por pacote de um sistema de telefone celular. A rede de acesso inclui vários nós de acesso aos quais o nó móvel pode se conectar. O dono/usuário do terminal móvel é um assinante de alguma outra rede "doméstica". O método de transferência de passagem apresentado aqui é superior aos métodos previamente apresentados em termos de segurança e eficiência de mensagem. Especificamente, estabelecer a remessa entre o nó móvel e um roteador de acesso antigo pode ser realizado com tão pouca quanto uma mensagem. Com suposições adicionais sobre a rede, é às vezes até mesmo possível estabelecer a remessa sem qualquer mensagem extra entre o nó móvel e os roteadores de acesso.
Deveria ser notado que, embora este documento seja escrito com otimização de IPv6 Móvel em mente, o procedimento apresentado não está por nenhum meio limitado a IPvó Móvel. É aplicável a qualquer técnica de mobilidade de IP que seja baseada em um mecanismo onde o nó móvel informa a seus semelhantes sobre mudanças em seus endereços. O procedimento para alcançar transferência de passagem rápida se confia em algumas suposições de simplificação. Estas suposições permitem ao estado necessário ser estabelecido com menos mensagens e melhor segurança do que os métodos prévios foram capazes de alcançar. Estas suposições são realistas em ambientes práticos. Adicionalmente, variações do procedimento também são apresentadas para as quais as suposições são levantadas embora com alguma perda de eficiência. A primeira suposição que é feita é que o nó móvel é capaz de antecipar, com uma alta probabilidade, o novo cuidado de endereço que é provável de usar com um novo roteador de acesso seguindo transferência de passagem. No caso improvável que a antecipação de endereço falhe, alguns pacotes podem ser enviados a um hospedeiro de destino errado, mas os pacotes serão suprimidos pelo recebedor. No mecanismo principal descrito aqui, referido abaixo como o mecanismo "básico", um novo roteador de acesso envolvido em um procedimento de transferência de passagem assume que o roteador de acesso antigo não envia qualquer tráfego desnecessário para ele. Note que roteadores já assumem que hospedeiros na Internet não enviam pacotes para nós não existentes ou enviam pacotes desnecessários. Porém, um inuuAJ |jcuu aoov^uiai 4UV votu jujjvtpivuv ον j.u,tuii-ixjaiu v aoovgui m v-juv vo uvxo roteadores pertençam ao mesmo domínio administrativo, e que a rede execute filtragem de endereço de fonte de forma que não seja possível enviar pacotes com um endereço de fonte "enganado" de forma que eles pareçam vir de um roteador de acesso antigo.
Em qualquer caso, os efeitos negativos potenciais desta falha de suposição são relativamente benignos; roteadores já são esperados serem capazes de priorizar seu uso de recursos para se protegerem contra depleção de recursos. Adicionalmente, uma variação do mecanismo proposto oferece meio heurístico e criptográfico para distinguir tráfego falso de tráfego legitimo. Isto é descrito em mais detalhe abaixo.
Para alcançar o objetivo de prevenir perda de pacote desnecessária durante e depois da transferência de passagem de um nó móvel entre roteadores de acesso, é necessário estabelecer um mecanismo por meio do qual pacotes destinados ao cuidado de endereço antigo sejam passados ao novo cuidado de endereço. Para fazer assim, um túnel de remessa é estabelecido do roteador de acesso antigo para o novo cuidado de endereço, por esse meio remetendo os pacotes para o novo local do nó móvel. O túnel de remessa tem um tempo de vida limitado, embora o nó móvel possa pedir explicitamente um tempo de vida estendido para o túnel, se precisado. É importante notar que, enquanto um dos pontos finais de túnel está localizado no roteador de acesso antigo, o outro ponto final não está localizado no novo roteador de acesso, mas dentro do próprio hospedeiro móvel, em seu novo cuidado de endereço. Há duas variantes principais do procedimento de transferência de passagem rápida. No caso "proativo", o túnel de remessa é estabelecido antes que o nó móvel se mova para longe da ligação antiga. No caso "reativo", o túnel de remessa é criado uma vez que o nó móvel tenha chegado à nova ligação e é capaz de usar seu novo cuidado de endereço. O túnel de remessa é essencialmente uma otimização e é por esse meio um "estado suave Se precisado, o roteador de acesso antigo está livre para suprimir o túnel a qualquer hora, até mesmo antes que o tempo de vida de túnel expire. Isto pode resultar em perda de pacote, mas pode ser aceitável em uma dada situação.
Uma vez que o nó móvel tenha completado seu movimento à nova ligação, o túnel pode ser usado em ambas as direções. Isto permite ao nó móvel enviar pacotes usando o cuidado de endereço antigo durante o tempo que leva para atualizar as ligações. O novo roteador de acesso não precisa estar ciente do túnel de remessa. Tudo que ele vê são pacotes enviados pelo roteador de acesso antigo ao nó móvel no novo cuidado de endereço, e pacotes enviados pelo nó móvel do novo cuidado de endereço para o roteador de acesso antigo. • Remessa Reativa No caso de remessa reativa, o roteador de acesso antigo pode enfileirar alguns pacotes enviados ao cuidado de endereço antigo na esperança que o nó móvel retomará ou estabelecerá subseqüentemente o túnel de remessa. Tal mecanismo de remessa está sujeito à política local, e pode ser ativado simplesmente pelo nó móvel deixando a ligação antiga. A sinalização associada com o caso de remessa reativa é ilustrada na Figura 1.
Porém, deveria ser notado que a ordem das mensagens não é necessariamente como mostrado.
Por exemplo, a mensagem de "Eu estou aqui agora" podería ser enviada depois da mensagem de designação de endereço.
Também, a mensagem de Estabelecimento de Túnel pode não ser precisada, e colocação em túnel é alcançada usando descoberta de vizinho como explicado em outro lugar no texto. E ademais notado que o Processo de designação de endereço consistirá tipicamente em múltiplo, e pode ser executado em um ponto diferente no esquema de sinalização global. Remessa de pacote pode começar tanto imediatamente depois do recebimento no novo λκ ou aa πιαísagein ue jdu estou aqui agoia , uu mais tatue. ivemessa pouc ir pelo novo AR ou ser endereçada diretamente ao nó móvel. No caso anterior, o novo AR armazenará em memória temporária os pacotes até que a designação de endereço esteja completa. • Remessa Proativa No caso de remessa proativa, a fim de evitar perda de pacote no novo roteador de acesso, pode ser requerido que o novo roteador de acesso enfileire alguns pacotes antes que o nó móvel esteja pronto para receber pacotes no novo cuidado de endereço. Porém, este problema de enfileiramento é considerado ser separado arquitonicamente do problema de remessa. Como explicado acima, o novo roteador de acesso não precisa criar qualquer estado até mesmo quando remessa é usada. Por outro lado, enfileiramento por si mesmo cria um estado. A princípio pode parecer que seria necessário para o roteador de acesso antigo pedir explicitamente ao novo roteador de acesso para enfileirar os pacotes remetidos. Porém, sob inspeção rigorosa tal sinalização parece ser completamente desnecessária. Como já foi declarado, é assumido que o novo roteador de acesso confia que o roteador de acesso antigo não enviará qualquer pacote desnecessariamente. Baseado nesta suposição, um acordo implícito pode ser criado entre os roteadores de acesso. O novo roteador de acesso assume que se o roteador de acesso antigo enviar para ele pacotes que são destinados a um nó desconhecido, então o roteador de acesso antigo tem uma razão para esperar que aquele nó chegará na nova ligação de acesso brevemente. Conseqüentemente, o novo roteador de acesso pode enfileirar seguramente os pacotes por enquanto, espaçar e outros recursos permitindo. Sinalização não ajuda aqui. Se o novo roteador de acesso tiver recursos, ele pode enfileirar facilmente pacotes, até mesmo se não tiver recebido um pedido para fazer assim. Por outro lado, se o novo roteador de acesso não tiver bastante recursos, ele não pode enfileirar os pacotes mesmo se o roteador de acesso antigo tiver pedido para fazer assim.
Se o novo roteador de acesso não souber ou confiar no roteador de acesso antigo, a situação se toma ligeiramente mais complicada. Se não houver nenhuma relação de forma alguma entre o antigo e novo roteador de acesso, o caso se toma basicamente o mesmo como acima: tanto o novo roteador de acesso é capaz de enfileirar os pacotes desconhecidos ou não é. Uma mensagem de sinalização do roteador de acesso antigo desconhecido e não confiado não ajuda, como poderia ser forjada. Uma situação mais desafiadora é o caso onde o novo roteador de acesso não tem inicialmente qualquer razão para confiar no roteador de acesso antigo, mas há um terceiro confiado pelo novo roteador de acesso, que é capaz de certificar o roteador de acesso antigo. Porém, mesmo aqui é desnecessário informar ao novo roteador de acesso sobre cada hospedeiro móvel separadamente. Sinalização não adiciona nenhum recurso ao novo roteador de acesso. Assim, se sinalização for precisada para criar uma relação de confiança entre os roteadores em primeiro lugar, esta sinalização é melhor mantida separada do enfileiramento atual dos pacotes. • Relações de confiança Há três partes envolvidas no protocolo de base; o nó móvel, o roteador de acesso antigo, e o novo roteador de acesso. Por necessidade, o nó móvel deve confiar nos roteadores de acesso para prover serviços de roteamento. Quer dizer, deve confiar que os roteadores passem corretamente pacotes entre o nó móvel e seus semelhantes. Adicionalmente, mais provavelmente o nó móvel deveria, ou pelo menos pode confiar que os roteadores não lançam deliberadamente ataques contra ele. Além disso, antes de estabelecer o túnel de remessa, o nó móvel deve decidir confiar que o roteador de acesso antigo executará remessa corretamente. Em uma situação real, o nó móvel provavelmente autenticará os roteadores de acesso antes que decida confiar neles. Porém, tais mecanismos caem fora da extensão deste documento. 0 novo roteador de acesso deve confiar, a uma extensão, que o roteador de acesso antigo não envia desnecessariamente pacotes que são destinados para nós que não estão (ainda) na ligação. Esta confiança pode ser manifestada na quantidade de espaço e recursos que o novo roteador de acesso está pronto para dedicar a enfileirar pacotes. Como roteadores de acesso antigos potenciais podem cair em classes de probidade variada, o novo roteador de acesso pode reservar quantidade diferente de recursos para cada classe. Por exemplo, pode estar disposto a enfileirar pacotes de nós que parecem estar na mesma sub-rede como ele mesmo, mas recusar a enfileirar pacotes enviados por qualquer outro nó.
Os roteadores de acesso não deveriam confiar nos nós móveis. Os roteadores de acesso devem assumir que o nó móvel pode tentar lançar vários tipos de ataques contra eles ou outros nós móveis. Por outro lado, os roteadores de acesso são considerados serem obrigados a prover serviços ao nó móvel. Quer dizer, embora os roteadores de acesso não confiem no nó móvel, eles ainda devem estar dispostos a rotear pacotes para e do nó móvel. Adicionalmente, o roteador de acesso antigo deveria estar disposto, durante um tempo limitado pelo menos, a remeter pacotes em nome de um nó móvel que deixou recentemente a ligação.
No caso proativo, é ademais assumido que o nó móvel confia no roteador de acesso antigo para criar corretamente o túnel de remessa baseado só no identificador do novo roteador de acesso.
Adicionalmente, o nó móvel precisa ser capaz de confiar que o roteador de acesso antigo não iniciará a remeter pacotes antes que o nó móvel de fato se separe da ligação.
No protocolo de base, os nós são assumidos não confiarem em nenhum outro na rede. Por outro lado, algumas variações assumem um terceiro confiado. É assumido que o nó móvel aprende alguma noção de tempo ele ligar a mensagem de criação de túnel de remessa com a noção de tempo do roteador de acesso, por esse meio contrariando ataques repetidos. Não há nenhuma necessidade para assumir relógios sincronizados entre quaisquer das partes. • Ameaças potenciais Como o mecanismo cria estados nos roteadores de acesso no pedido de um nó móvel não confiado, o mecanismo é vulnerável à criação não autorizada de estados. Adicionalmente, o mecanismo pode abrir nova negação de possibilidades de serviço. Nesta seção nós analisamos brevemente as ameaças identificadas.
Roubo de Endereço Se um atacante for capaz de criar um túnel de remessa não autorizado em um roteador de acesso, ele pode efetivamente colocar em túnel todos os pacotes tanto para si mesmo ou para um buraco negro. Isto é semelhante ao ataque de roubo de endereço básico de IPvó móvel e tem consequências semelhantes com respeito à integridade e segredo. O ataque funciona contra qualquer nó que use o roteador de acesso vulnerável para seu acesso de rede.
Roubo de Endereço Futuro Se um atacante for capaz de antecipar o cuidado de endereço que um nó móvel é provável de usar em uma ligação, e se puder se conectar à ligação usando esse endereço particular, ele pode usar o endereço por algum tempo, se mover para longe e pedir o endereço a ser remetido. Tal pedido seria autorizado como o atacante estava legalmente usando o mesmo endereço. Quando a vítima mais tarde vier à ligação, ela não obterá nenhum pacote como seu endereço está remetido fora.
Interrupção de túnel de remessa não autorizado A vulnerabilidade a roubo de endereço futuro não pode ser diminuída simplesmente dizendo que um nó ativo em uma ligação sempre anula um túnel de remessa. Tal prática permitiría a um atacante iniciar usando o endereço de um nó móvel logo depois que o nó móvel se moveu para longe, por esse meio rompendo o túnel de remessa.
Criar um túnel de remessa para um falso fim Um atacante pode ser capaz de criar um túnel de remessa cujo ponto final é um local onde o atacante não tem nenhuma intenção para se mover. Se houver um novo roteador de acesso de enfileiramento nesse local, este ataque consumirá recursos de enfileiramento no novo roteador de acesso. Inundação com criação de túnel Se um atacante for capaz de estabelecer um grande número de túneis de remessa ao mesmo tempo, todos dirigidos para o mesmo cuidado de endereço ou para uma única rede, um atacante pode ser capaz de inundar o objetivo com uma grande quantidade de pacotes. O próprio atacante não precisa estar envolvido no tráfego depois do estabelecimento inicial, como os pacotes serão enviados por vários servidores que o atacante contatou antes de estabelecer os túneis de remessa. Isto é semelhante aos ataques de inundação de IPv6 móvel.
Reproduzindo criação de túnel Se um atacante for capaz de registrar uma mensagem de estabelecimento de remessa e mais tarde reproduzi-la quando o nó móvel está de volta à ligação, o atacante pode por em "buraco negro" o tráfego. Isto resulta em negação de serviço.
Exaurindo recursos de enfileiramento no novo roteador de acesso O novo roteador de acesso pode querer enfileirar pacotes remetidos chegando antes que o nó móvel chegue. O roteador só tem uma quantidade limitada de recursos disponíveis para armazenar tais pacotes. Se um atacante puder fazer o novo roteador de acesso enfileirar desnecessariamente pacotes, isto pode requerer tantos recursos que o roteador não pode enfíleirar pacotes destinados para um nó móvel legítimo. Assim, é desejável que o novo roteador de acesso possa de alguma maneira fazer uma distinção entre pacotes legitimamente remetidos que precisam ser enfileirados e pacotes aleatórios que não precisam ser enfileirados.
Exaurindo recursos de enfileiramento em roteador de acesso antigo O roteador de acesso antigo pode querer enfíleirar pacotes destinados a um nó móvel que se moveu para longe, mas que ainda não estabeleceu um túnel de remessa para seu novo local. Como com o caso de novo roteador de acesso, há só uma quantidade limitada de memória disponível para armazenar tais pacotes. Se um atacante puder forçar o roteador de acesso para armazenar desnecessariamente pacotes que nunca serão entregues ao novo local de um nó móvel, isto ocupará recursos. Assim, é desejável que o roteador de acesso antigo possa de alguma maneira fazer uma distinção entre pacotes que são prováveis de serem enviados a um nó móvel e aqueles que não são. • Soluções A solução básica consiste em duas partes. A primeira parte cuida da criação do túnel de remessa do roteador de acesso antigo para o novo local do nó móvel. A segunda parte trata de enfileiramento de pacotes em roteadores de acesso. A solução é baseada em um acordo no cuidado de endereços. Quer dizer, os nós móveis não são permitidos usarem livremente qualquer cuidado de endereço que eles poderiam querer usar. Ao invés, o nó móvel e roteadores de acesso devem concordar sobre o cuidado de endereços que o nó móvel é para usar, ou pelo menos é provável de usar. O acordo exato depende da solução de segurança aplicada. O protocolo básico usa Endereços de IPv6 Gerados Através de Criptografia [Aura, T., "Cryptographically Generated Addresses (CGA)", maio de 2003]. A solução presente é caracterizada só por requisitos de estado mínimos. Antes que o nó móvel peça que um túnel de remessa seja estabelecido, nenhum dos roteadores de acesso precisa ter qualquer estado por nó, diferente daqueles que eles têm para outros propósitos. Por exemplo, o roteador de acesso antigo deve, naturalmente, manter informação de estado sobre os nós móveis que está servindo. Esta informação de estado é mantida tipicamente só por um curto tempo depois que um nó móvel deixou a ligação, e o estado pode ser utilizado em controlar ambos estabelecimento de remessa e enfileiramento de pacotes. Porém, tal estado não é necessário, e o túnel de remessa ainda pode ser criado seguramente até mesmo sem tal estado. O novo roteador de acesso não tem e não precisa ter qualquer estado antes que o nó móvel de fato chegue na ligação e adquira um cuidado de endereço. Até mesmo depois disso, o único estado explícito precisado é o estado natural que o novo roteador de acesso tem que manter para cada nó móvel para outros propósitos. É importante notar que os requisitos de estado são ligeiramente diferentes para estabelecimento de remessa e enfileiramento de pacotes. Para o estabelecimento de remessa, toda a informação de estado a priori pode ser . armazenada no nó móvel. Para enfileiramento de pacotes por outro lado, o roteador de acesso antigo pode precisar manter informação de estado sobre os nós que recentemente serviu, mas não serve mais.
Para impedir perda de pacote, os pacotes enviados ao cuidado de endereço antigo são remetidos ao novo cuidado de endereço. Para realizar isto, um túnel de remessa é criado do roteador de acesso antigo ao novo local . do nó móvel. O túnel resultante é descrito na Figura 2. O túnel é criado entre o roteador de acesso antigo e o nó móvel no novo local. Quer dizer, o cabeçalho de IP exterior tem o novo cuidado de endereço como seu endereço de destino e o endereço de roteador de acesso antigo como seu endereço de fonte. Respectivamente, o estado de túnel está localizado no nó móvel e no roteador de acesso antigo; o novo roteador de acesso pode permanecer não ciente da existência do túnel. Figura 3 ilustra o formato de pacote de IP antes de remessa (topo) e durante remessa (abaixo).
No caso proativo, o túnel é criado logicamente antes que o nó móvel chegue ao novo local. Nesse caso, os pacotes (alguns) se enfileirarão no novo roteador de acesso até que o nó móvel chegue ao novo local. Como já discutido, isto não impõe qualquer necessidade de ter estado por nó explícito no novo roteador de acesso.
Os dois pontos finais do túnel podem ser criados separadamente. O ponto final no roteador de acesso antigo é criado no pedido do nó móvel. O outro ponto final é criado logo que o nó móvel saiba, com certeza, seu novo cuidado de endereço. Deve ser notado que em alguns cenários, o roteador de acesso antigo sabe o novo cuidado de endereço futuro antes que o nó móvel o conheça. Isto é possível se, por exemplo, o cuidado de endereço for determinado através de algoritmo, como explicado abaixo.
No protocolo básico, o cuidado de endereços são sempre endereços de CGA [Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPvó World", 9o Seminário Internacional de Protocolos de Segurança, Cambridge, REINO UNIDO, 25-27 de abril 2001, LNCS 2467, páginas 12-26, Springer, 2002], A idéia básica é que a parte de identificador de interface do endereço de IPv6 seja criada tomando uma reedição criptográfica sobre o prefixo de roteamento e a chave pública do nó móvel. Os detalhes são definidos em [Aura, T., "Cryptographically Generated Addresses (CGA)", maio de 2003], e é desnecessário repeti-los aqui.
Esta construção tem três conseqüências importantes: • Os endereços são distribuídos aleatoriamente, e se quaisquer das entradas de reedição for perdida, é difícil predizer o que o endereço será, • Dado um prefixo de roteamento, a chave pública, e os outros parâmetros, qualquer nó pode construir facilmente o endereço mais provável. • Dado um endereço, chave pública, e os outros parâmetros, um nó pode verificar que a chave pública está associada com o endereço com uma alta probabilidade. Em outras palavras, dado um endereço, é difícil de construir outra chave pública que dê o mesmo endereço na mesma ligação. Além disso, dada qualquer chave pública, é até mais difícil construir uma chave pública diferente que dê os mesmos endereços (como o dado) em duas ligações separadas. É notado que sem qualquer conhecimento sobre a chave pública, os endereços parecem ser virtualmente aleatórios, e não revelam nenhuma informação sobre a identidade do nó. Se o mesmo identificador de interface for mantido por muito tempo, isto pode, porém, ajudar a determinar a identidade do nó móvel e rastrear seus movimentos. Para contrariar este problema potencial, o nó móvel pode mudar periodicamente sua chave pública ou outros parâmetros usados como entrada para a geração de identificador de interface. O nó móvel pode pedir que o roteador de acesso antigo crie o túnel de remessa tanto proativamente, antes que mude de local, ou reativamente, depois de ter mudado de local. Também existe um caso especial, discutido ademais abaixo, onde o roteador de acesso antigo pode até mesmo criar o túnel de remessa autonomamente.
Operação proativa não é sempre possível. E só possível se: 1. O nó móvel puder predizer que se moverá (provavelmente), e 2. O nó móvel puder identificar o (provável) novo roteador de acesso.
Adicionalmente, é útil se o roteador de acesso antigo puder detectar o momento quando o nó móvel de fato se move para longe, e ativa o túnel de pedido só então.
Para ser capaz de criar seguramente o ponto final de túnel, o roteador de acesso antigo tem que saber o seguinte: 1. O cuidado de endereço antigo do nó móvel. 2. 0 (provável) novo cuidado de endereço do nó móvel 3. Nenhum outro nó móvel é provável estar presente no novo cuidado de endereço. 4. O nó móvel está ou estava recentemente presente na ligação antiga, usando o cuidado de endereço antigo.
As primeiras três propriedades podem ser estabelecidas facilmente com endereços de CGA. Porém, o quarto ponto requer oportunidade, e portanto tanto estado, marcas de tempo, ou marcos são precisados. Para evitar problemas com sincronização de tempo, nós evitamos marcas de tempo. O protocolo básico usa marcos; é definido mais tarde como estado pode ser usado para aumentar a proteção provida por marcos.
Para reduzir requisitos de estado e proteger contra ataques de retomada, os roteadores de acesso radiodifundem periodicamente um marco para a ligação local. O marco é mudado a cada alguns segundos. O roteador de acesso deve se lembrar do marco atual e pelo menos um marco prévio. O algoritmo exato usado para geração de marco é um assunto local para o roteador de acesso. Porém, dada qualquer história de marcos, deve ser difícil de forma criptográfica predizer marcos futuros.
Para pedir um túnel de remessa, o nó móvel envia uma mensagem ao roteador de acesso antigo. A mensagem deve conter os dados seguintes. • Identidade do roteador de acesso antigo, em alguma forma. • Identidade do novo roteador de acesso, em alguma forma. • Um marco recente, como recebido do roteador de acesso antigo. • Cuidado de endereço antigo, para verificação de CGA. • Chave pública, parâmetros de CGA e Assinatura. O roteador de acesso antigo executa as operações seguintes: • Verifica que o pacote identifica corretamente o roteador de acesso antigo. • Verifica que o marco está suficientemente fresco. • Verifica que o cuidado de endereço antigo tem o prefixo de roteamento correto usado na ligação servida pelo roteador de acesso antigo. • Verifica que o cuidado de endereço antigo corresponde com a dada chave pública e parâmetros de CGA. • Verifica a assinatura.
Depois deste procedimento, o roteador de acesso antigo conhece o seguinte: • O remetente do pacote estava recentemente na ligação local (ou pelo menos era capaz de receber o marco que o roteador de acesso antigo radiodifundiu na ligação local), como o marco está fresco. • O remetente do pacote, identificado pela chave pública, usava o dado cuidado de endereço antigo enquanto estava na ligação local (com alta probabilidade, dado que o remetente estava na ligação local em primeiro lugar), A probabilidade que outra pessoa estava usando o endereço ou estava usando atualmente o endereço é muito pequena. Porém, se parecer que outra pessoa está usando o endereço agora mesmo, o túnel não pode ser estabelecido. (Isto é um custo imposto pela natureza probabilística do esquema. Porém, a probabilidade de tal colisão é quase desprezível, e é impossível, para todos os propósitos práticos, para um atacante simular uma tal colisão.) • Nenhum outro mas um nó conhecendo a chave privada correspondendo à dada chave pública enviou o pacote, como a assinatura foi verificada (e o marco está coberto pela assinatura). • O remetente do pacote é provável (ou pelo menos reivindica) ser acessível agora (ou logo) no dado novo roteador de acesso.
Dada a informação no pacote e o conhecimento estabelecido pelo processo de verificação, o roteador de acesso antigo pode agora proceder para estabelecer o túnel de remessa. Para fazer assim, primeiro deve derivar o (provável) novo cuidado de endereço do nó móvel como segue: va • Dado o novo identificador de roteador de acesso levado na mensagem, o roteador de acesso antigo determina o prefixo de roteamento para nós na nova ligação. O método exato como o roteador de acesso antigo determina o prefixo de roteamento cai além da extensão deste documento. • Dada a chave pública, parâmetros de CGA e o novo prefixo de roteamento, o roteador de acesso antigo computa o novo identificador de interface, como discutido acima. • Concatenar o prefixo de roteamento e o identificador de interface dá o novo (provável) cuidado de endereço. • Neste ponto, o roteador de acesso antigo sabe ambos o antigo e novo cuidado de endereços do nó móvel, e pode estabelecer o túnel de remessa. No esquema básico, o túnel é apenas estabelecido, implicitamente. O túnel expirará automaticamente depois de um período de tempo prefixado.
Em algumas das variações descritas mais tarde neste documento, o roteador de acesso antigo envia uma mensagem de reconhecimento.
Deveria ser notado que não há nenhuma diferença fundamental entre os casos proativo e reativo. Em ambos os casos, o nó móvel envia essencialmente a mesma informação ao roteador de acesso antigo. Porém, pode haver diferenças práticas.
Uma vez que o nó móvel chegue na nova ligação e seja capaz de adquirir um novo cuidado de endereço, deve estar pronto para receber pacotes remetidos. Como ele tem seu próprio cuidado de endereço antigo e o endereço do roteador de acesso antigo, ele tem toda a informação precisada e pode iniciar desempacotando pacotes adequadamente enviados em túnel. Como discutido abaixo, é muito improvável que qualquer nó possivelmente existente estaria disposto a desempacotar estes pacotes, até mesmo se houvesse uma colisão de endereço.
Como o roteador de acesso antigo pode criar o novo cuidado de endereço já antes que o nó móvel tenha chegado na nova ligação, é possível que o novo cuidado de endereço não esteja disponível. Quer dizer, é possível que algum outro nó já esteja usando o dado endereço quando o nó móvel chega na nova ligação. Porém, tal evento é muito improvável. Para propósitos práticos, endereços de CGA são distribuídos uniformemente e aleatoriamente através de 259 valores diferentes. Assim, dada uma ligação com k nós já na ligação, a probabilidade que um nó de chegada obteria um endereço disponível é (l-2"59)k, que é ligeiramente maior que 1- k*259 para todos os valores práticos de k, Reciprocamente, a probabilidade de colisão é menos que k*2A59. Por exemplo, para uma ligação com cerca de 65.000 ou 216 nós, a probabilidade de colisão é menos que 216*2'59 = 2'43 = 1,137*10'13. Se o novo roteador de acesso estiver servindo 216 nós a qualquer hora, e lá chegar um novo nó a cada 1 segundo (e um nó antigo parte, respectivamente), levará mais de 250.000 anos antes que seja provável ter havido uma colisão. Assim, colisões de endereço serão eventos muito raros. A especificação de CGA define um método pelo qual o nó móvel é capaz de adquirir outro cuidado de endereço se a escolha prefixada já estiver ocupada. Porém, se o roteador de acesso antigo estabeleceu o túnel de remessa tanto proativamente ou autonomamente, os pacotes remetidos são passados a um nó errado. Felizmente, este nó é provável suprimir os pacotes com uma probabilidade maior que 1-259, como a probabilidade que o cuidado de endereço antigo do nó receptor e o cuidado de endereço antigo do nó de chegada colidiría não só requer que ambos os nós tenham chegado da mesma ligação, mas também que eles tivessem o mesmo cuidado de endereço naquela ligação antiga.
Assim, na prática, uma colisão de endereço na nova ligação é um evento muito raro. No evento que acontece, a única consequência prática é que os pacotes remetidos serão suprimidos. O novo roteador de acesso cria uma entrada de 'cache' vizinha para o nó móvel quando ele chega. Assim, no caso de estabelecimento de remessa proativa ou autônoma, se um pacote remetido chegar no novo roteador de acesso antes que o nó móvel tenha chegado, o novo roteador de acesso simplesmente nota que recebeu um pacote destinado para um endereço para o qual não tem nenhuma entrada 'cache' vizinha. No caso reativo, pode haver pacotes chegando no cuidado de endereço antigo antes que o túnel de remessa tenha sido estabelecido. Em ambos os casos, é desejável enfileirar os pacotes por um tempo limitado, e remeter os pacotes logo que possível. Também, em ambos os casos, o volume de pacotes enfileirados está estritamente ligado pela quantidade de recursos disponíveis nos roteadores de acesso. Este volume é provável ser ligado por hardware, e portanto não pode ser variado dinamicamente. Assim, o problema para resolver em administrar enfüeiramento é se assegurar que nenhum pacote está enfíleirado desnecessariamente. Uma vez que isto foi cuidado, não há nenhuma necessidade adicional para diferenciar entre pacotes enfileirados, a menos que classes de QoS explícitas sejam usadas. O roteador de acesso antigo pode iniciar a enfileirar pacotes uma vez que perceba que um nó deixou a ligação, mas não estabeleceu um túnel de remessa. Deveria enfileirar estes pacotes só por um tempo limitado. O tempo de enfileiramento deveria ser variado de acordo com a quantidade de memória disponível e a quantidade de pacotes a serem enfileirados. O algoritmo de administração de fila atual é um assunto local. Os pacotes enfileirados podem ser remetidos tanto se o nó retomar à ligação ou se o nó estabelecer um túnel de remessa. O roteador de acesso antigo pode notar que um nó deixou a ligação por notificação de camada de ligação, por falha de Detecção de Incapacidade de Alcance de Vizinho de IPv6 (NUD), ou por algum outro meio. Todas estas situações são caracterizadas pelo roteador de acesso antigo ter uma entrada de 'cache' de vizinha para o cuidado de endereço antigo, e um evento sinalizando a inabilidade para passar de fato pacotes ao nó móvel. O novo roteador de acesso pode iniciar a enfileirar pacotes se iniciar recebendo pacotes enviados em túnel para um endereço que não está atualmente em sua 'cache' de vizinha. Em tal caso, os pacotes são provavelmente para serem destinados a um nó móvel que ainda não chegou à ligação, mas que provavelmente chegará e iniciará usando o endereço como seu cuidado de endereço. Se o novo roteador de acesso tiver bastante recursos disponíveis, ele pode enfileirar todos os pacotes recebidos, mas não entregáveis durante algum tempo. Porém, tal prática é vulnerável a um ataque de negação de serviço, onde o atacante, talvez usando endereços de fonte falsos, tenta encher a memória disponível com pacotes que nunca serão entregues. Assim, o novo roteador de acesso deveria classificar pacotes enfileirados baseado na probabilidade que eles de fato foram enviados por um roteador de acesso antigo confiado. Há múltiplos modos nos quais o novo roteador de acesso pode classificar os pacotes. Pelo menos as possibilidades seguintes estão disponíveis: • O novo roteador de acesso pode decidir dar prioridade a pacotes contendo um cabeçalho de túnel. • O novo roteador de acesso pode verificar o endereço de fonte no cabeçalho de túnel, e dar prioridade a um pacote se o endereço de fonte pertencer a um roteador de acesso antigo conhecido. Este método pode ser fortalecido se for possível estruturar a rede de tal modo que seja impossível para estranhos enviarem pacotes de IP que contêm endereço de fonte falso pertencendo a um roteador de acesso antigo. • Se o novo roteador de acesso e os roteadores de acesso antigos conhecidos compartilharem associações de segurança de IPSec, o novo roteador de acesso pode dar prioridade a pacotes que são protegidos usando uma tal associação de segurança. • Antes de iniciar a enviar pacotes colocados em túnel, o roteador de acesso antigo pode remeter a mensagem de estabelecimento de remessa que recebeu, e o novo roteador de acesso pode verificar esta mensagem, como explicado abaixo, e criar uma entrada de 'cache' de vizinha "futura" de tentativa. Pode então dar prioridade a endereços de destino que têm uma tal entrada de 'cache' de vizinha "futura" de tentativa. À primeira vista, parece desejável ter conhecimento explícito dos nós móveis que são prováveis de chegar à ligação no futuro próximo. Nós agora definimos um método que permite ao novo roteador de acesso estabelecer um tal estado.
Uma vez que o roteador de acesso antigo tenha executado sua verificação em uma mensagem de estabelecimento de remessa, ele pode remeter a mensagem ao novo roteador de acesso. Se fizer assim, deveria remeter o pacote primeiro e iniciar passando pacotes enviados em túnel só depois. Quando o novo roteador de acesso recebe uma tal mensagem de estabelecimento de remessa passada, deveria verificar a mensagem como segue: • Verificar que a mensagem foi enviada por um roteador de acesso antigo conhecido, por exemplo, baseado no endereço de fonte (+ confiar em filtragem de ingresso como discutido acima), baseado na mensagem sendo protegida com IPSec, ou por algum outro meio. • Se possível, o novo roteador de acesso deveria verificar que a mensagem está fresca, isto é, não uma mensagem reproduzida. Se isto é possível, depende principalmente de como a mensagem foi retransmitida pelo roteador de acesso antigo. Por exemplo, se a mensagem for protegida com IPSec, proteção de número de seqüência de IPSec da segurança suficiente que ninguém reproduziu a mensagem (exceto talvez o roteador de acesso antigo). • Se o prefixo de roteamento usado na ligação antiga for conhecido (baseado na identidade de roteador de acesso antigo), ele verifica que o prefixo de roteamento no cuidado de endereço antigo casa com este prefixo de roteamento. • Verifica que o cuidado de endereço antigo corresponde com a chave pública e com os parâmetros de CGA na mensagem remetida. • Opcionalmente, verifica a assinatura.
Deveria ser notado que este método requer recursos e adiciona proteção só no caso onde o roteador de acesso antigo não pode ser confiado completamente, tanto porque é impossível implementar classificação de pacote digna de confiança baseada no endereço de fonte de túnel (devido a falta de filtragem de ingresso), ou porque o nó móvel é de alguma maneira conhecido e confiado mais que o roteador de acesso antigo. Se o roteador de acesso antigo for confiado para enviar pacotes em túnel só se houver um nó móvel que seja provável de aparecer na nova ligação, o primeiro tal pacote enviado em túnel contém implicitamente uma indicação que mais tais pacotes são prováveis de vir, e que o nó móvel é provável aparecer. Porém, uma tal mensagem enviada em túnel não contém os parâmetros de CGA ou assinatura. Assim, a proteção adicional provida por este método é limitada. CGA sozinho não adiciona muito valor, como qualquer um pode gerar novos endereços de CGA.
Semelhantemente, a assinatura só adiciona uma garantia que o nó móvel (como identificado pela chave pública) pretendeu (uma vez) se mover da ligação de acesso antiga à nova. Porém, a assinatura não adiciona valor a menos que o nó móvel seja de alguma maneira mais confiado do que o roteador de acesso antigo, ou a menos que as reivindicações combinadas pelo nó móvel e pelo roteador de acesso sejam consideradas serem mais valiosas do que a reivindicação sozinha pelo roteador de acesso antigo.
Em resumo, o valor de passar as mensagens de estabelecimento de remessa, e usá-las para controlar alocação de recurso para enfileirar recursos no novo roteador de acesso depende do modelo de confiança exato e suposições de segurança subjacentes. O protocolo básico usa só uma mensagem, a mensagem de estabelecimento de remessa, enviada pelo nó móvel ao roteador de acesso antigo, tanto proativamente ou reativamente. A mensagem consiste em um cabeçalho de IPvó, cabeçalho de IPSec AH protegido por chave pública, e uma nova mensagem de ICMP como ilustrada na Figura 4. O cabeçalho de AH contém a chave pública, assinatura e parâmetros de CGA. Note que, como discutido abaixo, o endereço de fonte do pacote pode ser tanto o antigo ou o novo cuidado de endereço. Em qualquer caso, a assinatura de CGA e parâmetros são válidos. A nova mensagem de criação de Túnel de Remessa de ICMP contém o marco, a identidade do novo roteador de acesso, e o cuidado de endereço antigo. No caso proativo, este endereço deve ser idêntico ao endereço de fonte. No caso reativo, o endereço de fonte é o novo cuidado de endereço. Os novos conteúdos de mensagem de ICMP são descritos na Figura 5.
Os campos de IP são como segue: Endereço de Fonte: tanto o antigo ou o novo cuidado de endereço do nó móvel. Um endereço que pertence ao roteador de acesso antigo.
Campos de ICMP: Tipo TBD: A ser designado por IANA > para estabelecimento de remessa. Código: 0 Verificação de soma: Verificação de soma de ICMP
Identificador: Um inteiro sem sinal de 16 bits que é um identificador para ajudar a casar mensagens de estabelecimento de remessa e reconhecimentos, como explicado ademais abaixo.
Reservado Não utilizado. DEVE ser iniciado a zero pelo remetente e DEVE ser ignorado pelo receptor.
Opções obrigatórias: Marco: Opção de marco como definida em [Arkko, L, "Secure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-00 (trabalho em curso), fevereiro de 2003].
Identificação de Roteador de Acesso: Usado para identificar o novo roteador de acesso.
TBD
Outras opções: Cuidado de endereço: Contém o cuidado de endereço antigo do nó móvel. TBD. Esta opção DEVE ser usada no caso reativo.
Certificado: Opção de certificado, como definida em [Arkko, J., "Secure Neighbor Discovery (SEND)", draft-ietf-send-ipsec-00 (trabalho em curso), fevereiro de 2003].
Considerando agora o nó móvel proativo, este nó móvel executa as operações seguintes: • Escuta os marcos radiodifundidos pelo roteador de acesso antigo. Seria lógico incluir os marcos na mensagem de Aviso de Roteador. • Detecta que ele (quer dizer, o nó móvel) é provável se mover para um novo roteador de acesso no futuro muito próximo, e determina a identidade (provável) desse roteador de acesso. • Cria uma mensagem de criação de Túnel de Remessa de ICMP, usando o cuidado de endereço atual como o endereço de fonte e o endereço de IP do roteador de acesso antigo como o endereço de destino> contendo um número de identificador de mensagem fresco, o marco recebido mais recentemente, e a identidade (provável) do novo roteador de acesso. • Empacota a mensagem em um cabeçalho de AH, incluindo a chave pública do nó móvel, que os parâmetros de CGA usados, e uma assinatura através de todo o pacote. • Envia a mensagem ao roteador de acesso antigo.
Uma vez que o nó móvel detecte que realmente se moveu, e assumindo que o novo cuidado de endereço é o prefixado, inicia aceitando pacotes remetidos do roteador de acesso antigo.
No caso do nó móvel reativo, o nó móvel executa as operações seguintesC • Escuta os marcos radiodifundidos pelo roteador de acesso antigo. Novamente, é lógico incluir os marcos na mensagem de Aviso de Roteador. • Detecta que se moveu para um novo roteador de acesso. • Cria uma mensagem de criação de Túnel de Remessa de ICMP, usando o cuidado de endereço atual como o endereço de fonte e o endereço de IP do roteador de acesso antigo como o endereço de destino, contendo um número de identificador de mensagem fresco, o marco recebido mais recentemente, e a identidade (prefixo de roteamento) do novo roteador de acesso, e o cuidado de endereço antigo. • Empacota a mensagem em um cabeçalho de AH, incluindo a chave pública do nó móvel, os parâmetros de CGA usados, e uma assinatura através de todo o pacote. • Envia a mensagem ao roteador de acesso antigo. • Inicia aceitando pacotes remetidos do roteador de acesso antigo. O roteador de acesso antigo tem duas funções independentes: ciuiicuauieiuu uc patuic c ac icmctssa.
Pacotes são enfíleirados só antes de criação de túnel de remessa.
Se o roteador de acesso antigo detectar que um nó móvel se tomou inalcançável sem criar um túnel de remessa, ele pode iniciar enfileirando os pacotes enviados ao cuidado de endereço antigo, recursos permitindo. Os pacotes enfíleirados deveríam ser contidos só por um tempo limitado. O tempo de enfileiramento máximo é uma opção de configuração, cujo valor não deveria exceder 10 segundos. Se houver menos recursos disponíveis do que seria precisado para enfileirar todos os pacotes durante o tempo máximo, o roteador pode suprimir pacotes enfíleirados. O algoritmo de supressão é uma opção de implementação local.
Quando o roteador de acesso antigo recebe uma mensagem de criação de Túnel de Remessa de ICMP, primeiro executa as operações seguintes, em alguma ordem dependente de implementação: • Verifica que a mensagem é visada ao nó direito. Isto é normalmente executado automaticamente pela camada de IP. • Verifica que o marco na opção de ICMP está fresco, isto é, tanto o mais recentemente radiodifundido ou o imediatamente antes disso. Se não, suprime silenciosamente a mensagem. • Extraí o cuidado de endereço antigo tanto do campo de endereço de fonte no cabeçalho de IP, ou da opção de cuidado de endereço antiga de ICMP. • Verifica que o prefixo de roteamento no cuidado de endereço antigo casa com o prefixo de roteamento usado na ligação antiga. Se não casar, suprime silenciosamente a mensagem. • Verifica se ainda há uma entrada de 'cache' de vizinha para o cuidado de endereço antigo. Se não houver nenhuma tal entrada de 'cache' de vizinha, o procedimento continua à próxima etapa. Se houver uma tal entrada e se a mensagem foi recebida do cuidado de endereço antigo, opcionalmente verifica que o endereço de MAC de fonte casa com o na entrada de 'cache' de vizinha. Se não casar, suprime o pacote. Se a mensagem fosse recebida de algum outro endereço de IP, ele ativa a Detecção de Incapacidade de Alcance de Vizinho (NUD) em direção ao nó descrito na entrada de 'cache' de vizinha. Se NUD mostrar que o nó é inalcançável, o procedimento continua, caso contrário, a mensagem é suprimida. • Verifica que o cuidado de endereço antigo está construído corretamente da chave pública e dos parâmetros de CGA. No caso proativo, esta etapa pode ser executada como uma parte de processamento de AH. Se a verificação falhar, a mensagem é suprimida silenciosamente. • Verifica a assinatura. No caso proativo, esta etapa é executada tipicamente como uma parte de processamento de AH. Se a verificação falhar, a mensagem é suprimida silenciosamente. • Verifica que a dada identidade do novo roteador de acesso é uma válida. O propósito desta etapa é proteger redes inocentes contra nós móveis maliciosos que criam túneis de remessa cujo outro ponto final é um falso.
Note que a ordem na qual as operações são executadas pode diferir de uma implementação para outra. Porém, a ordem acima é acreditada ser mais resistente à negação de serviço do que muitas das outras ordens possíveis.
Depois de verificar as mensagens, o roteador de acesso inicia remessa, como segue: • Computa o novo cuidado de endereço usando o prefixo de roteamento do novo roteador de acesso, a chave pública do nó móvel, e os parâmetros de CGA. • Se a mensagem de criação de Túnel de Remessa de ICMP não foi recebida do cuidado de endereço antigo, verifica que o endereço de fonte de IP na mensagem casa com o novo cuidado de endereço computado.
Se não casar, suprime a mensagem, registra uma advertência, e não cria o túnel. • Se a mensagem de criação de Túnel de Remessa de ICMP fosse recebida do cuidado de endereço antigo, opcionalmente espera para o nó móvel se tomar inalcançável. • Inicia remetendo todos os pacotes cujo endereço de destino é o cuidado de endereço antigo. Empacota tais pacotes em um cabeçalho de túnel cujo endereço de fonte é um endereço de IP do roteador de acesso antigo, e o endereço de destino do novo cuidado de endereço, e passa estes pacotes de volta à rede por fios, a serem entregues ao novo roteador de acesso. Se houver qualquer pacote enfileirado, destinado para este cuidado de endereço antigo, passa esses pacotes primeiro. • Ao mesmo tempo, inicia remetendo pacotes em túnel cujo endereço de fonte exterior é o novo cuidado de endereço e endereço de destino é o roteador de acesso antigo. Ao desempacotar esta mensagem, o roteador de acesso antigo DEVE verificar que o endereço de fonte interna casa com o cuidado de endereço antigo. Isto cria efetivamente um túnel inverso, permitindo ao nó móvel enviar pacotes com seu cuidado de endereço . antigo.
Além de suas operações normais, a única coisa que o novo roteador de acesso precisa fazer é enfileirar no caso proativo. Diferente disso, o novo roteador de acesso atua como um roteador de acesso exatamente como antes. Porém, note que a maioria de roteadores de acesso atuará ambos nos papéis de roteador de acesso antigo e roteador de acesso novo, frequentemente e simultaneamente. Isto deve ser cuidado na implementação. O novo roteador de acesso pode iniciar enfileiramento quando recebe um pacote remetido, destinado a um endereço local que não tem uma entrada de 'cache' de vizinho. Para ser mais específico, o novo roteador de acesso atua como segue: Quando o roteador de acesso recebe pacotes da rede por fios, inspeciona sua 'cache' de vizinho, e se houver uma entrada 'cache' de vizinho correspondendo ao endereço de destino, entrega o pacote.
Se não houver nenhuma entrada 'cache' de vizinho correspondente, o roteador de acesso inicia procedimento de descoberta de vizinho como definido em REC2461.
Se o roteador de acesso tiver recursos disponíveis para pacotes enfileirados, o roteador de acesso a seguir inspeciona o pacote mais cuidadosamente, classificando-o baseado em seu cabeçalho. Enquanto os critérios de classificação exatos são específicos de implementação, os critérios seguintes são sugeridos: • Se o pacote for um remetido, e o endereço de fonte exterior pertencer a um roteador de acesso conhecido (e confiado), ao pacote é dada uma prioridade de enfileiramento mais alta que caso contrário. • Se o cabeçalho de túnel for protegido por integridade (por exemplo, modo de túnel de ESP), ao pacote é dada prioridade de enfileiramento mais alta que se o cabeçalho de túnel não fosse protegido por integridade. • Qualquer pacote enfileirado deveria ser suprimido depois de um tempo. O tempo de enfileiramento máximo é um parâmetro de configuração, cujo valor não deveria exceder 10 segundos. • Se houver menos recursos disponíveis do que seria precisado para enfileirar todos os pacotes recebidos durante o tempo máximo, não há nenhuma outra opção que suprimir alguns pacotes. O algoritmo de supressão é uma opção de implementação local. • Se uma nova entrada 'cache' de vizinho for criada, as filas são verificadas para ver se há qualquer pacote destinado àquele endereço. Se houver, os pacotes enfileirados são entregues imediatamente, Nesta seção nós descrevemos brevemente algumas variações do método básico. As variações são descritas explicando como elas diferem do método básico.
• Usando certificados em vez de CGA
Pode ser útil usar certificados em vez de CGA. Neste caso, todos os roteadores de acesso participantes devem ter um terceiro confiado comum (ou um conjunto de tais partes) que emitem certificados.
Cada nó móvel deve ter um tal certificado, e o certificado deve incluir a chave pública e identificador de interface do nó móvel. Por exemplo, cartões de interface de rede poderíam conter um par d chaves e certificado emitido pelo fabricante para o endereço de MAC do cartão. Em vez de computar os identificadores de interface dinamicamente, como por CGA, os identificadores de interface são estáticos neste método. Um cuidado de endereço é formado simplesmente concatenando o prefixo de roteamento e o identificador de interface, como dado no certificado. Porém, para propósitos de privacidade, também é possível usar alguma derivada criptográfica do prefixo de roteamento e o identificador de interface original como o identificador de interface. Por exemplo, alguém pode computar uma função de reedição através do prefixo de roteamento e do identificador de interface original, e então usar bits do resultado de função de reedição como o identificador de interface atual.
Em vez de passar os parâmetros de CGA no cabeçalho de AH, o nó móvel deve passar o certificado como uma opção de ICMP. Também, em vez de verificar que o endereço casa com a chave pública e parâmetros de CGA, o roteador de acesso antigo verifica que o identificador de interface casa com o dado no certificado. Adicionalmente, o roteador de acesso antigo deve verificar a assinatura no certificado e se certificar que o emissor de certificado está confiado no contexto. • Remetendo pacotes para várias ligações novas Em vez de remeter proativamente os pacotes ao novo roteador de acesso mais provável, o roteador de acesso antigo pode enviar em túnel simultaneamente os pacotes para vários novos roteadores de acesso prováveis. Isto é possível, por exemplo, se os roteadores de acesso compartilharem informação topológica e geográfica, permitindo-os "adivinhar" quais são os roteadores de acesso próximos mais prováveis que o nó móvel é provável de chegar. Deve ser notado que este método usa mais recursos que outros métodos, como o roteador de acesso antigo criará múltiplas cópias dos pacotes, e os pacotes serão enviados em túnel em vários possíveis novos roteadores de acesso. Este método pode ser aumentado pelo nó móvel enviando uma mensagem de criação de túnel de remessa reativa uma vez que tenha chegado à nova ligação atual, permitindo ao roteador de acesso cessar a remessa dos pacotes para todos exceto o novo roteador de acesso atual. • Estabelecimento de remessa autônomo Estabelecimento de túnel autônomo pelo roteador de acesso antigo é possível se o roteador de acesso antigo for capaz de detectar quando o nó móvel partiu, e o roteador de acesso antigo é capaz de adivinhar, com uma probabilidade alta suficiente, o novo roteador de acesso provável (ou roteadores) que o nó móvel vai usar. Em estabelecimento de remessa autônomo, nem endereços de CGA nem certificados são precisados tipicamente. E suficiente para os roteadores de acesso compartilharem uma associação de segurança. Recursos permitindo, o roteador de acesso antigo pode ser capaz de usar um grupo de novos roteadores de acesso prováveis em vez de um único, e iniciar remetendo pacotes para todos estes. Porém, isto toma mais recursos que caso contrário é precisado. • Suportando classes de QoS explícitas em enfileiramento No método básico é sugerido que os pacotes sejam enfileirados igualmente, com a possível exceção do novo roteador de acesso classificando pacotes baseado em qual tipo de cabeçalho de envio em túnel eles tem.
Porém, se for possível usar classificação de qualidade de serviço nos pacotes, e ajustar os algoritmos de enfileiramento apropriadamente. • Desempacotando o cabeçalho de túnel no novo roteador de acesso É possível aumentar o desempenho da ligação de acesso no novo roteador de acesso removendo o cabeçalho de túnel no novo roteador de acesso. O novo roteador de acesso apenas enviaria o pacote ao endereço de MAC do nó móvel, mas ainda mantería o cuidado de endereço antigo como o endereço de fonte. • Várias mensagens de reconhecimento No método básico, o nó móvel envia simplesmente a mensagem de criação de Túnel de Remessa de ICMP. Não há nenhuma mensagem de reconhecimento. Há duas razões para isto. Primeiramente, mantém o método simples. Em segundo lugar, no caso proativo, é improvável que o nó móvel seria capaz de receber um reconhecimento antes que se mova, e no caso reativo iniciando para receber mensagens remetidas, atua como um reconhecimento implícito. Assim, de um ponto de vista prático, adicionar r reconhecimentos não acrescenta muito valor ao protocolo. E certamente possível porém, adicionar mensagens de reconhecimento ao protocolo. O campo de identificador de mensagem na mensagem de ICMP permite aos reconhecimentos e pedidos de criação de túnel de remessa serem casados entre si. Nós não vemos qualquer razão para proteger explicitamente os reconhecimentos, como eles são informativos; isto é, eles não criam nenhum estado real. • Usando cuidado de endereço antigo como endereço de fonte em caso reativo No método básico, a mensagem de criação de Túnel de Remessa de ICMP reativa é enviada usando o novo cuidado de endereço como o endereço de fonte no cabeçalho de IP. Porém, se a rede permitir ao nó móvel usar o cuidado de endereço antigo até mesmo no caso reativo, isso simplificaria processamento no roteador de acesso antigo. Tecnicamente, não há nenhuma razão por que o cuidado de endereço antigo não podería ser usado; a pergunta é puramente se os possíveis filtros de endereço de fonte na rede passariam o pacote toda vez da nova ligação ao roteador de acesso antigo. • Simplificações com Protocolo de Identidade de Hospedeiro (HIP) Se o método for usado junto com o Protocolo de Identidade de Hospedeiro (HIP), o cabeçalho de túnel pode ser substituído com reescrita de endereço de IP simples. Quer dizer, o cuidado de endereço antigo no campo de destino no cabeçalho de IP é substituído simplesmente com o novo cuidado de endereço. Como HIP usa HITs em somas de verificação de camada superior em vez de endereços de IP, a substituição não afeta protocolos de camada superior. Porém, o novo roteador de acesso pode precisar ser mais cuidadoso com seus algoritmos de classificação de fila. Há um caso onde o método presente pode produzir desempenho não ótimo. Se o nó móvel executar criação de túnel de remessa proativa, os pacotes enviados em túnel são enfileirados no novo roteador de acesso. Isto é baseado na suposição que isto conduzirá a entrega de pacote mais rápida uma vez que o nó móvel chegue à nova ligação. Porém, é possível que o novo roteador de acesso tenha nenhum ou menos recursos de enfileiramento a sua disposição que o roteador de acesso antigo tem. Nesse caso específico, produziría melhor desempenho se os pacotes fossem enfileirados no roteador de acesso antigo em vez do novo. Porém, incluindo um tal esquema no presente método seria uma solução de engenharia que melhoraria o desempenho em um caso raramente ocorrendo, às custas de complexidade muito mais alta e requisitos de estado.
REIVINDICAÇÕES

Claims (24)

1. Método de remeter pacotes de Protocolo de Internet (IP), enviados para um cuidado de endereço antigo de um nó móvel, para o nó móvel seguindo uma transferência de passagem do nó móvel de um primeiro roteador de acesso antigo para um segundo novo roteador de acesso, o método caracterizado pelo fato de compreender: antes de conclusão de dita transferência de passagem, prover dito primeiro roteador ou outro nó de procuração com informação necessária para determinar o novo cuidado de endereço de IP a ser usado pelo nó móvel quando o nó móvel é transferido ao segundo roteador de acesso; em dito primeiro roteador ou dito nó de procuração, determinar o novo cuidado de endereço para o nó móvel usando dita informação, e confirmar propriedade do novo cuidado de endereço pelo nó móvel; e remeter subseqüentemente pacotes recebidos em dita primeira rede de acesso e destinados para dito cuidado de endereço antigo, para o endereço de cuidado de endereço predito.
2. Método de acordo com reivindicação 1, caracterizado pelo fato de que dito nó de procuração atua como uma procuração de nível de Protocolo de Internet para o nó móvel, fazendo dito primeiro roteador de acesso acreditar que o nó móvel ainda não se moveu.
3. Método de acordo com reivindicação 1 ou 2, caracterizado pelo fato de que dita etapa de determinar um novo cuidado de endereço para o nó móvel inclui predizer esse endereço na base de um ou mais componentes.
4. Método de acordo com reivindicação 3, caracterizado pelo fato de que dita etapa de predizer o novo cuidado de endereço é executada em resposta ao nó móvel notificando o primeiro roteador ou nó de procuração que se moveu ou está prestes a se mover.
5. Método de acordo com reivindicação 4, caracterizado pelo fato de que o nó móvel envia a notificação ao primeiro roteador de acesso da ligação conectada ao roteador de acesso antigo.
6. Método de acordo com reivindicação 4, caracterizado pelo fato de que o nó móvel envia a notificação ao primeiro roteador de acesso da ligação conectada ao segundo roteador de acesso.
7. Método de acordo com qualquer uma das reivindicações 4 a 6, caracterizado pelo fato de que o primeiro roteador de acesso ou nó de procuração confirma a oportunidade de dita notificação antes de remeter pacotes para o novo cuidado de endereço.
8. Método de acordo com reivindicação 7, e caracterizado pelo fato de compreender determinar a oportunidade de dita notificação usando um marco enviado periodicamente pelo primeiro roteador de acesso e ecoado de volta na notificação.
9. Método de acordo com qualquer uma das reivindicações precedentes, e caracterizado pelo fato de compreender enfileirar, no segundo roteador de acesso, pacotes de IP remetidos do primeiro roteador de acesso até que o nó móvel apareça na nova ligação e a resolução de endereço necessária e outros procedimentos tenham sido completados para assegurar que o segundo roteador de acesso e o nó móvel possam trocar pacotes.
10. Método de acordo com qualquer uma das reivindicações precedentes, e caracterizado pelo fato de compreender enfileirar, no primeiro roteador de acesso, pacotes destinados ao cuidado de endereço antigo do nó móvel até que o primeiro roteador de acesso seja capaz de determinar o novo cuidado de endereço do nó móvel.
11. Método de acordo com reivindicação 9 ou 10, caracterizado pelo fato de que uma fila é estabelecida para o nó móvel em um roteador de acesso dependendo da relação de confiança existindo entre esse roteador de acesso e o outro roteador de acesso e/ou o nó móvel.
12. Método de acordo com reivindicação 11, caracterizado pelo fato de que o tamanho máximo da fila depende de ditas relações de confiança.
13. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que dita etapa de predizer o novo cuidado de endereço é probabilística e pode falhar.
14. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que a etapa de predizer o novo cuidado de endereço inclui aplicar um procedimento que é conhecido e compreendido por nós móveis e roteadores de acesso.
15. Método de acordo com reivindicação 14, caracterizado pelo fato de que dito procedimento usa endereços gerados através de criptografia.
16. Método de acordo com reivindicação 14, caracterizado pelo fato de que dito procedimento faz uso de certificados.
17. Método de acordo com reivindicação 15, caracterizado pelo fato de que dita etapa de determinar um novo cuidado de endereço inclui usar a chave pública de um par de chaves pública-privada pertencendo ao nó móvel para gerar o novo cuidado de endereço, e dita etapa de confirmar propriedade do novo cuidado de endereço pelo nó móvel inclui gerar uma mensagem assinada no nó móvel com a chave privada, e enviar essa mensagem assinada ao primeiro roteador de acesso.
18. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que dito novo cuidado de endereço é um de uma pluralidade de cuidado de endereços preditos pelo primeiro roteador de acesso, o primeiro roteador de acesso remetendo pacotes para cada um dos cuidado de endereços preditos.
19. Método de acordo com qualquer uma das reivindicações precedentes, e caracterizado pelo fato de compreender, seguindo a predição do novo cuidado de endereço pelo primeiro roteador ou pelo nó de procuração, enviar um pedido de estabelecimento de túnel do primeiro roteador para o segundo roteador, e remeter subseqüentemente pacotes pelo túnel estabelecido.
20. Método de acordo com reivindicação 17, caracterizado pelo fato de que o segundo roteador de acesso verifica a relevância de pedidos de estabelecimento de túnel enviando periodicamente um marco para escutar nós móveis, dito nó móvel escutando este marco quando varre uma nova ligação e o incluindo em sua notificação para o primeiro roteador de acesso, o primeiro roteador de acesso incluindo o marco na mensagem de estabelecimento de túnel.
21. Roteador de acesso para uso em uma rede de acesso comutada por pacote e caracterizado pelo fato de compreender: meio para determinar um cuidado de endereço futuro para um terminal móvel atualmente ou recentemente conectado ao roteador de acesso e para confirmar propriedade do novo cuidado de endereço pelo nó móvel; meio para remeter pacotes enviados ao terminal móvel em um cuidado de endereço associado com o roteador de acesso, para dito cuidado de endereço.
22. Roteador de acesso de acordo com reivindicação 21, e caracterizado pelo fato de compreender meio para estabelecer um túnel entre o roteador de acesso e um segundo roteador de acesso associado com o cuidado de endereço futuro predito.
23. Nó móvel para uso no método como definido em qualquer uma das reivindicações 1 a 20, e caracterizado pelo fato de compreender meio para notificar ao primeiro roteador de acesso que o nó móvel está prestes ou se transferiu para um novo roteador de acesso.
24. Método de remeter pacotes de IP, enviados para um cuidado de endereço antigo de um nó móvel, para o nó móvel seguindo uma transferência de passagem do nó móvel de um primeiro roteador de acesso antigo para um segundo novo roteador de acesso, o método caracterizado pelo fato de compreender: antes de conclusão de dita transferência de passagem, prover dito primeiro roteador ou outro nó de procuração com informação necessária para predizer o novo cuidado de endereço de IP a ser usado pelo nó móvel quando o nó móvel é transferido ao segundo roteador de acesso; em dito primeiro roteador ou dito nó de procuração, predizer o novo cuidado de endereço para o nó móvel usar dita informação; e remeter subseqüentemente pacotes recebidos em dita primeira rede de acesso e destinados para dito cuidado de endereço antigo, para o endereço de cuidado de endereço predito.
BRPI0410612A 2003-06-03 2004-03-22 método de remeter pacotes de protocolo de internet, roteador de acesso para uso em uma rede de acesso comutada por pacote, e, nó móvel para uso no método BRPI0410612B8 (pt)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB0312681.0A GB0312681D0 (en) 2003-06-03 2003-06-03 IP mobility
PCT/EP2004/050342 WO2004107702A1 (en) 2003-06-03 2004-03-22 Ip mobility

Publications (3)

Publication Number Publication Date
BRPI0410612A BRPI0410612A (pt) 2006-06-20
BRPI0410612B1 true BRPI0410612B1 (pt) 2017-05-30
BRPI0410612B8 BRPI0410612B8 (pt) 2017-06-13

Family

ID=9959207

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0410612A BRPI0410612B8 (pt) 2003-06-03 2004-03-22 método de remeter pacotes de protocolo de internet, roteador de acesso para uso em uma rede de acesso comutada por pacote, e, nó móvel para uso no método

Country Status (8)

Country Link
US (3) US7535870B2 (pt)
EP (1) EP1636964B1 (pt)
CN (1) CN1799241B (pt)
AT (1) ATE472219T1 (pt)
BR (1) BRPI0410612B8 (pt)
DE (1) DE602004027804D1 (pt)
GB (1) GB0312681D0 (pt)
WO (1) WO2004107702A1 (pt)

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004077205A2 (en) * 2003-02-26 2004-09-10 Nokia Corporation A method of reducing denial-of-service attacks and a system as well as an access router therefor
GB0312681D0 (en) * 2003-06-03 2003-07-09 Ericsson Telefon Ab L M IP mobility
US20050235065A1 (en) * 2004-04-15 2005-10-20 Nokia Corporation Method, network element, and system for providing security of a user session
US8619701B2 (en) * 2004-05-03 2013-12-31 Core Wireless Licensing S.A.R.L. Method of facilitating handoff for CDMA networks using IP protocols
JP4423118B2 (ja) * 2004-06-08 2010-03-03 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム、アクセスルータ、管理装置及び移動通信方法
US20080031183A1 (en) * 2004-09-30 2008-02-07 Matsushita Electric Industrial Co., Ltd. Communication Network Management Method, Access Router, And Mobile Communication Device
KR100651715B1 (ko) * 2004-10-07 2006-12-01 한국전자통신연구원 차세대 인터넷에서 자동으로 주소를 생성하고 수락하는방법 및 이를 위한 데이터 구조
US8098626B2 (en) * 2005-01-28 2012-01-17 Panasonic Corporation Packet transfer control method, communication message processing method, access router, and mobile terminal
US7925027B2 (en) * 2005-05-02 2011-04-12 Ntt Docomo, Inc. Secure address proxying using multi-key cryptographically generated addresses
US8169966B2 (en) * 2005-06-01 2012-05-01 Telefonaktiebolaget L M Ericsson (Publ) Method and a network node for managing handovers in a packet data communication environment
US20060274672A1 (en) * 2005-06-06 2006-12-07 Narayanan Venkitaraman System and method for reducing unnecessary traffic in a network
US7532597B2 (en) * 2005-06-15 2009-05-12 Motorola, Inc. Method and apparatus to facilitate handover
FR2888078B1 (fr) * 2005-06-30 2007-08-10 Alcatel Sa Procede de transfert d'une communication impliquant un noeud mobile en situation de macro-mobilite au sein d'un reseau de communication ip a routage hierarchique
WO2007004051A1 (en) * 2005-07-06 2007-01-11 Nokia Corporation Secure session keys context
ATE518334T1 (de) * 2006-01-23 2011-08-15 Ericsson Telefon Ab L M Kommunikationsnetzzugang
US7653813B2 (en) * 2006-02-08 2010-01-26 Motorola, Inc. Method and apparatus for address creation and validation
US7839815B2 (en) * 2006-02-10 2010-11-23 Alcatel-Lucent Usa Inc. Triggering migration of a network access agent associated with an access terminal
JP2010503244A (ja) * 2006-09-06 2010-01-28 パナソニック株式会社 通信システム及びモバイルルータ並びにホームエージェント
JP4864797B2 (ja) * 2006-09-11 2012-02-01 Kddi株式会社 P−cscf高速ハンドオフシステム及びp−cscf高速ハンドオフ方法
US8112803B1 (en) * 2006-12-22 2012-02-07 Symantec Corporation IPv6 malicious code blocking system and method
US7953044B2 (en) * 2007-02-16 2011-05-31 Futurewei Technologies, Inc. Method, component and system for network-based handover
US8014357B2 (en) 2007-02-16 2011-09-06 Futurewei Technologies, Inc. Method and system for managing address prefix information associated with handover in networks
KR101336325B1 (ko) * 2007-03-16 2013-12-03 삼성전자주식회사 이동국에 투명한 고속 핸드오버를 지원하는 통신 장치 및방법
CN101304365B (zh) * 2007-05-08 2012-12-12 华为技术有限公司 认证方法和认证系统
US7990925B2 (en) * 2007-05-30 2011-08-02 Qualcomm Incorporated Method and apparatus for communication handoff
US8289862B2 (en) * 2007-06-27 2012-10-16 Futurewei Technologies, Inc. Method and apparatus for dynamic LMA assignment in proxy mobile IPv6 protocol
KR100964350B1 (ko) * 2007-09-14 2010-06-17 성균관대학교산학협력단 IPv6 환경에서의 SEND와 IPSec 협업 기법 및시스템
ATE543325T1 (de) * 2007-09-20 2012-02-15 Ericsson Telefon Ab L M Ortskodierung in einem kommunikationsnetzwerk
US8411866B2 (en) * 2007-11-14 2013-04-02 Cisco Technology, Inc. Distribution of group cryptography material in a mobile IP environment
GB2454897A (en) * 2007-11-22 2009-05-27 Ericsson Telefon Ab L M Cryptographically generated IP addresses
CN101547383B (zh) * 2008-03-26 2013-06-05 华为技术有限公司 一种接入认证方法及接入认证系统以及相关设备
US8225400B2 (en) * 2008-05-13 2012-07-17 Verizon Patent And Licensing Inc. Security overlay network
WO2010003113A1 (en) * 2008-07-03 2010-01-07 The Trustees Of Columbia University In The City Of New York Methods and systems for controlling traffic on a communication network
EP2166724A1 (en) 2008-09-23 2010-03-24 Panasonic Corporation Optimization of handovers to untrusted non-3GPP networks
WO2010045977A1 (en) * 2008-10-23 2010-04-29 Telefonaktiebolaget Lm Ericsson (Publ) Mobility handling for multicast services
US8520580B2 (en) * 2009-04-24 2013-08-27 Aruba Networks, Inc. Synchronization of mobile client multicast membership
US9049653B2 (en) * 2009-07-02 2015-06-02 Futurewei Technologies, Inc. Handover in core-edge separation technology in wireless communications
US8411666B1 (en) * 2009-11-13 2013-04-02 Sprint Communications Company L.P. Location-based geographical routing
US8953798B2 (en) * 2010-10-29 2015-02-10 Telefonaktiebolaget L M Ericsson (Publ) Enhanced cryptographically generated addresses for secure route optimization in mobile internet protocol
US20140019754A1 (en) * 2011-03-21 2014-01-16 Thomson Licensing Anonymous and unlinkable distributed communication and data sharing system
CN103108375A (zh) * 2011-11-14 2013-05-15 中兴通讯股份有限公司 一种切换过程中路由优化的方法及系统及接入网元
JP5716712B2 (ja) * 2012-07-24 2015-05-13 横河電機株式会社 パケット転送装置及び方法
US9537818B2 (en) * 2013-05-15 2017-01-03 Mediatek Inc. Enhanced DHCP method
EP3079310B1 (en) * 2014-01-26 2017-09-20 Huawei Technologies Co., Ltd. Data packet sending method and mobile router
US10333696B2 (en) 2015-01-12 2019-06-25 X-Prime, Inc. Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency
US10051000B2 (en) * 2015-07-28 2018-08-14 Citrix Systems, Inc. Efficient use of IPsec tunnels in multi-path environment
US10142903B2 (en) 2016-12-07 2018-11-27 Wistron Neweb Corporation Inter-domain handover method and system for user equipment and relay gateway device
US10966091B1 (en) * 2017-05-24 2021-03-30 Jonathan Grier Agile node isolation using packet level non-repudiation for mobile networks
CN109842918B (zh) * 2017-11-24 2020-09-08 华为技术有限公司 一种无线通信的方法和装置
US10938652B1 (en) * 2019-08-20 2021-03-02 Hughes Network Systems, Llc Gateway diversity switching
US11575612B2 (en) * 2021-06-07 2023-02-07 Cisco Technology, Inc. Reducing packet misorderings in wireless networks

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6603972B1 (en) * 1999-08-26 2003-08-05 Lucent Technologies Inc. Apparatus, method and system for voice communication hand-off in a mobile packet data network environment
US7353027B2 (en) 2000-10-18 2008-04-01 Telefonaktiebolaget Lm Ericsson (Publ) Seamless handoff in mobile IP
US20030211842A1 (en) * 2002-02-19 2003-11-13 James Kempf Securing binding update using address based keys
US7031709B2 (en) * 2002-04-05 2006-04-18 Ntt Docomo, Inc. Method and associated apparatus for increment accuracy of geographical foreign agent topology relation in heterogeneous access networks
JP2004015143A (ja) * 2002-06-04 2004-01-15 Fujitsu Ltd 移動通信システムにおけるハンドオーバ方法、および移動通信システムにおいて使用されるルータ装置
GB0312681D0 (en) * 2003-06-03 2003-07-09 Ericsson Telefon Ab L M IP mobility

Also Published As

Publication number Publication date
US8009631B2 (en) 2011-08-30
US8644256B2 (en) 2014-02-04
CN1799241B (zh) 2010-09-29
WO2004107702A1 (en) 2004-12-09
EP1636964B1 (en) 2010-06-23
BRPI0410612A (pt) 2006-06-20
US20090285181A1 (en) 2009-11-19
GB0312681D0 (en) 2003-07-09
DE602004027804D1 (de) 2010-08-05
US20110274091A1 (en) 2011-11-10
US20060274693A1 (en) 2006-12-07
CN1799241A (zh) 2006-07-05
US7535870B2 (en) 2009-05-19
ATE472219T1 (de) 2010-07-15
EP1636964A1 (en) 2006-03-22
BRPI0410612B8 (pt) 2017-06-13

Similar Documents

Publication Publication Date Title
BRPI0410612B1 (pt) método de remeter pacotes de protocolo de internet, roteador de acesso para uso em uma rede de acesso comutada por pacote, e, nó móvel para uso no método
Johnson et al. Mobility support in IPv6
Johnson et al. RFC 3775: Mobility support in IPv6
EP2589197B1 (en) Method and devices for a light-weight security solution for host-based mobility and multihoming protocols
JP4705673B2 (ja) ネットワーク管理方法及びネットワーク管理装置
US8413243B2 (en) Method and apparatus for use in a communications network
Deng et al. Defending against redirect attacks in mobile IP
JP2010507301A (ja) ネットワーク・ベース及びホスト・ベースの混合モビリティ管理における方法
BRPI0614316A2 (pt) método de autenticação em um nó móvel, de um primeiro anúncio recebido de um ponto de acesso, e, nó móvel
JP2010527549A (ja) ネットワーク・ベースおよびホスト・ベース混合型のモビリティ管理における方法
JP5250634B2 (ja) 移動通信ネットワークにおいて使用するための方法及び装置
US8819790B2 (en) Cooperation method and system between send mechanism and IPSec protocol in IPV6 environment
Li et al. Mobile IPv6: protocols and implementation
Koskiahde Security in Mobile IPv6
Hossain et al. Security vulnerabilities and protection mechanisms of mobility management protocols
Tripathi et al. Security issues in mobile IPv6
Kuang et al. Investigating enhanced route optimization for mobile IPv6
Johnson et al. RFC 6275: Mobility Support in IPv6
Arkko IETF Mobile IP Working Group D. Johnson Internet-Draft Rice University Expires: July 21, 2003 C. Perkins Nokia Research Center
Jo et al. Secure Route Optimization for Network Mobility Using Secure Address Proxying
Roe et al. Status of this Memo
Arkko IETF Mobile IP Working Group D. Johnson Internet-Draft Rice University Expires: October 30, 2003 C. Perkins Nokia Research Center
Arkko IETF Mobile IP Working Group D. Johnson Internet-Draft Rice University Expires: November 24, 2003 C. Perkins Nokia Research Center
Arkko IETF Mobile IP Working Group David B. Johnson INTERNET-DRAFT Rice University Charles E. Perkins Nokia Research Center
Durr et al. An analysis of security threats to mobile IPv6

Legal Events

Date Code Title Description
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]
B16C Correction of notification of the grant [chapter 16.3 patent gazette]
B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 19A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2715 DE 17-01-2023 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.