BRPI0610269A2 - método e aparelho para usar o protocolo de identidade de hospedeiro, e, programa operacional - Google Patents

Abstract

MéTODO E APARELHO PARA USAR O PROTOCOLO DE IDENTIDADE DE HOSPEDEIRO, E, PROGRAMA OPERACIONAL. Um método é provido de usar o protocolo de identidade de hospedeiro, HIP, para estabelecer uma conexão entre um segundo hospedeiro (32) e um receptáculo de aplicativo (42) em um primeiro hospedeiro (30), incluindo estabelecer uma nova ou selecionar uma associação de segurança de HIP existente (46) entre o primeiro e segundo hospedeiros (30, 32), criar uma nova ou selecionar uma associação de tubo existente (44), identificada por um identificador de tubo, entre o receptáculo de aplicativo (42) e a associação de segurança (46), formar uma associação (43, 45) para a conexão entre o receptáculo de aplicativo (42), a associação de segurança (46) e a associação de tubo (44), por esse meio estabelecendo uma conexão entre o segundo hospedeiro (32) e o receptáculo de aplicativo (42) no primeiro hospedeiro (30) pela associação de segurança (46) e associação de tubo (44).

Description

"MÉTODO E APARELHO PARA USAR O PROTOCOLO DE IDENTIDADE DE HOSPEDEIRO, E, PROGRAMA OPERACIONAL" FUNDAMENTO DA INVENÇÃO

1. Campo da Invenção

A presente invenção relaciona-se a um Método e Aparelho de Protocolo de Identidade de Hospedeiro.

2. Descrição da Arte Relacionada

Quando a Internet foi idealizada originalmente, hospedeiros eram fixos em localização e havia confiança implícita entre usuários apesar da falta de segurança real ou protocolos de identificação de hospedeiro, e esta situação continuava até mesmo no entendimento mais amplo e uso da tecnologia. Havia poucas técnicas precisadas a considerar para lidar com mobilidade de hospedeiro desde que computadores eram relativamente vultosos e imóveis.

Com a revolução na indústria de telecomunicações e computadores no início de 1990, equipamento de comunicação e computadores menores se tornaram mais amplamente disponíveis e a invenção da 'World Wide Web', e todos os serviços que emergiram com isto, finalmente fez a Internet atraente para a pessoa comum. A combinação de uso crescente da rede e telecomunicações móveis criou a necessidade por administração de mobilidade segura na Internet.

O número crescente de partes envolvidas, e as transações monetárias que eram precisadas para certos serviços, também criava uma necessidade por segurança de nível de aplicativo adicionada. Atualmente, os protocolos de criptografia mais amplamente usados, por exemplo SSL/TLS, estão correndo dentro das camadas de rede superiores, por exemplo TCP.

Levando em conta os assuntos de administração de mobilidade e segurança anteriores, o padrão de IP Móvel (C. Perkins, "IP Mobility Support for IPv4", RFC 3220, IETF, 2002) e o padrão de IPv6 Móvel (D. Johnson, C. Perkins, J. Arkko, "Mobility Support IPv6", RFC3775, IETF, 2004) foram introduzidos. Juntas estas especificações são planejadas para prover suporte de mobilidade para a Internet geração de próxima. Trabalho de segurança está se desenvolvendo na forma de IPsec, e atividades relacionadas, tais como vários protocolos de troca de chave, com o objetivo sendo prover segurança na camada de IP. Porém, experiência mostrou que é bastante difícil alcançar segurança e mobilidade combinadas usando os padrões atuais.

Um endereço de IP descreve um local topológico de um nó na rede. O endereço de IP é usado para rotear o pacote do nó de fonte para o destino. Ao mesmo tempo, o endereço de IP também é usado para identificar o nó, provendo duas funções diferentes em uma entidade. Isto é familiar a uma pessoa respondendo com seu endereço doméstico quando perguntado quem são eles. Quando mobilidade também é considerada, a situação se torna até mesmo mais complicada: desde que endereços de IP atuam como identificadores de hospedeiro neste esquema, eles não devem ser mudados; porém, desde que endereços de IP também descrevem locais topológicos, eles devem necessariamente mudar quando um hospedeiro muda seu local na rede. Claramente, é impossível alcançar ambas estabilidade e mudanças dinâmicas ao mesmo tempo.

No caso de IP Móvel, a solução é usar um local doméstico fixo provendo um "endereço doméstico" para o nó. O endereço doméstico ambos identifica o nó e provê um local estável para ele quando está em casa. A informação de local atual está disponível na forma de um cuidado de endereço, que é usado para propósitos de roteamento quando o nó está longe de casa.

Outra solução para o problema é separar as funções de identificação e localização uma da outra, e esta é a abordagem levada na proposta de Protocolo de Identidade de Hospedeiro (HIP) (R. Moskowitz, P. Nikander, P. Jokela, nHost Identity Protocol", Minuta da Internet, produção em curso, draft-ietf-hip-base-05, IETF, 2006). HIP separa os papéis de localização e identidade de endereços de IP introduzindo um novo espaço de nome, a Identidade de Hospedeiro (HI). Em HIP, a Identidade de Hospedeiro é basicamente uma chave criptográfica pública de uma par de chaves pública- privada, e é gerada da e ligada à chave privada. A chave pública identifica a parte que contém a única cópia da chave privada. Um hospedeiro possuindo a chave privada do par de chaves pode provar diretamente que "possui" a chave pública que é usada para identificá-la na rede. A separação também provê um meio para operar mobilidade e 'multi-homing' de um modo seguro.

HIP é discutido em mais detalhe abaixo, mas não é a única proposta baseada ao redor da idéia de localização e separação de identidade. FARA (D. Clark, R. Braden, A. Falk, V. Pingali, mFARA: Reorganizing the Addressing Architecture", Seminários de ACM SIGCOMM 2003, 25 e 27 de agosto de 2003), é um modelo generalizado de idéias que provêem uma estrutura da qual a arquitetura atual pode ser derivada. FARA poderia fazer uso do HIP quando as identificações de nó são verificadas, e conseqüentemente HIP poderia fazer parte de um caso de FARA particular. A proposta de 'PeerNet1 (J. Eriksson, M. Faloutsos, S. Krishnamurthy, "PeerNet: Pushing Peer-to-Peer Down the Stack", IPTPS' 03, 20-21 de fevereiro de 2003) também discute a localização e separação de identidade. A Infra- estrutura de Procedimento Indireto da Internet, I (I. Stoica, et. al., "Internet Indirection Infrastructure", ACM SIGCOMM Ό2, 19-23 de agosto de 2002) também define uma separação entre a informação de identidade e roteamento.

O Protocolo de Identidade de Hospedeiro introduz uma separação entre a informação de localização e identidade na camada de IP. Além da separação, um protocolo é definido para negociar associações de segurança (SAs) entre nós habilitados para HIP.

Com HIP, cada hospedeiro tem uma ou mais identidades, que podem ser de longo prazo ou curto prazo, que podem ser usadas para identificá-la na rede. Com HIP3 um identificador é a chave pública de um par de chaves pública-privada. Quando o hospedeiro possui a chave privada, ele pode provar que na verdade "possui" esta identidade que a chave pública representa; isto é familiar a mostrar um cartão de ID.

Cada hospedeiro pode gerar chaves a curto prazo a serem usadas só por pouco tempo. Estas são úteis quando não é necessário para o nó ser identificado com a mesma identidade mais tarde. Por exemplo, comprar livros de uma livraria pode ser uma relação de longo prazo, enquanto contatar um servidor uma vez para coletar perfis de usuário pode ser considerado uma ação de curto prazo. No caso anterior, uma identidade de curto prazo pode ser criada para evitar disseminação mais difundida da identidade de longo prazo.

A Identidade de Hospedeiro de HIP (HI), sendo uma chave pública, pode ser bastante longa e é portanto não viável em todas as situações. Em HIP, o HI é representado com uma Etiqueta de Identidade de Hospedeiro (HIT) de 128 bits de comprimento, que é gerada do HI reeditando-a. Assim, o HIT identifica um HI. Desde que o HIT é de 128 bits de comprimento, ele pode ser usado para aplicações de IPvó diretamente como é exatamente o mesmo comprimento como endereços de IPvó.

Outra representação das Identidades de Hospedeiro é o Identificador de Extensão Local (LSI), que é uma representação de 32 bits para a Identidade de Hospedeiro. O propósito do LSI é facilitar usar Identidades de Hospedeiro em protocolos existentes e APIs. Por exemplo, desde que o LSI é o mesmo comprimento como um endereço de IPv4, ele pode ser usado para aplicações de IPv4 diretamente. Embora muito do resto desta descrição será baseado ao redor do uso do HIT mais longo, será apreciado que as mesmas considerações ou semelhantes se aplicam à representação de LSI alternativa.

Quando HIP é usado, as camadas superiores, incluindo os aplicativos, já não vêem mais o endereço de IP. Ao invés, elas vêem o HIT como o "endereço" do hospedeiro de destino. A informação de localização é escondida a uma nova camada, a ser descrita abaixo. Os endereços de IP já não mais identificam os nós; eles só são usados para rotear os pacotes na rede.

Aplicativos tipicamente não estão interessados em informação de localização, mas precisam saber sua identidade de seus pares. A identidade é representada pelo HIT. Isto significa que o endereço de IP só tem importância em camadas inferiores onde roteamento está preocupado. Os HITs que os aplicativos usam, devem ser mapeados aos endereços de IP correspondentes antes que qualquer pacote deixe o hospedeiro. Isto é alcançado em uma nova Camada de Identidade de Hospedeiro como descrito abaixo.

Figura 1 dos desenhos acompanhantes ilustra as várias camadas em HIP, incluindo a camada de transporte padrão 4, camada de rede 8 e camada de ligação 10, com um processo 2 se comunicando com a camada de transporte 4 debaixo dela. Com HIP, uma nova Camada de Identidade de Hospedeiro 6 está disposta entre a camada de transporte 4 e a camada de rede 8.

Localmente, cada HI e seu HIT associado são mapeados aos endereços de IP do nó. Quando pacotes estão deixando o hospedeiro, a rota correta é escolhida (por qualquer meio) e endereços de IP correspondentes são postos no pacote como os endereços de fonte e destino. Cada pacote chegando da camada superior contém o HIT do par como o endereço de destino. O mapeamento entre o HIT e a informação de localização podem ser achado na camada de HI 6. Conseqüentemente, o endereço de destino é convertido ao endereço de IP mapeado, e o HIT de fonte é convertido a endereço de fonte de IP.

O mapeamento entre um HIT de par e endereço de IP pode ser recuperado de vários modos, um dos quais sendo de um servidor de DNS. A informação de localização pode ser atualizada pelo nó de par a qualquer momento. O procedimento de atualização será discutido em mais detalhe abaixo.

HIP define uma troca de mensagem básica contendo quatro mensagens, um aperto de mão de quatro vias, e isto é usado para criar uma associação de segurança (SA) entre hospedeiros habilitados para HIP. Durante a troca de mensagem, o procedimento de Diffie-Hellman é usado para criar uma chave de sessão e estabelecer um par de Associações de Segurança (SAs) de Carga Util de Segurança Encapsuladora de IPsec (ESP) entre os nós.

Figura 2 dos desenhos acompanhantes ilustra a operação do aperto de mão de quatro vias. As partes negociantes são chamadas o Iniciador, começando a conexão, e o Respondedor. O Iniciador começa a negociação enviando um pacote de Il que contém os HITs dos nós participando na negociação. O HIT de destino também pode ser zerado, se o HIT do Respondedor não for conhecido pelo Iniciador.

Quando o Respondedor adquire o pacote de II, ele envia de volta um pacote de Rl que contém um enigma a ser resolvido pelo Iniciador. O protocolo é projetado de forma que o Iniciador deve fazer a maioria do cálculo durante a resolução de enigma. Isto dá alguma proteção contra ataques de DoS. O Rl também inicia o procedimento de DifTie-Hellman, contendo a chave pública do Respondedorjunto com os parâmetros de Diffie-Hellman.

Uma vez que o pacote de Rl seja recebido, o Iniciador resolve o enigma e envia um 'cookie' de resposta em um pacote de 12 junto com um valor de SPI de IPsec e sua chave pública codificada para o Respondedor. O Respondedor verifica que o enigma foi resolvido, autentica o Iniciador e cria os SAs de ESP de IPsec. A mensagem de R2 final contém o valor de SPI do Respondedor.

Os SAs entre os hospedeiros são ligados às Identidades de Hospedeiro, representadas pelos HITs. Porém, os pacotes viajando na rede não contêm a informação de HI atual, mas o pacote de chegada é identificado e mapeado ao SA correto usando o valor de índice de Parâmetro de Segurança (SPI) no cabeçalho de IPsec. Figura 3 dos desenhos acompanhantes mostra as estruturas de pacote lógico e atual quando viaja na rede.

Do anterior está claro que mudar a informação de localização no pacote não cria nenhum problema para o processamento de IPsec. O pacote ainda é identificado corretamente usando o SPI. Se, por alguma razão, o pacote for roteado para um destino errado, o receptor não é capaz de abrir o pacote como não tem a chave correta.

Quando um pacote de partida chega na camada de HI da camada anterior, o HIT de destino é verificado do SADB de IPsec. Se um SA casando com o HIT de destino for achado, o pacote é codificado usando a chave de sessão associada com o SA.

O HIT não pode ser usado para rotear o pacote. Assim, os endereços de destino (e fonte) devem ser mudados para casar com os endereços de IP dos nós. Estes mapeamentos são armazenados, como mencionado anteriormente, na camada de HI. Depois que os endereços foram mudados, o pacote pode ser enviado à rede, onde é roteado ao destino usando a informação de endereço de IP.

No hospedeiro receptor, o valor de SPI é usado para achar o SA correto do SADB de IPsec. Se uma entrada for achada, os endereços de IP podem ser mudados a HITs correspondentes e o pacote pode ser decifrado usando a chave de sessão.

Mobilidade é definida ser a situação onde um hospedeiro se move enquanto mantendo seu contexto de comunicação ativo, ou em outras palavras, o hospedeiro muda seu local topológico, descrito pelo endereço de IP, enquanto ainda mantendo todas as conexões existentes ativas. Os processos correndo no hospedeiro não vêem a mobilidade, exceto possivelmente se a qualidade experimentada de serviço mudar.

O hospedeiro móvel pode mudar a localização dentro de uma rede de acesso, entre tecnologias de acesso diferentes, ou até mesmo entre reinos de endereço de IP diferentes, por exemplo entre as redes de IPv4 e IPv6. Em HIP, o aplicativo não nota a mudança na versão de endereço de IP. A camada de HI esconde a mudança completamente de camadas superiores. Certamente, o nó de par deve ser capaz de operar a atualização de localização que muda a versão de IP e pacotes devem ser dirigíveis usando algum endereço compatível. Se um nó não tiver ambas conectividade de IPv4 e IPv6, ele pode usar um nó de procuração que executa a conversão de versão de endereço e provê conectividade em nome do nó.

'Multi-homing' se refere a uma situação onde um ponto final tem vários caminhos de comunicação paralelos que pode usar. Normalmente, 'multi-homing' é um resultado tanto de se o hospedeiro tendo várias interfaces de rede ('multi-homing' de hospedeiro final) ou devido a uma rede entre o hospedeiro e o resto da rede tendo caminhos redundantes ('multi-homing' local).

Com HIP, a separação entre a informação de localização e identidade faz clarear que a identificação de pacote e roteamento pode ser separada completamente entre si. O hospedeiro recebendo um pacote identifica o remetente primeiro adquirindo a chave correta e então decifrando o pacote. Assim, os endereços de IP que estão no pacote são irrelevantes.

Um Nó Móvel de HIP (HMN), se movendo na rede, pode mudar o ponto de conexão à Internet constantemente. Quando o ponto de conexão é mudado, assim faz o endereço de IP. Esta informação de localização mudada deve ser enviada aos nós de par, isto é, Nós Correspondentes de HIP (HCN), e isto é ilustrado na Figura 4 dos desenhos acompanhantes. O mesmo endereço também pode ser enviado a um Agente de Remessa (FA) do HMN, de forma que o HMN possa ser alcançado também por um ponto mais estável. O sistema de DNS é lento demais para ser usado para mudar constantemente informação de localização. Portanto, deve haver um endereço mais estável que pode ser usado para contatar o HMN. Este endereço é o endereço provido pelo FA.

O protocolo de Mobilidade de HIP e 'Multi-homing' (P. Nikander, J. Arkko, P. Jokela, "End-Host Mobility and Multihoming with Host Identity Protocol", Minuta da Internet, produção em curso, draft-ietf- HIP-mm-03, IETF, 2006) define um pacote de atualização (ATUALIZAÇÃO) que leva o "parâmetro de localizador" (conhecido como o parâmetro de re-endereço (REA) em Minutas da Internet anteriores) que contém o endereço de IP atual do HMN. Quando o HMN muda localização e endereço de IP, ele gera um pacote de ATUALIZAÇÃO, sinaliza o pacote com a chave privada casando com o HI usado, e envia o pacote ao nó de par e ao FA.

Quando o nó de par recebe um pacote de ATUALIZAÇÃO, deve começar um processo de verificação de endereço para o endereço de IP que está incluído no pacote de ATUALIZAÇÃO. A verificação de endereço é precisada para evitar aceitar atualizações falsas do HMN. Envia um pacote de reconhecimento de atualização (ATUALIZAÇÃO-ACK) para o endereço que estava no pacote de ATUALIZAÇÃO. Quando o HMN recebe um ATUALIZAÇÃO-ACK que casa com a ATUALIZAÇÃO enviada anteriormente, pode começar usando o novo endereço de IP para enviar dados para HCN. Depois que o nó de par recebeu o primeiro pacote de dados do novo endereço, a verificação de endereço é completada e pode adicionar o endereço de IP como a informação de localização do HMN.

Porque o HMN pode se mover entre redes usando versões de endereço de IP diferentes, o endereço recebido pelo HCN também pode ser de uma família de endereços diferente do endereço prévio.

O HCN pode suportar só uma versão de endereço de IP. Neste caso, o HCN deve usar algum outro nó de procuração que pode ser usado para rotear pacotes para a outra rede de versão de endereço de IP. Um hospedeiro de HIP 'multi-homed', tendo múltiplos endereços de IP configurados em diferentes interfaces conectadas a redes de acesso diferentes, tem muito mais possibilidades para operar o tráfego para um nó de par. Como tem múltiplos endereços de IP apresentando sua localização atual na rede, pode querer contar todos estes endereços para seus nós de par. Para fazer assim, o nó de HIP 'multi-homed' cria um pacote de ATUALIZAÇÃO, que contém todos os endereços que é capaz de usar para aquele nó particular. Este conjunto de endereços pode conter todos os endereços que tem, ou algum subconjunto destes endereços. Quando o nó de par recebe o pacote de ATUALIZAÇÃO com os múltiplos endereços, ele deve fazer a verificação de endereço para cada um destes endereços para evitar possíveis atualizações falsas.

Endereços falsos ou não dirigíveis no pacote de ATUALIZAÇÃO podem ser causados tanto porque o HMN é um nó malicioso, tem um erro na implementação de pilha, ou o HMN pode estar dentro de uma rede que usa endereços privados que não são dirigíveis na Internet.

Um nó de HIP 'multi-homed' é capaz de usar todas das conexões disponíveis, mas uso eficiente das conexões requer um sistema de política que tenha conhecimento das redes de acesso subjacentes e possa controlar o uso delas. Tal sistema de política pode usar tipos diferentes de informação: preferências de usuário, preferências de operador, entradas das conexões de rede, tal como QoS, e assim por diante.

A fim de começar a troca de HIP com um nó móvel, o nó de iniciador precisa saber como alcançar o nó móvel. Embora DNS Dinâmico pudesse ser usado para esta função para nós moveis não freqüentemente, uma alternativa a usar DNS deste modo é usar o pedaço de infra-estrutura estática introduzida acima, o Agente de Remessa (também chamado um servidor de encontro de HIP). Em vez de registrar seu endereço dinâmico atual com o servidor de DNS, o nó móvel registra os endereços de seus Agentes de Remessa. O nó móvel mantém os Agentes de Remessa atualizados continuamente com seus endereços de IP atuais. Um Agente de Remessa simplesmente remete o pacote de HIP inicial de um iniciador para o nó móvel em sua localização atual. Todos os pacotes adicionais fluem entre o iniciador e o nó móvel. Tipicamente há muito pouca atividade em um Agente de Remessa, principalmente atualizações de endereço e remessa de pacote de HIP inicial. Assim, um Agente de Remessa pode suportar um grande número de nós móveis potenciais. Os nós móveis devem se confiar no Agente de Remessa para manter corretamente seus mapeamentos de endereço de HIT e IP. Um Agente de Remessa pode ser usado até mesmo para nós que são fixos em localização, desde que é freqüentemente o caso que nós fixos podem mudar seu endereço de IP freqüentemente, por exemplo quando é alocado a cada vez que uma conexão de Internet é estabelecida por um Provedor de Serviço para aquele nó.

O Agente de Remessa também é precisado se ambos dos nós forem móveis e acontece se moverem ao mesmo tempo. Nesse caso, pacotes de re-endereço de HIP cruzarão um ao outro na rede e nunca alcançarão o nó de par. Para resolver esta situação, os nós deveriam lembrar do endereço de Agente de Remessa, e re-enviar o pacote de re-endereço de HIP ao Agente de Remessa se nenhuma resposta for recebida.

O nó móvel mantém seu endereço atual no Agente de Remessa estabelecendo uma associação de HIP com o Agente de Remessa e enviando pacotes de atualização de HIP, contendo re-endereço, para isto. Um Agente de Remessa permitirá a dois sistemas móveis usarem HIP sem qualquer infra- estrutura estranha (além do próprio Agente de Remessa), incluindo DNS se eles tiverem um método diferente de uma pergunta de DNS para adquirir HI e HIT um do outro.

No caso de equipamento de legado, um hospedeiro pode não ser habilitado para HIP, e a única opção é identificar conexões entre hospedeiros usando endereços de IP. Isto não é seguro. A situação pode ser melhorada localizando uma procuração de HIP entre o hospedeiro habilitado para HIP e o hospedeiro que não pode usar HIP. Um cenário típico seria uma pequena LAN corporativa onde os terminais de cliente não são habilitados para HIP. Tráfego é roteado para hospedeiros correspondentes (que são habilitados para HIP) pela procuração de HIP.

Este arranjo é ilustrado na Figura 5 dos desenhos acompanhantes. Na Figura 5, um hospedeiro de legado 12 é mostrado se comunicando com um nó habilitado para HIP 14 (tendo o nome de domínio "hip.foo.com") por uma procuração de HIP 16. O hospedeiro de legado 12 acessa a procuração de HIP 16 através de uma rede de acesso 18, enquanto a procuração de HIP 16 acessa o nó de HIP 14 através da Internet 20. Para reter parcialmente a conexão entre o hospedeiro de legado 12 e o nó de HIP 14, todas as comunicações entre a procuração de HIP 16 e o nó de HIP 14 são por uma Associação de Segurança estabelecida entre a procuração de HIP 16 e o nó de HIP 14 de um modo semelhante àquele descrito acima com referência à Figura 3.

Porém, até mesmo antes que a Associação de Segurança 22 mostrada na Figura 5 possa ser estabelecida para habilitar comunicação entre o hospedeiro de legado 12 e o nó de HIP 14, um problema surge quando o hospedeiro de legado 12 tenta solucionar o endereço de IP do nó de HIP 14 enviando uma pergunta a um servidor de DNS 24-1 (e por sua vez servidor de DNS 24-2) quando o nó de HIP 14 está localizado atrás de um Agente de Remessa 26 como descrito acima. O servidor de DNS 24-1 retornará para o HIT do nó de HIP 14 junto com o endereço de IP do Agente de Remessa 26. Como o hospedeiro de legado 12 não está habilitado para HIP, ele desconsiderará o HIT e começará enviando mensagens ao Agente de Remessa 26. Sem o HIT, o Agente de Remessa 26 não será capaz de solucionar o endereço de destino destas mensagens desde que é mais provável que vários nós de HIP usarão o mesmo Agente de Remessa 26. Igualmente, desde que o hospedeiro de legado 12 descarta o HIT e usa só o endereço de IP do nó de HIP 14 ao iniciar uma conexão, a procuração de HIP 16 é incapaz de iniciar negociação de HIP entre si mesmo e o nó de HIP 14 porque não conhece o HIT do nó de HIP 14. Este problema é tratado em nosso Pedido PCT N0 PCT/EP04/050129.

Outras considerações técnicas surgem ao implementar HIP em redes de telecomunicações móveis de terceira geração (3G), onde nem todos os Equipamentos de Usuário (UEs) no ambiente de 3G estão habilitados para HIP. Neste contexto, o Sistema de Telecomunicações Móvel Universal (UMTS) é o sucessor de 3G para o Sistema Global para Comunicações Móveis (GSM). O passo evolutivo mais importante de GSM para UMTS é o Serviço de Rádio de Pacote Geral (GPRS). GPRS introduz comutação de pacote na rede de núcleo de GSM e permite acesso direto a redes de dados de pacote (PDNs). Isto habilita transmissão comutada por pacote de alta taxa de dados bem além do limite de 64 kbps de ISDN pela rede de núcleo de GSM, que é uma necessidade para taxas de transmissão de dados de UMTS até 2 Mbps. GPRS é um pré-requisito para a introdução de UMTS. Princípios semelhantes são igualmente aplicáveis a UMTS como eles são para GPRS. GPRS foi projetado como uma extensão à infra-estrutura de rede de GSM existente, com o objetivo de prover um serviço de dados de pacote sem conexão. GPRS introduz vários novos elementos funcionais através de GSM que suportam o transporte de ponta a ponta de dados de pacote baseados em IP.

Dificuldades técnicas até agora estão impedindo o uso de mobilidade baseada em fluxo, e é desejável superar pelo menos algumas destas dificuldades técnicas.

De acordo com um primeiro aspecto da presente invenção, é provido um método de usar o Protocolo de Identidade de Hospedeiro, HIP, para estabelecer uma conexão entre um segundo hospedeiro e um receptáculo de aplicativo em um primeiro hospedeiro, incluindo estabelecer um novo ou selecionar uma Associação de Segurança de HIP existente entre o primeiro e segundo hospedeiros, criar um novo ou selecionar uma Associação de Tubo existente, identificada por um Identificador de Tubo, entre o receptáculo de aplicativo e a Associação de Segurança, formar uma associação para a conexão entre o receptáculo de aplicativo, a Associação de Segurança e a Associação de Tubo, por esse meio estabelecendo uma conexão entre o segundo hospedeiro e o receptáculo de aplicativo no primeiro hospedeiro pela Associação de Segurança e Associação de Tubo.

O receptáculo de aplicativo pode incluir uma porta.

O receptáculo de aplicativo pode incluir um HIT ou LSI.

O receptáculo de aplicativo pode incluir um endereço de IP.

O método pode incluir comunicar informação ao segundo hospedeiro relativa à associação de conexão.

A informação de associação de conexão pode ser comunicada em uma mensagem de ATUALIZAÇÃO de HIP.

A informação de associação de conexão pode ser comunicada durante negociação de HIP entre o primeiro e segundo hospedeiros para estabelecer uma nova Associação de Segurança.

A informação de associação de conexão pode incluir primeira informação relativa à associação ou mapeamento entre o identificador de Tubo e o receptáculo.

A informação de associação de conexão pode incluir segunda informação relativa à associação entre o identificador de Tubo e um SPI.

A primeira e segunda informações podem ser enviadas como parâmetros de HIP separados.

Os parâmetros de HIP relativos à primeira e segunda informações podem ser parâmetros de TUPO INFO e SATUINFO, respectivamente.

O método pode incluir enviar a informação de associação de conexão em resposta a uma mudança em políticas das conexões ativas.

O método pode incluir enviar a informação de associação de conexão em resposta a uma mudança em políticas da administração de política de camada superior.

O primeiro hospedeiro pode ser 'multi-homed', incluindo várias interfaces de rede por quais uma Associação de Segurança pode ser estabelecida para o segundo hospedeiro.

O segundo hospedeiro também pode ser 'multi-homed'.

Uma Associação de Tubo existente pode ser selecionada no caso onde uma Segurança Associada existente também é selecionada.

O método pode incluir criar uma nova Associação de Tubo selecionando e duplicando uma Associação de Tubo existente.

O método pode incluir estabelecer uma política para a Associação de Tubo que é compatível com uma política estabelecida no segundo hospedeiro.

O método pode incluir criar Associações de Tubo duplicadas.

As Associações de Tubo duplicadas podem ser respectivamente para tráfego de chegada e de partida.

Uma única Associação de Segurança pode ser associada com a Associação de Tubo.

Uma pluralidade de Associações de Segurança pode ser associada com a Associação de Tubo.

Uma pluralidade de Associações de Segurança e Associações de Tubo pode ser criada com antecedência, e a Associação de Segurança e Associação de Tubo podem ser selecionadas destas.

Pelo menos alguma da informação relativa à Associação de Tubo pode ser administrada no primeiro hospedeiro.

De acordo com um segundo aspecto da presente invenção, é provido um aparelho para usar o Protocolo de Identidade de Hospedeiro, HIP, para estabelecer uma conexão entre hospedeiro remoto e um receptáculo de aplicativo no aparelho, incluindo meio para estabelecer um novo ou selecionar uma Associação de Segurança de HIP existente entre o aparelho e o hospedeiro remoto, meio para criar uma nova ou selecionar uma Associação de Tubo existente, identificada por um Identificador de Tubo, entre o receptáculo de aplicativo e a Associação de Segurança, meio para formar uma associação para a conexão entre o receptáculo de aplicativo, a Associação de Segurança e a Associação de Tubo, por esse meio estabelecendo uma conexão entre o hospedeiro remoto e o receptáculo de aplicativo no aparelho pela Associação de Segurança e Associação de Tubo.

De acordo com um terceiro aspecto da presente invenção, é provido um programa operacional que, quando carregado em um aparelho, faz o aparelho se tornar aparelho de acordo com o segundo aspecto da presente invenção.

De acordo com um quarto aspecto da presente invenção, é provido um programa operacional que, quando corrido em um aparelho, faz o aparelho efetuar um método de acordo com o primeiro aspecto da presente invenção.

O programa operacional pode ser levado em um meio de portador. O meio de portador pode ser um meio de transmissão. O meio de portador pode ser um meio de armazenamento.

BREVE DESCRIÇÃO DOS DESENHOS

Figura 1, discutida anteriormente, ilustra as várias camadas no Protocolo de Identidade de Hospedeiro;

Figura 2, também discutida anteriormente, ilustra a operação do aperto de mão de quatro vias no protocolo de HIP; Figura 3, também discutida anteriormente, mostra as estruturas de pacote lógico e atual em HIP;

Figura 4, também discutida anteriormente, ilustra uma transferência de passagem entre IPv6 e IPv4;

Figura 5, também discutida anteriormente, é um diagrama esquemático ilustrando o estabelecimento de rede geral para comunicações entre hospedeiro de legado e um modo de HIP por uma procuração de HIP;

Figura 6 ilustra um exemplo de dois locais de hospedeiro em uma rede para uso em explicar uma concretização da presente invenção;

Figura 7 ilustra outro exemplo de dois locais de hospedeiro em uma rede para uso em explicar uma concretização da presente invenção;

Figura 8 ilustra esquematicamente uma concretização da presente invenção;

Figura 9 ilustra um parâmetro adicional usado em uma mensagem de ATUALIZAÇÃO em uma concretização da presente invenção;

Figura 10 ilustra um parâmetro adicional usado em uma mensagem de ATUALIZAÇÃO em uma concretização da presente invenção;

e

Cursores 1 a 25 contêm assunto relativo a uma concretização da invenção.

Como mencionado acima, o suporte de mobilidade em HIP é baseado em uma mensagem de ATUALIZAÇÃO, onde o hospedeiro móvel envia uma informação de atualização de localização ao hospedeiro de par. A atualização contém um novo mapeamento de endereço de HIT para IP que o hospedeiro de par usa para comunicação adicional com aquele hospedeiro usando este HIT.

Uma concretização da presente invenção propõe uma extensão para este protocolo, e introduz o conceito de um Tubo no hospedeiro final, com cada porta sendo mapeada a um certo Tubo. Um Tubo particular também mapeia a um certo par de Associação de Segurança de ESP criado entre hospedeiros através de um caminho de conexão particular, isto é, uma certa interface em ambas as pontas. (Atualmente, quando um hospedeiro de HIP perde uma interface e muda todas as conexões para outra interface, o par de SA de ESP antigo é removido, e um novo é criado através da nova interface.)

Em uma concretização da presente invenção, o pacote de ATUALIZAÇÃO, levando previamente a informação de endereço de IP, também é estendido com um parâmetro para levar os números da porta que estão associados com um certo ID de Tubo.

Figura 6 ilustra um exemplo de dois locais de hospedeiro em uma rede, incluindo um primeiro hospedeiro 30 e um segundo hospedeiro 32. O primeiro hospedeiro 30 é um MN 'multi-homed' e o segundo hospedeiro 32 é um CN de HIP. O MN 'multi-homed' 30 tem duas conexões separadas à Internet 20 por redes de acesso diferentes 18-1 e 18-2, e adiante para o CN de HIP 32. O Domínio de SIMA é explicado ademais abaixo.

A implementação de HIP básica opera a negociação de SA de ESP entre os nós 30 e 32, e geração de chave de sessão, para criar um SA entre os nós 30 e 32. O domínio de HIP (HIPD) cria os SAs de ESP nos bancos de dados de IPsec pertinentes.

Figura 7 ilustra outro exemplo de dois locais de hospedeiro em uma rede, incluindo primeiro hospedeiro 30 e um segundo hospedeiro 32. O primeiro hospedeiro 30 é um MN 'multi-homed' e o segundo hospedeiro 32 também é um MN 'multi-homed', em contraste com a Figura 6, onde o segundo hospedeiro 32 era um CN de HIP. O primeiro MN 'multi-homed' 30 tem duas conexões separadas à Internet 20 por redes de acesso diferentes 18-1 e 18-2 (definindo uma gama de acesso do primeiro MN 'multi-homed' 30), e o segundo MN 'multi-homed' 32 também tem duas conexões separadas à Internet 20 por redes de acesso diferentes 18-3 e 18-4 (definindo a gama de acesso do segundo MN 'multi-homed' 32). Na gráfico da Figura 7, os hospedeiros 30 e 32 podem definir sua preferência no uso de rede (isto é, definindo ID de Tubo e enviando mensagens de ATUALIZAÇÃO). Este cenário mais envolvido que a Figura 6 porque conectando portas 42 a Tubos 44 (agrupando, por exemplo, três aplicativos 40 para usar o mesmo Tubo 44) pode não ser aceitável para o outro hospedeiro 32, que pode requerer que algum dos aplicativos use um caminho diferente a sua ponta, em qual caso eles não podem ser agrupados da maneira proposta pelo MN 30. Uma solução seria permitir aos hospedeiros "negociarem" o rompimento de conexões de Tubo e permitir a um hospedeiro criar dois Tubos 44 semelhantes e também conectar aplicativos 40 separados a eles de forma que também case com os requisitos de par 32. Negociação só poderia ser para pôr porta - IDs de Tubo 43 entre um direção e respondendo com um novo conjunto de portas - IDs de Tubo 43 com duplicações requeridas de Tubos 44. Em uma solução mais envolvida, um Tubo 44 poderia ter múltiplas conexões aos SAs de ESP subjacentes 32.

Como mencionado acima, em uma concretização da presente invenção, um novo nível de abstração é introduzido: o Tubo. Isto será descrito agora em mais detalhe com referência à Figura 8, que corresponde ao cenário da Figura 6 no qual um MN 'multi-homed' 30 está se comunicando com CNs (Hospedeiros de Par) 32, mas a descrição é igualmente aplicável aqui ao cenário da Figura 7.

Figura 8 ilustra esquematicamente um MN 'multi-homed' 30 em comunicação com CNs (Hospedeiros de Par) 32. O MN 30 inclui uma pluralidade de aplicativos 40, e, desde que o MN 30 é 'multi-homed', uma pluralidade de interfaces de rede 48 à Internet (não mostrada) e os CNs 32. Figura 8 também mostra as associações entre Portas (ou Receptáculos) 42 associadas com os aplicativos 40, Tubos 44 e SAs de ESP 46.

Um Tubo 44 está localizado entre um SA de ESP 46 e uma porta de aplicativo ou receptáculo 42. A ligação entre uma porta ou receptáculo 42 e um Tubo 44 é dinâmica, como é a ligação entre um Tubo 44 e um SA de ESP 46. Cada Tubo 44 é nomeado a um ID de Tubo.

Ambos os nós de ponta 30 e 32 compartilham o mesmo ID de Tubo para um dado conjunto de conexões; conseqüentemente, o ID de Tubo é criado pelo iniciador e enviado ao nó de par. O iniciador dos Tubos 44 não é necessariamente o iniciador da conexão no senso de HIP. O Respondedor de HIP também pode ter múltiplas conexões, em qual caso o Respondedor de HIP poderia enviar o conjunto de conexões de porta-tubo-SA 43, 45 na mensagem de R2, ou mais tarde na mensagem de ATUALIZAÇÃO. Associações de tubo são geralmente específicas de hospedeiro, ou específicas de hospedeiro-hospedeiro relacionada a uma associação de HIP 46 entre os nós, e assim normalmente seria armazenada só nos hospedeiros finais. Um ID de Tubo normalmente seria único entre um par de hospedeiros. O domínio de validade do ID de Tubo é chamado "domínio de SIMA" (SIMA, Multi-acesso Simultâneo), como ilustrado nas Figuras 6 e 7.

Introduzir o conceito de um Tubo permite políticas mais simples serem usadas, desde que cada uma das portas ou receptáculos 42 (conexões) não tem que ter uma política sua própria.

Uma política é um conjunto de regras definindo a preferência de uso de rede que será aplicada a um grupo de conexões. As políticas podem ter aspectos diferentes dependendo do ponto de vista de partes diferentes do sistema. E o papel da máquina de política unificar isto. Do ponto de vista do aplicativo, um aplicativo criará uma política a ser aplicada a um receptáculo particular. Essa política ligará o receptáculo a uma lista de preferência entre o seguinte:

* uma lista de interfaces conhecidas;

* Localização de CN;

* uma propriedade de rede;

* tecnologia (GPRS, WLAN,...) * largura de banda?

* operador?

* Versão de IP?

Quando a política é "usada", por exemplo se houve mudanças no ambiente de rede e a nova instalação é testada com a política, o resultado é uma interface que será usada para remeter dados desse ponto adiante.

Uma distinção é feita entre políticas permanentes e efêmeras. Uma política efêmera é uma política que existe contanto que seja aplicada a um grupo de conexões. Assim, é destruída quando a última conexão usando aquela política é fechada. Tipicamente, este é o caso para uma política criada por um aplicativo para um receptáculo particular. Por outro lado, uma política permanente permanecerá no banco de dados de política até mesmo se nenhuma conexão ativa estiver fazendo uso dela. A política prefixada é um conjunto de políticas permanentes que são para serem usadas se nenhuma política particular for criada para uma conexão. Devido ao fato que políticas permanentes normalmente têm uma extensão larga, uma conexão pode casar várias políticas, conduzindo a uma colisão de política potencial. É portanto precisado priorizar as políticas entre si. Pode ou não ser permitido anular uma política permanente.

Na Figura 8, as associações 43, 45 entre as portas ou receptáculos 42, Tubos 44 e SAs de ESP 46 são mostradas. Cada porta ou receptáculo 42 está associado com um Tubo 44, e cada Tubo 44 está associado com um SA de ESP 46. Cada um dos Tubos 44 tem uma sua política própria, e a política define a interface a ser usada em situações diferentes. Assim, no nível de aplicativo, a política de Tubo pode ser conhecida e o aplicativo 40 pode ser conectado a um Tubo 44 com uma política adequada para as necessidades de aplicativos.

Para uma instalação de conexão com um novo hospedeiro 32, para qual nenhum Associação de HIP 46 já existe, uma nova associação de HIP 46 é criada primeiro com a troca de base de HIP habitual. Depois que o SA de ESP 46 é criado, um novo Tubo 44 também é criado. A porta ou receptáculo 42 que foi aberto para o aplicativo 40 é conectado agora a este novo Tubo 44.

Também é possível negociar múltiplos SAs de ESP 46 através de interfaces diferentes 44 e criar Tubos 44 relacionados com antecedência.

A informação de Porta - Tubo 43 e Tubo - SA 45 é comunicada ao nó de par em novos parâmetros de HIP, ou durante a troca de base ou mais tarde, usando mensagens de HIP de ATUALIZAÇÃO (SATUJNFO, TUPOJNFO).

Para uma instalação de conexão com um hospedeiro 32 onde uma associação de HIP 46 já existe, o sistema de política identifica e seleciona o Tubo 44 preferível a ser usado para este tipo de conexão. O porta 42 recentemente aberta é conectada ao Tubo 44. A informação de Porta - Tubo 43 atualizada é comunicada ao par 32 usando o novo parâmetro de HIP (TUPOJNFO).

No caso de 'multi-homing' duplo, quando ambos os hospedeiros 30 e 32 são 'multi-homed', pode acontecer que o conjunto de Porta - Tubo 43 proposto por um hospedeiro 30 não seja adequado para o hospedeiro de par 32 (por exemplo, o hospedeiro de par 32 pode requerer interfaces diferentes para estes aplicativos). Na primeira fase, pode ser operada de forma que o primeiro hospedeiro 30 crie uma duplicata do Tubo 44, copie as mesmas políticas para ambos os Tubos 44, e faça a compatibilidade com o hospedeiro de par 32 com este método. Também é possível que um Tubo 44 possa ser conectado a múltiplos SAs de ESP 46 simultaneamente (chamado um Multi-tubo ou MuTu); isto requereria uma política de mapeamento de pacote para lidar como o endereço de IP de destino correto é determinado.

Ligações assimétricas (enviando e recebendo por interfaces diferentes) também podem ser operadas usando semelhantemente Tubos 44 duplicados. A diferença é que a porta local 42 é conectada a dois Tubos 44; uma para tráfego de partida e um para tráfego de chegada. Para o par 32, só o par de Tubo de chegada - Porta 43 precisa ser comunicado (onde o par 32 envia dados), o outro par 45 não é precisado pelo par 32. Pacotes para o par 32 podem parecer vir de um endereço de fonte diferente, mas em HIP isto não importa, porque a identificação de pacote é baseada no HIT.

Mais informação relativa ao novo parâmetro de HIP será discutida agora.

O pacote de ATUALIZAÇÃO de HIP é definido para transferir a informação de endereço de IP mudada ao nó de par 32 de forma que o hospedeiro possa fazer um novo mapeamento de endereço de HIT para IP para o hospedeiro móvel 30. A presente concretização usa dois parâmetros adicionais bastante semelhantes para a mensagem de ATUALIZAÇÃO. Primeiro, um parâmetro é usado que conecta números da porta locais a um certo ID de Tubo, e segundo, um parâmetro é usado que conecta IDs de Tubo a um certo SPI.

Há pelo menos dois possíveis modos para incluir a informação de Tubo no novo parâmetro.

Primeiramente, o parâmetro poderia conter só a informação de política "efetiva" do hospedeiro 'multi-homed' 30. Isto significa que a informação não contém múltiplas escolhas para um identificador de conexão, mas só o ativo. Esta informação pode ser configurada diretamente na administração de política de IPsec. Isto é talvez mais simples para implementar, mas uma desvantagem potencial é que a informação de política deve ser enviada no parâmetro a cada vez que há uma mudança em políticas das conexões ativas.

Em segundo lugar, o parâmetro poderia conter o conjunto básico de políticas, incluindo múltiplas escolhas como interfaces de destino para cada um dos identificadores de conexão. Com esta solução, a informação de política precisa ser transmitida só quando há mudanças nas políticas atuais na administração de política de camada superior. Uma desvantagem potencial é que o CN 32 deve adquirir o conhecimento sobre a interface perdida, isto é, usando o pacote de ICMP recebido. E além disso, o hospedeiro 'multi-homed' 30 pode ter que ainda enviar a informação atualizada ao nó de par 32, caso contrário a informação de ligação de Tubo - SA de ESP 45 errada pode ainda no par 32 (no caso da conexão perdida nunca aparecer novamente).

Nesta concretização, um parâmetro de TUPO_INFO é usado para transmitir os mapeamentos de Porta - Tubo 43 para o hospedeiro de par 32. Cada uma das portas 42 pode ser conectada a um Tubo 44 e um Tubo 44 pode ter conexão a múltiplas portas 42. Para suportar separação bem granulada de conexões, ambos os números da porta e número de protocolo seriam incluídos no parâmetro. Um parâmetro de exemplo de TUPO_INFO é ilustrado na Figura 9.

Nesta concretização, um parâmetro de SATU_INFO é usado para transmitir Associação de Segurança de ESP e associações de Tubo 45. Cada um dos Tubos 44 pode, em um exemplo, ser conectado a um SA de ESP 46, identificado pelo valor de SPI. Um SA de ESP 46 pode ter múltiplos Tubos 44 conectados a ele. Um exemplo parâmetro de SATU_INFO é ilustrado na Figura 10.

Um sistema de multi-homing concretizando a presente invenção tira proveito do sistema de HIP básico com mensagem de ATUALIZAÇÃO e conecta o uso de interface múltipla à arquitetura divida de Identidade/Localizador. Uma concretização da presente invenção provê administração de mobilidade baseada em fluxo de um modo elegante e relativamente simples usando o Protocolo de Identidade de Hospedeiro. Adicionando informação às mensagens de ATUALIZAÇÃO de HIP sobre portas, protocolos, e (uma nova abstração) Tubos, conjuntos de informação podem ser criados que podem ser usados para roteamento baseado em fluxo correto de dados.

Será apreciado que a operação de um ou mais dos componentes acima descritos pode ser controlada por um programa operando no dispositivo ou aparelho. Tal programa operacional pode ser armazenado em um meio legível por computador, ou poderia, por exemplo, ser concretizado em um sinal tal como um sinal de dados carregável provido de um site da Internet. As reivindicações anexas são para serem interpretadas como cobrindo um programa operacional por si só, ou como um registro em um portador, ou como um sinal, ou em qualquer outra forma.

Uma pessoa qualificado na arte apreciará que concretizações da presente invenção não estão necessariamente limitadas a qualquer protocolo particular ou esquema de endereçamento para cada uma das camadas, por exemplo nas camadas de transporte ou rede, e funcionarão dentro da estrutura de HIP qualquer que seja o protocolo de endereçamento ou transporte usado ao redor dessa estrutura.

Claims (30)

1. Método para usar o Protocolo de Identidade de Hospedeiro, HIP, para estabelecer uma conexão entre segundo hospedeiro e um receptáculo de aplicativo em um primeiro hospedeiro, caracterizado pelo fato de que compreende estabelecer um novo ou selecionar uma Associação de Segurança de HIP existente entre o primeiro e segundo hospedeiros, criar um novo ou selecionar uma Associação de Tubo existente, identificada por um Identificador de Tubo, entre o receptáculo de aplicativo e a Associação de Segurança, formar uma associação para a conexão entre o receptáculo de aplicativo, a Associação de Segurança e a Associação de Tubo, por esse meio para estabelecer uma conexão entre o segundo hospedeiro e o receptáculo de aplicativo no primeiro hospedeiro pela Associação de Segurança e Associação de Tubo.

2. Método de acordo com a reivindicação I5 caracterizado pelo fato de que o receptáculo de aplicativo inclui uma porta.

3. Método de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que o receptáculo de aplicativo inclui um HIT ou LSI.

4. Método de acordo com a reivindicação I5 2 ou 3, caracterizado pelo fato de que o receptáculo de aplicativo inclui um endereço de IP.

5. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que compreende comunicar informação ao segundo hospedeiro relativa à associação de conexão.

6. Método de acordo com a reivindicação 5, caracterizado pelo fato de que a informação de associação de conexão é comunicada em uma mensagem de ATUALIZAÇÃO de HIP.

7. Método de acordo com a reivindicação 5 ou 6, caracterizado pelo fato de que a informação de associação de conexão é comunicada durante negociação de HIP entre o primeiro e segundo hospedeiros para estabelecer uma nova Associação de Segurança.

8. Método de acordo com a reivindicação 5, 6 ou 7, caracterizado pelo fato de que a informação de associação de conexão inclui primeira informação relativa à associação ou mapeamento entre o identificador de Tubo e o receptáculo.

9. Método de acordo com qualquer uma das reivindicações 5 a - 8, caracterizado pelo fato de que a informação de associação de conexão inclui segunda informação relativa à associação entre o identificador de Tubo e um SPI.

10. Método de acordo com a reivindicação 9, caracterizado pelo fato de que a primeira e segunda informações são enviadas como parâmetros de HIP separados.

11. Método de acordo com a reivindicação 10, caracterizado pelo fato de que os parâmetros de HIP relativos à primeira e segunda informações são parâmetros de TUPOJNFO e S ATUJNFO respectivamente.

12. Método de acordo com qualquer uma das reivindicações 5 a 11, caracterizado pelo fato de que compreende enviar a informação de associação de conexão em resposta a uma mudança em políticas das conexões ativas.

13. Método de acordo com qualquer uma das reivindicações 5 a 12, caracterizado pelo fato de que compreende enviar a informação de associação de conexão em resposta a uma mudança em políticas da administração de política de camada superior.

14. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que o primeiro hospedeiro é 'multi- homed', incluindo várias interfaces de rede por quais uma Associação de Segurança pode ser estabelecida para o segundo hospedeiro.

15. Método de acordo com a reivindicação 14, caracterizado pelo fato de que o segundo hospedeiro também é 'multi-homed'.

16. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que uma Associação de Tubo existente é selecionada no caso onde uma Segurança Associada existente também é selecionada.

17. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que compreende criar uma nova Associação de Tubo selecionando e duplicando uma Associação de Tubo existente.

18. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que compreende estabelecer uma política para a Associação de Tubo que seja compatível com uma política estabelecida no segundo hospedeiro.

19. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que compreende criar Associações de Tubo duplicadas.

20. Método de acordo com a reivindicação 19, caracterizado pelo fato de que Associações de Tubo duplicadas são respectivamente para tráfego de chegada e de partida.

21. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que uma única Associação de Segurança está associada com a Associação de Tubo.

22. Método de acordo com qualquer uma das reivindicações 1 a 20, caracterizado pelo fato de que uma pluralidade de Associações de Segurança está associada com a Associação de Tubo.

23. Programa operacional de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que uma pluralidade de Associações de Segurança e Associações de Tubo é criada com antecedência, e a Associação de Segurança e Associação de Tubo são selecionadas destas.

24. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que pelo menos alguma da informação relativa à Associação de Tubo é administrada no primeiro hospedeiro.

25. Aparelho para usar o Protocolo de Identidade de Hospedeiro, HIP, para estabelecer uma conexão entre hospedeiro remoto e um receptáculo de aplicativo no aparelho, caracterizado pelo fato de compreender meio para estabelecer uma nova ou selecionar uma Associação de Segurança de HIP existente entre o aparelho e o hospedeiro remoto, meio para criar uma nova ou selecionar uma Associação de Tubo existente, identificada por um Identificador de Tubo, entre o receptáculo de aplicativo e a Associação de Segurança, meio para formar uma associação para a conexão entre o receptáculo de aplicativo, a Associação de Segurança e a Associação de Tubo, por esse meio estabelecendo uma conexão entre o hospedeiro remoto e o receptáculo de aplicativo no aparelho pela Associação de Segurança e Associação de Tubo.

26. Programa operacional, caracterizado pelo fato de que, quando carregado em um aparelho, faz o aparelho se tornar aparelho como definido na reivindicação 25.

27. Programa operacional, caracterizado pelo fato de que, quando corre em um aparelho, faz o aparelho efetuar um método como definido em qualquer uma das reivindicações 1 a 24.

28. Programa operacional de acordo com a reivindicação 26 ou - 27, caracterizado pelo fato de ser levado em um meio de portador.

29. Programa operacional de acordo com a reivindicação 28, caracterizado pelo fato de que o meio de portador é um meio de transmissão.

30. Programa operacional de acordo com a reivindicação 28, caracterizado pelo fato de que o meio de portador é um meio de armazenamento.