BRPI0607516B1 - Método para impedir fontes duplicadas em um protocolo de rede - Google Patents
Método para impedir fontes duplicadas em um protocolo de rede Download PDFInfo
- Publication number
- BRPI0607516B1 BRPI0607516B1 BRPI0607516-9A BRPI0607516A BRPI0607516B1 BR PI0607516 B1 BRPI0607516 B1 BR PI0607516B1 BR PI0607516 A BRPI0607516 A BR PI0607516A BR PI0607516 B1 BRPI0607516 B1 BR PI0607516B1
- Authority
- BR
- Brazil
- Prior art keywords
- source
- port
- packet
- client
- port number
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 16
- 238000013519 translation Methods 0.000 claims abstract description 14
- 230000004044 response Effects 0.000 claims abstract description 4
- 238000004891 communication Methods 0.000 claims description 10
- 238000012423 maintenance Methods 0.000 claims 2
- 238000013507 mapping Methods 0.000 abstract description 4
- 238000012545 processing Methods 0.000 description 27
- 238000005538 encapsulation Methods 0.000 description 11
- 230000014616 translation Effects 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 230000003068 static effect Effects 0.000 description 4
- 238000011330 nucleic acid test Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- GKSPIZSKQWTXQG-UHFFFAOYSA-N (2,5-dioxopyrrolidin-1-yl) 4-[1-(pyridin-2-yldisulfanyl)ethyl]benzoate Chemical compound C=1C=C(C(=O)ON2C(CCC2=O)=O)C=CC=1C(C)SSC1=CC=CC=N1 GKSPIZSKQWTXQG-UHFFFAOYSA-N 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5046—Resolving address allocation conflicts; Testing of addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/663—Transport layer addresses, e.g. aspects of transmission control protocol [TCP] or user datagram protocol [UDP] ports
-
- H04L29/12377—
-
- H04L29/12924—
-
- H04L61/6063—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Computer And Data Communications (AREA)
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 conexões que incluem tradução de número de porta. Em resposta a um pacote inbound de IPsec de um cliente fonte remoto, uma determinação é feita quanto a se um número de porta está disponível dentro de um intervalo de números de porta que obedecem a uma associação de segurança que governa a conexão. Se sim, o número de porta disponível é atribuído à. conexão, evitando, desse modo, uma possibilidade de uma fonte duplicada. Se um número de porta não estiver disponível, o pacote é rejeitado.
Description
“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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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 870190106009, 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.
Claims (6)
1. Método para impedir conflitos de fonte duplicada em um protocolo de rede que usa endereços de rede, protocolos e os números de porta para identificar conexões caracterizado pelo fato de que compreende:
receber um pacote inbound em uma conexão em um host de destino a partir de um cliente de fonte remota;
em resposta a uma determinação de que o pacote foi traduzido por um tradutor de endereço de rede e que o pacote foi recebido de acordo com uma associação de segurança definindo como os pacotes são submetidos a uma ou mais criptografias e autenticação para comunicação entre o host e o cliente fonte, determinar se o número de porta está disponível dentro de um intervalo de números de porta para associação de segurança (1112) e, onde um numero de porta está disponível, atribuir o número de porta disponível para a conexão; e em resposta a determinação de que nenhum número de porta está disponível dentro de um intervalo de números de porta, rejeitar o pacote como uma fonte duplicada (1114).
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda a manutenção de uma lista de números de portas atribuíveis para cada cliente de fonte remota e os estados atribuído e não atribuído de cada número de porta na lista.
3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que cada lista de números de portas atribuíveis é um vetor de bits em que as posições de bits identificam números de porta e os estados de bit
Petição 870180154978, de 26/11/2018, pág. 33/35
2/3 descrevem os estados atribuído e não atribuído dos números de porta.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda a manutenção de uma Tabela de Tradução da Porta fonte que associa cada conexão do lado do cliente com um número de porta traduzido.
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que a Tabela de Tradução da Porta fonte contém as entradas de porta fonte e entradas de porta fonte traduzidas, em que cada entrada de porta fonte é unicamente associada a uma entrada de porta fonte traduzida e cada entrada de porta fonte contém um endereço fonte da Internet, um número de porta fonte do UDP atribuído por um NAPT, um número de porta fonte do cliente e um identificador de protocolo do cliente e cada entrada de porta fonte traduzida contém um endereço fonte da Internet, um número de porta fonte do cliente traduzido e um identificador de protocolo do cliente, em que as entradas de porta fonte traduzidas são buscadas em pacotes de entrada para identificar um número de porta previamente atribuído a uma conexão de cliente remoto e as entradas de porta fonte traduzidas são buscadas em pacotes de saída para identificar um número de porta de cliente de um número de porta traduzido previamente atribuído.
6. Aparelho para impedir conflitos de fonte duplicada em um protocolo de rede que usa endereços de rede, protocolos e números de porta para identificar conexões, caracterizado por compreender:
Petição 870180154978, de 26/11/2018, pág. 34/35
3/3 meios para receber um pacote de entrada em uma conexão em um host de destino de um cliente fonte remoto;
meio responsivo a uma determinação de que o pacote foi traduzido por um tradutor de porta de endereço de rede e que o pacote é recebido de acordo com uma associação de segurança definindo como os pacotes estão sujeitos a uma ou mais criptografia e autenticação para comunicação entre o host e o cliente fonte, para determinar se um número de porta está disponível dentro de um intervalo de números de porta para a associação de segurança (1112) e, onde um número de porta está disponível, atribuindo o número de porta disponível à conexão; e meio responsivo a uma determinação de que nenhum número de porta está disponível dentro do intervalo de números de porta para rejeitar o pacote como uma fonte duplicada (1114) .
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/907,659 US8787393B2 (en) | 2005-04-11 | 2005-04-11 | Preventing duplicate sources from clients served by a network address port translator |
| US10/907,659 | 2005-04-11 | ||
| PCT/EP2006/061443 WO2006108808A1 (en) | 2005-04-11 | 2006-04-07 | Preventing duplicate sources from clients served by a network address port translator |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BRPI0607516A2 BRPI0607516A2 (pt) | 2012-01-17 |
| BRPI0607516B1 true BRPI0607516B1 (pt) | 2020-06-02 |
Family
ID=36645677
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0607516-9A BRPI0607516B1 (pt) | 2005-04-11 | 2006-04-07 | Método para impedir fontes duplicadas em um protocolo de rede |
Country Status (10)
| Country | Link |
|---|---|
| US (2) | US8787393B2 (pt) |
| EP (1) | EP1872562B1 (pt) |
| JP (1) | JP4482601B2 (pt) |
| CN (1) | CN101133625B (pt) |
| AT (1) | ATE460039T1 (pt) |
| BR (1) | BRPI0607516B1 (pt) |
| CA (1) | CA2602789C (pt) |
| DE (1) | DE602006012644D1 (pt) |
| TW (1) | TWI380650B (pt) |
| WO (1) | WO2006108808A1 (pt) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7852961B2 (en) * | 2004-05-20 | 2010-12-14 | Samsung Electronics Co., Ltd. | Digital broadcasting transmission/reception devices capable of improving a receiving performance and signal processing method thereof |
| US8787393B2 (en) | 2005-04-11 | 2014-07-22 | International Business Machines Corporation | Preventing duplicate sources from clients served by a network address port translator |
| US7962652B2 (en) | 2006-02-14 | 2011-06-14 | International Business Machines Corporation | Detecting network topology when negotiating IPsec security associations that involve network address translation |
| JP2009111437A (ja) * | 2007-10-26 | 2009-05-21 | Hitachi Ltd | ネットワークシステム |
| US8108514B2 (en) | 2008-04-02 | 2012-01-31 | International Business Machines Corporation | High availability of internet protocol addresses within a cluster |
| CN101674606A (zh) * | 2009-09-25 | 2010-03-17 | 华为技术有限公司 | 数据传输方法及装置 |
| GB2474843B (en) * | 2009-10-27 | 2012-04-25 | Motorola Solutions Inc | Method for providing security associations for encrypted packet data |
| US8806033B1 (en) * | 2011-06-30 | 2014-08-12 | Juniper Networks, Inc. | Effective network identity pairing |
| US8775614B2 (en) | 2011-09-12 | 2014-07-08 | Microsoft Corporation | Monitoring remote access to an enterprise network |
| CN103139189B (zh) * | 2011-12-05 | 2017-03-22 | 京信通信系统（中国）有限公司 | 一种IPSec隧道共用方法、系统及设备 |
| US20140153577A1 (en) * | 2012-12-03 | 2014-06-05 | Aruba Networks, Inc. | Session-based forwarding |
| CN105515990A (zh) * | 2014-09-23 | 2016-04-20 | 中国电信股份有限公司 | 基于二维信息进行寻路的方法和接入网关 |
| CN106899474B (zh) * | 2016-12-07 | 2020-06-09 | 新华三技术有限公司 | 一种报文转发的方法和装置 |
| FR3072233B1 (fr) * | 2017-10-10 | 2020-11-27 | Bull Sas | Procede de generation de requetes pour la segmentation de la surveillance d'un reseau d'interconnexion et materiel associe |
| US11526499B2 (en) | 2019-02-18 | 2022-12-13 | International Business Machines Corporation | Adaptively updating databases of publish and subscribe systems using optimistic updates |
| US11381665B2 (en) | 2019-02-18 | 2022-07-05 | International Business Machines Corporation | Tracking client sessions in publish and subscribe systems using a shared repository |
| CN112242943B (zh) * | 2020-11-26 | 2022-08-16 | 迈普通信技术股份有限公司 | IPSec隧道建立方法及装置、分支设备、中心端设备 |
| US11778071B2 (en) * | 2021-01-26 | 2023-10-03 | Avago Technologies International Sales Pte. Limited | Systems and methods for converting between a lossy communication protocol and a lossless communication protocol |
| US11765238B1 (en) * | 2022-06-21 | 2023-09-19 | Juniper Networks, Inc. | Non-translated port oversubscribing for a proxy device |
Family Cites Families (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5758084A (en) * | 1995-02-27 | 1998-05-26 | Hewlett-Packard Company | Apparatus for parallel client/server communication having data structures which stored values indicative of connection state and advancing the connection state of established connections |
| US5983260A (en) * | 1995-07-19 | 1999-11-09 | Fujitsu Network Communications, Inc. | Serial control and data interconnects for coupling an I/O module with a switch fabric in a switch |
| US6404736B1 (en) * | 1997-06-20 | 2002-06-11 | Telefonaktiebolaget L M Ericsson (Publ) | Call-routing efficiency with a network access server |
| US6138144A (en) * | 1997-06-24 | 2000-10-24 | At&T Corp. | Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network implemented over an ATM network |
| US6615357B1 (en) * | 1999-01-29 | 2003-09-02 | International Business Machines Corporation | System and method for network address translation integration with IP security |
| US6347376B1 (en) | 1999-08-12 | 2002-02-12 | International Business Machines Corp. | Security rule database searching in a network security environment |
| EP1168754B1 (en) * | 2000-06-26 | 2005-03-16 | Alcatel | Addressing scheme to be used in an IP-based radio access network |
| US7120697B2 (en) * | 2001-05-22 | 2006-10-10 | International Business Machines Corporation | Methods, systems and computer program products for port assignments of multiple application instances using the same source IP address |
| JP2002232450A (ja) * | 2001-01-31 | 2002-08-16 | Furukawa Electric Co Ltd:The | ネットワーク中継装置、データ通信システム、データ通信方法およびその方法をコンピュータに実行させるプログラム |
| US7072341B2 (en) * | 2001-02-20 | 2006-07-04 | Innomedia Pte, Ltd | Real time streaming media communication system |
| KR20030011080A (ko) * | 2001-03-16 | 2003-02-06 | 마쯔시다덴기산교 가부시키가이샤 | 방화벽 설정 방법 및 장치 |
| US20020144024A1 (en) * | 2001-03-30 | 2002-10-03 | Kumpf David A. | Method and system for assigning peripheral devices to logical ports of a network peripheral server |
| US7684317B2 (en) * | 2001-06-14 | 2010-03-23 | Nortel Networks Limited | Protecting a network from unauthorized access |
| DE60223451T2 (de) * | 2001-06-14 | 2008-11-27 | Hitachi, Ltd. | System zur Quittierung von Datenpaketen |
| US6898652B2 (en) * | 2001-08-22 | 2005-05-24 | General Atomics | Wireless device attachment and detachment system, apparatus and method |
| US7363286B2 (en) * | 2001-10-29 | 2008-04-22 | International Business Machines Corporation | File system path alias |
| US20030140089A1 (en) * | 2001-11-01 | 2003-07-24 | Hines Kenneth J. | Inter-applet communication using an applet agent |
| US20030154306A1 (en) * | 2002-02-11 | 2003-08-14 | Perry Stephen Hastings | System and method to proxy inbound connections to privately addressed hosts |
| JP3819804B2 (ja) * | 2002-05-09 | 2006-09-13 | 日本電信電話株式会社 | Ｉｐネットワーク接続機能を備えたネットワークインターフェイスを用いる通信方式およびその装置 |
| US7143137B2 (en) * | 2002-06-13 | 2006-11-28 | Nvidia Corporation | Method and apparatus for security protocol and address translation integration |
| US7339889B2 (en) * | 2002-06-20 | 2008-03-04 | Nortel Networks Limited | Control plane architecture for automatically switched optical network |
| KR100479261B1 (ko) * | 2002-10-12 | 2005-03-31 | 한국전자통신연구원 | 네트워크 주소 변환 상에서의 데이터 전송 방법 및 장치 |
| US7346770B2 (en) | 2002-10-31 | 2008-03-18 | Microsoft Corporation | Method and apparatus for traversing a translation device with a security protocol |
| US7386881B2 (en) * | 2003-01-21 | 2008-06-10 | Swander Brian D | Method for mapping security associations to clients operating behind a network address translation device |
| US20040193677A1 (en) * | 2003-03-24 | 2004-09-30 | Shaul Dar | Network service architecture |
| JP4352748B2 (ja) * | 2003-04-21 | 2009-10-28 | パナソニック株式会社 | 中継装置 |
| US7633948B2 (en) * | 2003-07-07 | 2009-12-15 | Panasonic Corporation | Relay device and server, and port forward setting method |
| US7283517B2 (en) * | 2003-07-22 | 2007-10-16 | Innomedia Pte | Stand alone multi-media terminal adapter with network address translation and port partitioning |
| US7287077B2 (en) * | 2003-08-07 | 2007-10-23 | International Business Machines Corporation | Reservation of TCP/UDP ports using UID, GID or process name |
| CN1317874C (zh) * | 2003-09-27 | 2007-05-23 | 财团法人资讯工业策进会 | 提供虚拟主机服务快速查询置换的网络地址端口转换网关器与方法 |
| US7424025B2 (en) * | 2003-10-01 | 2008-09-09 | Santera Systems, Inc. | Methods and systems for per-session dynamic management of media gateway resources |
| JP3762402B2 (ja) * | 2003-10-07 | 2006-04-05 | キヤノン株式会社 | データ処理装置及び方法 |
| US20050166206A1 (en) * | 2004-01-26 | 2005-07-28 | Parson Dale E. | Resource management in a processor-based system using hardware queues |
| JP4555592B2 (ja) * | 2004-03-31 | 2010-10-06 | 富士通株式会社 | パケット処理システム |
| US20050265252A1 (en) * | 2004-05-27 | 2005-12-01 | International Business Machines Corporation | Enhancing ephemeral port allocation |
| US7366182B2 (en) * | 2004-08-13 | 2008-04-29 | Qualcomm Incorporated | Methods and apparatus for efficient VPN server interface, address allocation, and signaling with a local addressing domain |
| US7656795B2 (en) * | 2005-04-11 | 2010-02-02 | International Business Machines Corporation | Preventing duplicate sources from clients served by a network address port translator |
| US8787393B2 (en) | 2005-04-11 | 2014-07-22 | International Business Machines Corporation | Preventing duplicate sources from clients served by a network address port translator |
-
2005
- 2005-04-11 US US10/907,659 patent/US8787393B2/en active Active
-
2006
- 2006-04-07 JP JP2008505873A patent/JP4482601B2/ja not_active Expired - Lifetime
- 2006-04-07 WO PCT/EP2006/061443 patent/WO2006108808A1/en not_active Ceased
- 2006-04-07 EP EP06743265A patent/EP1872562B1/en not_active Expired - Lifetime
- 2006-04-07 CN CN2006800071424A patent/CN101133625B/zh not_active Expired - Lifetime
- 2006-04-07 CA CA2602789A patent/CA2602789C/en not_active Expired - Lifetime
- 2006-04-07 DE DE602006012644T patent/DE602006012644D1/de not_active Expired - Lifetime
- 2006-04-07 TW TW095112585A patent/TWI380650B/zh not_active IP Right Cessation
- 2006-04-07 BR BRPI0607516-9A patent/BRPI0607516B1/pt active IP Right Grant
- 2006-04-07 AT AT06743265T patent/ATE460039T1/de not_active IP Right Cessation
-
2014
- 2014-05-06 US US14/270,810 patent/US9253146B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| TWI380650B (en) | 2012-12-21 |
| EP1872562B1 (en) | 2010-03-03 |
| CN101133625B (zh) | 2011-10-12 |
| CA2602789C (en) | 2015-10-06 |
| US9253146B2 (en) | 2016-02-02 |
| JP4482601B2 (ja) | 2010-06-16 |
| CN101133625A (zh) | 2008-02-27 |
| JP2008536418A (ja) | 2008-09-04 |
| WO2006108808A1 (en) | 2006-10-19 |
| ATE460039T1 (de) | 2010-03-15 |
| TW200709629A (en) | 2007-03-01 |
| CA2602789A1 (en) | 2006-10-19 |
| US8787393B2 (en) | 2014-07-22 |
| BRPI0607516A2 (pt) | 2012-01-17 |
| DE602006012644D1 (de) | 2010-04-15 |
| US20140244862A1 (en) | 2014-08-28 |
| EP1872562A1 (en) | 2008-01-02 |
| US20060227770A1 (en) | 2006-10-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9253146B2 (en) | Preventing duplicate sources from clients served by a network address port translator | |
| BRPI0607515B1 (pt) | método para impedir fontes duplicadas em um protocolo de rede | |
| JP3793083B2 (ja) | トンネリングおよび補償を使用するネットワーク・アドレス翻訳によりセキュリティを与えるための方法および装置 | |
| JP3457645B2 (ja) | ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法 | |
| US9641434B1 (en) | Private network address obfuscation and verification | |
| Srisuresh et al. | IP network address translator (NAT) terminology and considerations | |
| US20150304427A1 (en) | Efficient internet protocol security and network address translation | |
| JP2009111437A (ja) | ネットワークシステム | |
| KR100479261B1 (ko) | 네트워크 주소 변환 상에서의 데이터 전송 방법 및 장치 | |
| Srisuresh et al. | RFC2663: IP network address translator (NAT) terminology and considerations | |
| CN100464540C (zh) | 一种跨网关通信的方法 | |
| CN111903105A (zh) | 多路复用安全隧道 | |
| US20060268863A1 (en) | Transparent address translation methods | |
| JP4769877B2 (ja) | Ｉｐｓｅｃセキュリティ・アソシエーションを折衝するときのネットワーク・トポロジの検出 | |
| Penno et al. | Updates to Network Address Translation (NAT) Behavioral Requirements | |
| Tuexen et al. | RFC 6951: UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication | |
| Mikić et al. | Support of NAT traversal in IKEv2 implementation | |
| Penno et al. | RFC 7857: Updates to Network Address Translation (NAT) Behavioral Requirements | |
| Demerjian et al. | Network Security using E-DHCP over NAT/IPSEC. | |
| MCPHERSON | Eight Security Considerations for IPv6 Deployment | |
| Demerjian et al. | A secure way to combine IPsec, NAT & DHCP |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06G | Technical and formal requirements: other requirements [chapter 6.7 patent gazette] |
Free format text: APRESENTE O DEPOSITANTE DESENHO DO PEDIDO ADAPTADO AO AN NO 127/98, JA QUE CONSTA NA PUBLICACAO WO 2006/108808 A1 DE 19/10/2006. |
|
| B06G | Technical and formal requirements: other requirements [chapter 6.7 patent gazette] |
Free format text: EM ADITAMENTO A EXIGENCIA PUBLICADA NA REVISTA 1973 DE 28/10/2008, APRESENTE O DEPOSITANTE A TRADUCAO DOS DESENHOS QUE CONSTAM NO PEDIDO. |
|
| B11A | Dismissal acc. art.33 of ipl - examination not requested within 36 months of filing | ||
| B04C | Request for examination: application reinstated [chapter 4.3 patent gazette] | ||
| B06T | Formal requirements before examination [chapter 6.20 patent gazette] | ||
| B06F | Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette] | ||
| B07A | Application suspended after technical examination (opinion) [chapter 7.1 patent gazette] | ||
| B06A | Patent application procedure suspended [chapter 6.1 patent gazette] | ||
| B09A | Decision: intention to grant [chapter 9.1 patent gazette] | ||
| B16A | Patent or certificate of addition of invention granted [chapter 16.1 patent gazette] |
Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 02/06/2020, OBSERVADAS AS CONDICOES LEGAIS. |