BRPI0607515B1

BRPI0607515B1 - método para impedir fontes duplicadas em um protocolo de rede

Info

Publication number: BRPI0607515B1
Application number: BRPI0607515A
Authority: BR
Inventors: John Wierbowski David; Anne Porter Joyce; Hugh Overby Linwood Jr; Jakubik Patricia
Original assignee: Ibm
Priority date: 2005-04-11
Filing date: 2006-04-07
Publication date: 2020-04-22
Also published as: BRPI0607515A2; CA2602778C; JP2009532919A; US20060227807A1; CA2602778A1; TWI365651B; EP1872561B1; CN101156420A; WO2006108805A1; JP4766574B2; CN101156420B; US7656795B2; TW200708009A; EP1872561A1

Abstract

impedir fontes duplicadas de clientes servidos por um tradutor de porta de endereço de rede. impedir fontes duplicadas em uma conexão de protocolo que usa endereços de rede, protocolos e números de portas para identificar as aplicações de fonte que são servidas por um napt. se um pacote que chega encapsula um pacote codificado e passou por um napt em rota para o host de destino, o pacote encapsulado é descriptografado para obter um número de porta fonte original e um protocolo de pacote original do pacote descriptografado. uma tabela de mapeamento de porta fonte (spmt) é buscada por uma associação entre o endereço da fonte do napt, a porta original da fonte e o protocolo do pacote original associado com o endereço da fonte do napt e o número de porta. se uma associação incorreta é encontrada, o pacote é rejeitado como a representação de uma fonte duplicada ilegal; isto é, um segundo pacote de um host diferente servido por um napt que usando a mesma porta fonte e protocolo.

Description

(54) Título: MÉTODO PARA IMPEDIR FONTES DUPLICADAS EM UM PROTOCOLO DE REDE (51) Int.CI.: H04L 29/12; H04L 29/06.

(52) CPC: H04L 61/2517; H04L 29/12009; H04L 29/12377; H04L 63/0428; H04L 63/0272; (...).

(30) Prioridade Unionista: 11/04/2005 US 10/907,661.

(73) Titular(es): INTERNATIONAL BUSINESS MACHINES CORPORATION.

(72) Inventor(es): PATRICIA JAKUBIK; LINWOOD HUGH OVERBY JR; JOYCE ANNE PORTER; DAVID JOHN WIERBOWSKI.

(86) Pedido PCT: PCT EP2006061433 de 07/04/2006 (87) Publicação PCT: WO 2006/108805 de 19/10/2006 (85) Data do Início da Fase Nacional: 10/10/2007 (57) Resumo: IMPEDIR FONTES DUPLICADAS DE CLIENTES SERVIDOS POR UM TRADUTOR DE PORTA DE ENDEREÇO DE REDE. Impedir fontes duplicadas em uma conexão de protocolo que usa endereços de rede, protocolos e números de portas para identificar as aplicações de fonte que são servidas por um NAPT. Se um pacote que chega encapsula um pacote codificado e passou por um NAPT em rota para o host de destino, o pacote encapsulado é descriptografado para obter um número de porta fonte original e um protocolo de pacote original do pacote descriptografado. Uma tabela de mapeamento de porta fonte (SPMT) é buscada por uma associação entre o endereço da fonte do NAPT, a porta original da fonte e o protocolo do pacote original associado com o endereço da fonte do NAPT e o número de porta. Se uma associação incorreta é encontrada, o pacote é rejeitado como a representação de uma fonte duplicada ilegal; isto é, um segundo pacote de um host diferente servido por um NAPT que usando a mesma porta fonte e protocolo.

1/19 “MÉTODO PARA IMPEDIR FONTES DUPLICADAS EM UM PROTOCOLO DE REDE

Campo técnico [001] A invenção refere-se geralmente à rede da Internet e especificamente ao tratamento de conflitos causados pelo endereço de rede e pela tradução de portas.

Antecedentes da Invenção [002] Os problemas e soluções aqui descritos são descritos em termos da Internet e dos protocolos TCP / IP que formam a base das comunicações na Internet. No entanto, as técnicas também podem se aplicar a outros protocolos de comunicação, dependendo das especificidades dos protocolos.

[003] A tradução de endereços de rede da Internet é usada por vários motivos. O principal motivo é economizar no uso de endereços públicos. O endereço IP (Protocolo de Internet) de um Tradutor de Endereço de Rede (NAT) geralmente é um endereço público. Ou seja, o endereço IP NAT é conhecido no mundo externo, enquanto todos os servidores ou clientes atrás do NAT são endereços privados, desconhecidos para o mundo externo. Nesse caso, o mundo externo se comunica com o NAT e o NAT controla as comunicações com os servidores e clientes apropriados por trás dele. Isso significa que os endereços IP dos dispositivos por trás do NAT só precisam ser exclusivos nessa família, mas podem ser duplicados de outros endereços IP no resto do mundo. Os NATs envolvem apenas a tradução de endereços IP. Há outro tipo de tradução conhecido como NAPT (Tradução de Porta de Endereço de Rede), no qual os endereços IP e os números de porta são traduzidos. Os padrões para conversão de endereço de rede (NAT) e

Petição 870190106008, de 20/10/2019, pág. 9/28

2/19 conversão de porta de endereço de rede (NAPT) são estabelecidos na RFC 3022 da IETF (F), intitulada Tradução tradicional de endereço de rede IP.

[004] A Internet original não foi projetada com segurança como fator primário. De fato, a Internet foi propositalmente tornada relativamente aberta como um auxílio à comunicação científica e educacional. No entanto, o advento da Web e seus usos comerciais aumentou a necessidade de comunicações seguras na Internet. O Protocolo de Segurança de Internet (Internet Security Protocol), conhecido como IPsec, foi definido para solucionar esses problemas. Por exemplo, o IPsec fornece a autenticação de dispositivos de rede e / ou a criptografia de dados transmitidos. Uma comunicação IPsec entre os endereços de origem e destino é administrada de acordo com uma associação de segurança (SA), que é uma ou mais regras que definem o processamento IPsec aplicado à comunicação. IPsec é definido no RFC 2401 e em outros RFCs. Se um pacote é negado, permitido sem processamento IPsec ou permitido com processamento IPsec é determinado pela correspondência dos atributos de um pacote com as regras de segurança em um banco de dados de diretiva de segurança (SPD). Para fazer essa determinação, a técnica conhecida pesquisa as regras estáticas e dinâmicas na ordem dos atributos mais específicos para os menos específicos para pacotes de saída e de entrada. Um conjunto de regras estáticas é essencialmente uma política de segurança. As regras estáticas são predefinidas e geralmente não mudam com muita frequência.

[005] Regras dinâmicas são regras negociadas entre

Petição 870190106008, de 20/10/2019, pág. 10/28

3/19 nós durante o processamento IKE (Troca de Chave de Internet) e adicionadas ao banco de dados de políticas de segurança de maneira dinâmica, conforme necessário. A patente US 6.347.376 da International Business Machines descreve um método preferido para pesquisar as regras estáticas e dinâmicas de um SPD. Esta patente é aqui incorporada por referência na sua totalidade.

[006] Existem incompatibilidades inerentes entre o endereço de rede ou a conversão de portas e o processamento IPsec. Essas incompatibilidades são uma barreira para a implantação do IPsec. A RFC 3715 reconhece e discute algumas dessas incompatibilidades, mas não oferece soluções gerais. Por exemplo, a Seção 4.1 da RFC 3715 refere-se a uma solução limitada proposta na RFC 3456, Protocolo de Configuração Dinâmica de Host (DHCPv4, Configuração do Modo de Túnel IPsec), mas afirma que é necessária uma solução mais geral. Além disso, a Seção 5 da RFC 3948, intitulada Encapsulamento UDP de pacotes IPsec ESP do grupo de trabalho IPsec da IETF, também aborda alguns dos problemas de incompatibilidade. Particularmente, a Seção 5.2 da RFC descreve brevemente um problema na determinação de quais associações de segurança IPsec devem ser usadas nas conexões com clientes atendidos por um NAT. Esta seção também descreve outro problema ao permitir uma conexão de texto não criptografado com um cliente atrás de um NAPT quando o NAPT também lida com o tráfego IPsec.

[007] Portanto, é necessário resolver o problema de evitar fontes duplicadas quando os clientes são atendidos por um NAPT. Nenhuma solução é fornecida para este problema

Petição 870190106008, de 20/10/2019, pág. 11/28

4/19 por nenhum dos documentos IFC da IETF relacionados. Para os fins desta especificação, fontes duplicadas são definidas como pacotes com o mesmo endereço de origem (por exemplo, um endereço IP de um NAPT atribuído a um pacote original encapsulado em IPsec), o mesmo protocolo de transporte e o mesmo número da porta de origem original (ou seja, um número da porta no cabeçalho de transporte do pacote encapsulado IPsec).

[008] Origens duplicadas resultam em conexões duplicadas que promovem a integridade da rede. Por exemplo, pacotes podem ser enviados para o destino errado.

[009] RFC 3947, intitulado Negociação de NATTraversal no IKE descreve o que é necessário nas fases 1 e 2 do IKE (Troca de Chave de Internet) para o suporte à travessia de NAT. Isso inclui detectar se as duas extremidades em uma comunicação de pacote suportam a travessia de NAT e detectar se há um ou mais NATs no caminho de host para host. Ele também aborda como negociar o uso de pacotes IPsec encapsulados em protocolo UDP (Protocolo de Datagrama de Usuário) no IKE Quick Mode e descreve como transmitir um endereço IP de origem original para a outra extremidade, se necessário . O UDP é definido no RFC 768. O RFC 3948, Encapsulamento UDP de pacotes ESP IPsec, define métodos para encapsular e descapsular pacotes ESP (carga útil de encapsulamento de segurança) dentro de pacotes UDP para o propósito de atravessar NATs. O ESP é definido no RFC 2406. O ESP foi projetado para fornecer uma combinação de serviços de segurança em IPv4 e IPv6.

Sumario da invenção

Petição 870190106008, de 20/10/2019, pág. 12/28

5/19 [0010] A presente invenção fornece, portanto, a prevenção de fontes duplicadas de pacotes em conexões que usam endereços de origem, protocolos e números de porta de origem para identificar aplicativos de origem que são atendidos por um NAPT. Quando um pacote é recebido em um servidor, é determinado se o pacote é um pacote UDP que encapsula um pacote ESP cujo caminho de transmissão contém um NAPT (tradutor de porta de endereço de rede). Nesse caso, o pacote original é descapsulado para obter uma porta de origem original e um protocolo de transporte original. Uma tabela de mapeamento de porta de origem (SPMT) é pesquisada em busca de uma associação entre o endereço IP de origem NAPT, o número da porta de origem original e o protocolo de transporte original associado ao endereço IP de origem NAPT e ao número da porta de origem convertida. Se uma associação incorreta for encontrada, o pacote será rejeitado por representar uma fonte duplicada ilegal; isto é, um segundo pacote de um host diferente servido por um NAPT que tenha o mesmo endereço IP de origem, número da porta de origem e protocolo.

[0011] Na modalidade preferida, as entradas de host do Tradutor de Porta de Endereço de Rede (NAPT) no SPMT no servidor são construídas dinamicamente em resposta às mensagens IKE (Troca de Chave de Internet) dos hosts da Internet. Cada entrada do host NAPT contém o endereço IP de origem do NAPT e uma porta de origem atribuída pelo NAPT. As entradas da porta de origem no SPMT são construídas dinamicamente à medida que os pacotes criptografados chegam e são descriptografadas e as associações são estabelecidas

Petição 870190106008, de 20/10/2019, pág. 13/28

6/19 entre as entradas da porta de origem e as entradas do host NAPT do SPMT. Cada entrada da porta de origem contém um endereço IP de origem de um NAPT, um número de porta de origem original e um protocolo original.

Breve descrição dos desenhos [0012] Uma modalidade preferida da presente invenção será agora descrita a título de exemplo apenas com referência aos seguintes desenhos nos quais:

A Fig. 1 mostra um pacote que progride de um cliente, através de um NAPT para um host de destino e as alterações nos cabeçalhos e no conteúdo do pacote à medida que o pacote progride;

A Fig. 2 mostra um pacote de retorno responsivo ao pacote da Fig. 1;

A Fig. 3 mostra uma modalidade ilustrativa da Tabela de Mapeamento de Portas de Origem (SPMT);

A Fig. 4 mostra um pacote traduzido por NAPT que encapsula um pacote original criptografado;

A Fig. 5 mostra o pacote da figura 4 após descriptografia;

As Figs. 6 e 7 correspondem às Figs. 4 e 5, respectivamente, e mostram um segundo pacote no mesmo caminho que o pacote anterior que representa uma fonte duplicada ilegal causada pela inclusão de um NAPT no caminho de transmissão;

A Fig. 8 é um fluxograma da criação de entradas do host NAPT no SPMT;

A Fig. 9 é um fluxograma que mostra as opções disponíveis quando um pacote de entrada chega primeiro

Petição 870190106008, de 20/10/2019, pág. 14/28

7/19 a um host de destino;

A Fig. 10 é um fluxograma que mostra o processamento de um pacote de entrada que encapsula um pacote original criptografado e passou por um NAPT; e

As Figs. 11 e 12 são fluxogramas que mostram maneiras alternativas de processar pacotes de entrada que não atendem às condições de encapsulamento e de passagem por um NAPT.

Descrição detalhada [0013] Embora os problemas abordados pelas modalidades da presente invenção aqui descritas existam para o modo de transporte e o modo de túnel nas transmissões da Internet, a modalidade divulgada é direcionada ao modo de transporte. Uma pequena variação a ser descrita adapta a divulgação do modo de transporte para operação no modo de túnel.

[0014] Modalidades da presente invenção podem ser implementadas em software ou hardware ou em uma combinação de software e hardware. Além disso, as modalidades podem assumir a forma de um produto de programa de computador em um meio de armazenamento utilizável ou legível por computador, com meios de código de programa incorporados no meio para uso por ou em conexão com um computador ou qualquer sistema de execução de instruções. No contexto deste documento, um meio utilizável ou legível por computador pode ser qualquer meio que possa conter, armazenar, comunicar, propagar ou transportar o programa para uso por ou em conexão com o sistema, aparelho ou dispositivo de execução de instruções. .

Petição 870190106008, de 20/10/2019, pág. 15/28

8/19 [0015] O meio pode ser, por exemplo, mas não se limita a um sistema, aparelho ou dispositivo eletrônico, magnético, óptico, eletromagnético, infravermelho ou meio de propagação. Exemplos mais específicos (uma lista incompleta) do meio legível por computador incluiriam uma conexão elétrica com um ou mais fios, um disquete removível, uma memória de acesso aleatório (RAM), uma memória somente leitura (ROM), uma memória programável apagável memória somente leitura (EPROM ou memória Flash), uma fibra óptica e uma memória somente leitura portátil de CD (CD-ROM). Observe que a mídia utilizável por computador ou legível por computador pode até ser papel ou outra mídia adequada sobre a qual o programa é impresso, pois o programa pode ser capturado eletronicamente, por exemplo, através da digitalização óptica do papel ou outra mídia e compilada , interpretado ou processado de outra maneira de maneira adequada, se necessário, e armazenado na memória do computador.

[0016] Neste relatório, números iguais se referem a elementos iguais.

[0017] O processamento IPsec pode ser usado para autenticar ou criptografar o conteúdo de pacotes por motivos de segurança. Autenticação e criptografia podem ser aplicadas a um pacote ou podem ser aplicadas separadamente. Para simplificar esta apresentação, a descrição do processamento IPsec discute o encapsulamento e descapsulação dos pacotes em termos de criptografia e descriptografia. O processamento descrito é igualmente válido se a autenticação está sendo aplicada sozinha ou em conjunto com a

Petição 870190106008, de 20/10/2019, pág. 16/28

9/19 criptografia.

[0018] Quando o processamento IPsec é aplicado aos pacotes de saída de um cliente de origem, o processamento criptografa as portas de origem e destino originais e o campo do protocolo e encapsula esse material criptografado em um pacote UDP. O endereço IP de origem do cliente original é mantido no pacote UDP, mas o número da porta de origem é definido como 4500, conforme prescrito pelo RFC 3948 Encapsulamento UDP de pacotes ESP IPsec. Se o pacote UDP passar por um NAPT, o NAPT executará outras transformações. Estas transformações são descritas em detalhes abaixo em relação às Figs. 1 e 2. Especificamente, o NAPT substitui seu próprio endereço IP pelo endereço IP de origem do cliente, atribui um novo número de porta exclusivo ao cabeçalho UDP e acompanha essas traduções para que os pacotes de retorno possam ser mapeados para a fonte original. A RFC 3948 descreve um esquema no qual o número da porta de origem original em um pacote TCP ou UDP não é alterado pelo dispositivo NAPT, pois faz parte do cabeçalho de transporte original que agora é criptografado como parte da carga útil do IPsec ESP. O número da porta no cabeçalho UDP adicionado ao encapsulamento UDP é alterado em vez disso, conforme mencionado acima. Quando um pacote IPsec desse tipo é recebido por um servidor e descriptografado, as portas de origem e destino originais do pacote são reveladas. Para pacotes que não são processados através do IPsec, o dispositivo NAPT converte o endereço IP de origem e a porta de origem originais. Para pacotes não criptografados, os NAPTs garantem que não haja conexões duplicadas (fontes

Petição 870190106008, de 20/10/2019, pág. 17/28

10/19 duplicadas).

[0019] A Fig. 1 mostra um pacote que progride de um cliente 10.1.1.1, através de um NAPT 210.1.1.1 e um NAT

211.1.1.1 para um host de destino 11.1.1.1 e as alterações nos cabeçalhos e no conteúdo do pacote à medida que o pacote avança.

[0020] A figura 2 ilustra o progresso do pacote de retorno na direção inversa, do servidor para o cliente. Com referência à Fig. 1, o cliente no endereço IP 10.1.1.1 envia um pacote criptografado destinado ao servidor no endereço IP

11.1.1.1. O conteúdo original do pacote antes do processamento pelo IPsec é mostrado em 100. A coluna da esquerda de 100 descreve um tipo de campo do pacote, enquanto a coluna da direita mostra o conteúdo do campo. Observe que o endereço IP de destino em 100 é 211.1.1.1, que é o endereço público do NAT na frente do servidor de destino real

11.1.1.1. É responsabilidade do NAT 211.1.1.1 mapear pacotes para seus servidores de back-end, como 11.1.1.1. Em 100, as portas de origem e destino são ilustrativamente definidas para 4096 e 21, respectivamente. O conteúdo do pacote após o processamento do IPsec é mostrado em 102. A parte ligeiramente sombreada na parte inferior do pacote 102 ilustra a parte criptografada pelo IPsec. As partes sombreadas mais pesadas de 102 (e o conteúdo do pacote em outros pontos do caminho de transmissão) ilustram campos que foram alterados ou foram adicionados nesse ponto na transmissão. Em 102, as portas de origem e destino reais são valores criptografados de 4096 e 21 por IPsec e não podem ser lidos neste momento. O processamento IPsec adicionou um

Petição 870190106008, de 20/10/2019, pág. 18/28

11/19 cabeçalho UDP para indicar que este é um pacote IPsec que [0021] encapsula as portas e o protocolo do pacote original do cliente. As portas de origem e destino no cabeçalho UDP de texto não criptografado adicionado pelo IPsec são definidas como 4500, conforme especificado na RFC 3948. Um campo SPI (Índice de Parâmetro de Segurança) é ilustrativamente definido como 256. O campo SPI, juntamente com um protocolo de segurança e um endereço de destino, aponta para uma associação de segurança entre o cliente

10.1.1.1 e o servidor 11.1.1.1 que governa o algoritmo de criptografia e outros parâmetros de segurança entre essas entidades.

[0022] O pacote em 102 é traduzido pelo NAPT no endereço IP 210.1.1.1 e resulta no pacote mostrado em 104. Nesse ponto, o NAPT 210.1.1.1 alterou o endereço IP de origem para refletir seu próprio endereço 210.1.1.1. O NAPT também define um novo número de porta de origem exclusivo. Na Fig. 1, o número da porta de origem selecionada é ilustrativamente alterado de 4500 para 4501. O NAPT 210.1.1.1 controla essa conversão para pacotes de retorno do servidor 11.1.1.1 e para futuros pacotes de saída do IP do cliente 10.1.1.1 e porta de origem 4500.

[0023] O pacote em 104 é retraduzido pelo NAT

211.1.1.1 no pacote de entrada do servidor 11.1.1.1. Este pacote de entrada é mostrado em 106. Essencialmente, o endereço IP de destino do pacote é mapeado pelo NAT 211.1.1.1 no endereço de destino real 11.1.1.1 do servidor de destino. O processamento IPsec do pacote remove o cabeçalho UDP adicionado pelo processamento IPsec na origem 10.1.1.1 e

Petição 870190106008, de 20/10/2019, pág. 19/28

12/19 restaura os números reais das portas de origem e de destino. O pacote restaurado, como mostrado em 108, é entregue à porta de destino (21 neste exemplo) para processamento do aplicativo.

[0024] Para completar, a Fig. 2 mostra um fluxo de pacotes de retorno do servidor 211.1.1.1 para o cliente original 10.1.1.1. Não há necessidade de discutir esse fluxo de pacotes com nenhum detalhe, porque o problema de origem duplicada abordado pelas modalidades da presente invenção não pode ocorrer para pacotes de retorno.

[0025] Com referência novamente à Fig. 1, o pacote em 108 contém como endereço de origem o endereço do NAPT

210.1.1.1 e um número da porta de origem 4096. No entanto, é possível que outro cliente, digamos 10.1.1.2, seja o NAPT

210.1. 1.1 também está enviando pacotes para o host 11.1.1.1 da porta de origem 4096. Portanto, devido à presença de um NAPT no caminho entre o cliente 10.1.1.1 e o host 11.1.1.1, existe a possibilidade de uma fonte duplicada ilegal que resulta em um conflito.

[0026] Uma tabela de mapeamento de porta de origem (SPMT) é usada para detectar fontes duplicadas nas quais os pacotes são recebidos de clientes ou servidores atendidos por um NAPT. Um SPMT ilustrativo é mostrado na Figura 3 em 300. Esta tabela é criada dinamicamente quando os pacotes IKE (Troca de Chave de Internet) são recebidos em um servidor quando uma associação de segurança IPsec é estabelecida. Com referência à Fig. 3, quando o IKE negocia uma associação de segurança IPsec que atravessa um NAPT, a pilha TCP / IP é notificada para criar uma entrada de host NAPT como 302 para

Petição 870190106008, de 20/10/2019, pág. 20/28

13/19 representar o cliente remoto, representado pelo NAPT. Esta entrada contém o endereço IP de origem do NAPT (210.1.1.1 neste exemplo) e a porta de origem atribuída a este cliente pelo NAPT (4501 neste exemplo). A Fig. 3 mostra um segundo cliente NAPT ilustrativo 304 com o mesmo endereço de origem IP NAPT 210.1.1.1 e uma porta de origem diferente 4502 atribuída pelo NAPT. No lado direito do SPMT 300 estão as entradas da porta de origem. Essas entradas são criadas quando pacotes codificados por IPsec chegam para os quais não há entrada existente. O processo de adição de entradas da porta de origem ocorre após a descriptografia do IPsec. As associações 306 que mapeiam as entradas da porta de origem para as entradas do host NAPT são criadas conforme as entradas da porta de origem são criadas. Uma entrada de host NAPT é removida quando a última associação de segurança é excluída que pertence à entrada. Quando um pacote chega e é descriptografado, o endereço NAPT de origem, a porta de origem do pacote original e o protocolo do pacote original estão disponíveis. As entradas da porta de origem do SPMT são pesquisadas por uma correspondência nesses atributos. Se uma correspondência for encontrada, a entrada do host NAPT associada será verificada quanto à correspondência no endereço de origem NAPT e na porta de origem atribuída pelo NAPT. Se esses últimos atributos não corresponderem, isso significa que dois clientes atrás do NAPT de origem estão tentando usar os mesmos números de porta de origem. Isso representa uma fonte duplicada e o segundo pacote é rejeitado. Se esses últimos atributos corresponderem, o pacote será permitido.

Petição 870190106008, de 20/10/2019, pág. 21/28

14/19 [0027] As Figs. 4 a 7 ajudam a ilustrar a discussão acima. A Fig. 4 mostra um pacote proveniente de uma fonte NAPT. O endereço e a porta do cliente são assumidos como

10.1.1.1 e 4096, respectivamente, para ilustração. 400 é o cabeçalho IP atualizado pelo NAPT. Ele contém o endereço NAPT 210.1.1.1 e um endereço de host de destino 11.1.1.1. 402 é o cabeçalho UDP de encapsulamento adicionado pelo processamento IPsec e atualizado pelo NAPT. A porta de origem

4500 foi alterada para 4501 pelo NAPT. 404 contém o cabeçalho ESP (Encapsulated Security Protocol) adicionado pelo processamento IPsec. O cabeçalho de transporte TCP 406 contém as portas de origem e destino do cliente original, 4096 e 21. 408 contém os dados de carga útil seguidos pelo trailer ESP. O cabeçalho de transporte 406 e a carga útil 408 são criptografados de acordo com o processamento IPsec. A Fig. 5 representa o pacote da Fig. 4 após descriptografia no host de destino. Observe agora que o endereço NAPT de origem

210.1.1.1 (do campo de pacote 500) e a porta de origem do cliente 4096 e o protocolo (TCP) agora estão disponíveis no campo 506. As entradas da porta de origem do SPMT 300 são pesquisadas usando esses atributos. Neste exemplo, uma correspondência é encontrada em 308. A associação correspondente 306 aponta para a entrada 302 do host NAPT. O endereço NAPT de origem 210.1.1.1 e a porta de origem NAPT

4501 correspondem a este pacote (a porta de origem NAPT 4501 está disponível no campo 402 do pacote recebido). Portanto, este pacote está associado a uma conexão correta e é aceito.

[0028] As Figs. 6 e 7 representam um segundo pacote de origem duplicado que será rejeitado. Isso ocorre porque

Petição 870190106008, de 20/10/2019, pág. 22/28

15/19 o endereço de origem NAPT 210.1.1.1 do campo 700, o protocolo do campo 706 e a porta 4096 do cliente de origem correspondem a 308 das entradas da porta de origem do SPMT 300, mas a entrada NAPT associada 302 não corresponde ao número da porta atribuída ao NAPT de 4502 do campo 602 do pacote recebido.

[0029] Agora, esse processo é explicado com mais detalhes abaixo em associação com fluxogramas apropriados.

[0030] A Fig. 8 ilustra a inicialização das entradas do host NAPT do SPMT 300 durante as negociações de IKE. A negociação IKE é representada na etapa 802. Após a negociação, a etapa 804 envia uma notificação para a pilha TCP / IP para criar uma entrada de host NAPT associada no SPMT 300. Essa notificação contém o endereço de origem NAPT e o número da porta recuperados dos fluxos IKE .

[0031] A Fig. 9 inicia o processo de detecção de uma fonte duplicada quando um pacote de dados chega ao host de destino. A etapa 902 determina se o pacote recebido contém um pacote ESP encapsulado em um cabeçalho UDP e a porta de origem no cabeçalho UDP não é a porta de encapsulamento UDP predefinida 4500. Se o exposto acima for verdadeiro, o pacote estará usando IPsec, seja para criptografia ou autenticação, e um NAPT está envolvido no caminho de transmissão. Se um pacote estiver usando um protocolo UDP com uma porta de destino de 4500 e os quatro primeiros bytes contiverem dados diferentes de zero, o pacote será identificado como um pacote ESP encapsulado em UDP. Se a resposta na etapa 902 for negativa, existem duas opções alternativas de processamento, a opção 1 em 904 e a opção 2 em 906. As duas são discutidas abaixo. Supondo que a resposta em 902 seja sim, então 908

Petição 870190106008, de 20/10/2019, pág. 23/28

16/19 continua em A na Fig. 10. Na Fig. 10, a etapa 1002 executa o processamento IPsec necessário para descriptografar o pacote. Como resultado, o endereço de origem NAPT, o número da porta de origem do cliente original e o protocolo são obtidos de forma clara, conforme explicado acima. A etapa 1004 pesquisa as entradas da porta de origem do SPMT 300 nesses atributos. Em 1006, se uma correspondência não for encontrada, uma entrada de porta de origem é criada na etapa 1008 e o processamento de entrada do pacote continua normalmente. Se uma correspondência for encontrada na etapa 1006, a etapa 1010 utilizará a associação 306 correspondente para comparar o endereço de origem e o número da porta atribuídos ao NAPT da entrada do host NAPT correspondente aos mesmos atributos do pacote descriptografado. Se essa comparação falhar, o pacote será rejeitado em 1011. Se uma correspondência for obtida, o processamento do pacote continuará normalmente em 1012.

[0032] As opções 1 e 2 da Fig. 9 representam situações nas quais os pacotes são enviados em claro (sem processamento IPsec) ou não há tradução de endereço (NAPT) no caminho. No entanto, fontes duplicadas ainda são possíveis. As opções alternativas 1 e 2 detectam esses pacotes duplicados. O processamento da opção 1 começa em B da Figura 11. Esta opção processa todos os pacotes de dados através da tabela SPMT 300. Isso é feito adicionando outra entrada de host NAPT única designada como NO IPSEC / NAPT. Quando um pacote chega, as entradas da porta de origem do SMPT 300 são pesquisadas conforme explicado acima. Se nenhuma correspondência for encontrada, uma entrada da porta de

Petição 870190106008, de 20/10/2019, pág. 24/28

17/19 origem será criada em 1106 e associada à entrada do host NAPT NO IPSEC / NAPT. Se uma entrada de porta de origem correspondente for encontrada em 1104, a etapa 1110 determinará se a associação 306 correspondente apontará para a entrada do host NAPT NO IPSEC / NAPT. Nesse caso, o pacote é permitido na etapa 1108. Caso contrário, é rejeitado na 1112. A vantagem desta opção 1 é a simplicidade. Sua desvantagem é que todo o tráfego de dados é processado através da tabela 300 do SPMT.

[0033] A opção 2 usa a filtragem de pacotes IPsec de entrada para rejeitar pacotes de origem duplicados. Depois que o IPsec está em um host, todos os pacotes são processados pela tabela de regras IPsec (o SPD), independentemente de algum pacote ser criptografado ou não. Isso é para verificar se os pacotes não criptografados em uma determinada conexão são de fato permitidos pela regra IPsec que governa a conexão. O processo da opção 2 começa em C da Fig. 12. O pacote recebido é processado através da tabela de regras IPsec (não mostrada) na etapa 1202. Um exemplo de como isso é feito em uma modalidade preferida pode ser determinado a partir da referida patente US 6.347.376 . Esta patente é aqui incorporada por referência na sua totalidade. Se o pacote estiver criptografado (etapa 1204), a etapa 1206 determinará se a regra IPsec de controle exige criptografia. Supondo que esse seja o caso, o pacote é permitido em 1208. Caso contrário, ele será rejeitado em 1210. Se o pacote não for criptografado na etapa 1204, será feita uma determinação em 1212 se a regra IPsec de governo permitir pacotes não criptografados e o pacote for permitido ou rejeitado em

Petição 870190106008, de 20/10/2019, pág. 25/28

18/19 conformidade.

[0034] No modo de encapsulamento, o IPsec SA não é necessariamente de ponta a ponta. Por exemplo, um SA pode ser ne entre um host e um gateway que atende a vários clientes ou servidores. No modo de encapsulamento, um único endereço NAPT (que é o endereço IP de origem no cabeçalho de encapsulamento UDP) pode representar potencialmente vários hosts. No modo de encapsulamento, a parte criptografada e encapsulada de um pacote contém o endereço IP original da fonte e um cabeçalho de transporte. Para os fins desta especificação, o endereço IP original da fonte no modo de túnel é chamado de endereço IP da fonte interna. Como o endereço IP de origem interno não é globalmente exclusivo, não é utilizável para roteamento de pacotes ou para representar a origem de uma conexão. A porta de origem original, como contida nas entradas da porta de origem do SPMT 300, e o endereço IP de origem do encapsulamento apenas com a porta UDP, conforme descrito acima para o modo de transporte, podem não ser exclusivos. Para resolver isso, um campo adicional que contém o endereço IP de origem interno é adicionado às entradas da porta de origem (por exemplo, 308) do SPMT 300 na Fig. 3. O endereço IP de origem interno (não disponível no modo de transporte) quando combinado com os outros valores das entradas da porta de origem produzem um identificador exclusivo para hosts protegidos por uma IPsec SA no modo de encapsulamento. O endereço IP de origem interno é adicionado à entrada da porta de origem como parte da etapa 1008. Quando um pacote no modo de encapsulamento chega, as entradas da porta de origem do SPMT são pesquisadas

Petição 870190106008, de 20/10/2019, pág. 26/28

19/19 conforme descrito na etapa 1004 para encontrar uma associação a uma entrada do host NAPT e etapa 1010, além do que já foi descrito, verifica se o endereço IP do cliente interno de origem obtido a partir do pacote descriptografado é o mesmo que o endereço IP do cliente na entrada da porta de origem. Se essa verificação falhar, o pacote será rejeitado [0035] Será evidente para os versados na técnica que as modalidades preferidas podem ter muitas variações menores. Por exemplo, o protocolo ICMP não usa números de porta; em vez disso, eles usam identificadores de consulta. No que diz respeito à invenção, conforme divulgado e reivindicado, os identificadores de consulta são equivalentes aos números de porta.

Petição 870190106008, de 20/10/2019, pág. 27/28

1/3

Claims

REIVINDICAÇÕES

1. Método para impedir fontes duplicadas em um protocolo de rede que usa endereços de rede, protocolos e números de porta para identificar aplicações caracterizado pelo fato de que compreende:

a) receber um pacote em um servidor;

b) determinar (902) se o pacote é em um pacote encapsulado IPsec;

c) se o pacote for um pacote encapsulado IPsec, determinar (902) se o trajeto de transmissão do pacote contém um tradutor de porta de endereço de rede (NAPT);

d) se o trajeto de transmissão do pacote contém um NAPT, descriptografar (1002) o pacote encapsulado IPsec para obter um número de porta de fonte original e protocolo de pacote original.

e) buscar uma tabela de mapeamento de porta fonte (SPMT) para uma associação (1604) entre o endereço fonte NAPT, a porta original da fonte e o protocolo original do pacote para o endereço da fonte do NAPT e número de porta; e

f) se uma associação for encontrada na etapa e) que é para um número de porta original diferente daquele contido no pacote, rejeitar o pacote (1011).
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a etapa b) ainda compreende determinar se o pacote contém um payload de segurança (ESP) encapsulado por um cabeçalho de protocolo de datagrama de usuário (UDP).

Petição 870180154882, de 26/11/2018, pág. 25/27

2/3
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a etapa c) ainda compreende determinar se o cabeçalho UDP encapsulado contém número de porta fonte diferente de 4500 e um número de porta de destino igual a 4500.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende construir dinamicamente entradas de host de tradutor de endereço de rede (NAPT) na SPMT no servidor em resposta às mensagens de comutação de chave de Internet (IKE) dos hosts da Internet, cada entrada de host de NAPT contendo o endereço de IP da fonte do NPT e um número de porta fonte atribuído pelo NAPT.
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que ainda compreende construir dinamicamente entradas de portas da fonte na SPMT à medida que pacotes de IPsec chegam e são processados, cada entrada de porta fonte contendo um endereço da fonte de um NAPT, um úmero de porta fonte original e um protocolo original, e estabelecer associações entre as entradas da porta fonte e as entradas do host de NAPT da SPMT.
6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que a etapa de estabelecer associações ainda compreende estabelecer cada associação dinamicamente quando um pacote IPsec chega para o qual não há nenhuma associação.
7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que ainda compreende:

Petição 870180154882, de 26/11/2018, pág. 26/27

3/3 adicionar uma única entrada de host No IPSEC/NAPT” à SPMT para a associação com todos os pacotes que não contêm um cabeçalho de ESP ou não passaram por um NAPT, formar uma associação entre uma entrada da porta fonte da SPMT e a entrada No IPSEC/NAPT” quando um pacote chega e não contém um cabeçalho de ESP ou não passou por um NAPT e não tem uma associação; e rejeitar um pacote que não contenha um cabeçalho de ESP ou não passou por um NAPT se já existe uma associação estabelecida para a combinação da entrada de porta fonte que não aponta para a entrada No IPSEC/NAPT”.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende:

se o trajeto de transmissão de um pacote que chega não contém um NAPT ou o pacote que chega não é um pacote de IPsec, buscar uma tabela de regras de segurança para uma correspondência de regra que governe a rejeição ou a aceitação do pacote, rejeitar o pacote se o pacote é um pacote de IPsec e a correspondência de regra não requer processamento IPsec, e rejeitar o pacote se o pacote não é um pacote de IPsec e a correspondência de regra requer processamento IPsec.

Petição 870180154882, de 26/11/2018, pág. 27/27

1/5

CLIENTE

10.1.1.1

PROTOCOLO TCP SRC IP 10.1.1.1 SRC PORT 4096 DEST IP 211.1.1.1 DEST PORT 21

PROTOCOLO M UDP® SRC IP 10.1.1.1 SRC PORT 1 DEST IP 211.1.1.1 | DEST PORT III SPI iDÊSTPORT

102

NAPT

210.1.1.1

100

PROTOCOLO TCP· SRC IP 210.1.1.1 SRC PORT Í4O96JB DEST IP 11.1.1.1 DEST PORTf 211

108 SERVIDOR

11.1.1.1

106

PROTOCOLO UDP SRC IP 210.1.1.1 SRC PORT 4501 DESTIP Ί wUu· DEST PORT 4500 SPI 256 OSO

104

PROTOCOLO UDP J SRC IP 1 SRC PORT 1 Í114501· DESTIP 211.1.1.1 DEST PORT 4500 SPI 256 #&&(&&& **:2£**

NAT

211.1.1.1

FIGURA 1

202

CLIENTE

10.1.1.1

PROTOCOLO MttfÒPMK SRC IP

211.1/

SRC PORT ΟΓ2Ϊ

PROTOCOLO UDP SRC IP 211.1.1.1 SRC PORT 4500 DESTIP | Bl 0.1 .Ml DEST PORT | «4500ÉÍ SPI 257

NAPT

210.1.1.1

204

DEST IP DEST PORT

208

10.1.1

200

PROTOCOLO TCP SRC IP 11.1.1.1 SRC PORT 21 DEST IP 210.1.1.1 DEST PORT 4096

SERVIDOR

11.1.1.1

206

PROTOCOLO ÉB.yPgÉÍÉ

11.1.1.1

SRC IP .........

SRC PORT BÍ4500fll

210.1.1.1

4SÕ1

DEST IP DEST PORT

SPI jiff*

UDP

SRC IP 1 SRC PORT 4500 deSt ip 210.1.1.1 dest port 4501 SPI 257 Φ?ΒΡ$ ίψ&ϋΦί kèèfcfSiftr;

NAT

211.1.1.1

FIGURA 2

2/5

FIGURA 3 TABELA DE MAPEAMENTO DE PORTA FONTE (SPMT) 300

FIGURA 4 ENDEREÇO DE CLIENTE DO PACOTE ENCAPSULADO NAPT10.1.1.1 PORTA4096

400 IP HEADER SRC 210.1.1.1 DEST 11.1.1.1 402 UDP HEADER SRC PORT 4501 DEST PORT 4500 404 ESP HEADER 406 PROTOCOL TCP SRC PORT 4096 DEST PORT 21 408 PAYLOAD 410 ESP TRAILER

FIGURA 5 PACOTE DA FIGURA 4 APÓS PROCESSAMENTO IPSEC NO HOSPEDEIRO

500 IP HEADER SRC 210.1.1.1 DEST 11.1.1.1 506 PROTOCOLTCP SRC PORT 4096 DEST PORT 21 ent} PAYLOAD

FIGURA 6 ENDEREÇO DE CLIENTE DO PACOTE ENCAPSULADO NAPT10.1.1.2 PORTA4096

600 IP HEADER SRC 210.1.1.1 DEST 11.1.1.1 602 UDP HEADER SRC PORT 4502 DEST PORT 4500 604 ESP HEADER 606 PROTOCOL TCP SRCPORT4096 DEST PORT 21 608 PAYLOAD 610 ESP TRAILER

FIGURA 7 PACOTE DA FIGURA 5 APÓS PROCESSAMENTO IPSEC NO HOSPEDEIRO

700

IP HEADER SRC 210.1.1.1 DEST 11.1.1.1

706 PROTOCOLTCP SRC PORT 4096 DEST PORT 21

708 PAYLOAD

3/5

FIGURA 8 NEGOCIAÇÃO IKE