Protocolo de controle de portas

Benefícios do protocolo de controle de portas

Muitos aplicativos compatíveis com NAT enviam mensagens frequentes em nível de aplicativo para garantir que suas sessões não sejam cronometradas por um dispositivo NAT. O PCP está acostumado a:

• Reduza a frequência dessas mensagens keepalive do NAT

• Reduza a largura de banda na rede de acesso do assinante

• Reduza o tráfego para o servidor

• Reduza o consumo de bateria em dispositivos móveis

Protocolo de controle de porta Versão 2

A partir do Junos OS Release 15.1, o Protocolo de Controle de Portas (PCP) versão 2 é suportado, o que está em conformidade com o RFC 6887. O PCP oferece uma maneira de controlar o encaminhamento de pacotes futuros por dispositivos upstream, como NAT44 e dispositivos de firewall, e uma maneira de reduzir o tráfego continuamente vivo de aplicativos. A versão 2 do PCP oferece suporte à autenticação de nonce. O PCP permite que os aplicativos criem mapeamentos de um endereço IP externo e porta para um endereço IP e uma porta interna. Um payload nonce evita um ataque de repetição e é enviado por padrão, a menos que seja explicitamente desativado.

A verificação da nonce do cliente para solicitações de mapa da versão 2 (para atualização ou exclusão) exige que a nonce recebida na solicitação de mapa original que faz com que o mapeamento do PCP seja preservado seja preservado. A versão da solicitação inicial que permite a criação do mapeamento também é preservada. Esse comportamento de salvar os parâmetros de nonce e versão denota que 13 bytes por mapeamento PCP são usados. Esse pequeno aumento no espaço de armazenamento não é significativo quando combinado com o uso atual de memória de um sistema para um único mapeamento solicitado (levando em conta o mapeamento independente de endpoint (EIM) e a filtragem independente de endpoint (EIF) que são criadas junto com ele). Em uma implantação do cliente, o PCP faz com que mapeamentos de EIM e EIF representem uma fração de todos esses mapeamentos.

Até o Junos Release 15.1, os PICs de serviços oferecem suporte a servidores PCP nos roteadores da Juniper Networks de acordo com a versão 22 do PCP com codificação de mensagens versão 1. Com o PCP sendo refinado da versão de rascunho conforme definido no protocolo de controle de portas (PCP) draft-ietf-pcp-base-22 (expiração de julho de 2012) para uma versão finalizada e padrão conforme definido no RFC 6887 -- Protocolo de controle de portas (PCP), a codificação da mensagem mudou para a versão 2 com a adição de uma carga de pagamento de nonce aleatória para autenticar solicitações de peer e mapa conforme necessário. A versão 1 não decodifica mensagens em conformidade com o formato da versão 2 e a autenticação de nonce não é suportada. Em um ambiente de rede de palavras reais, com dispositivos CPE (Customer Premises Equipment, equipamentos locais do cliente) que oferecem suporte cada vez maior apenas à versão 2, é necessário analisar e enviar mensagens da versão 2. A compatibilidade reversa com dispositivos CPE com suporte à versão 1 é mantida (a negociação de versão faz parte do padrão) e autentica pacotes de payload de solicitação quando as mensagens v2 estão em uso.

A saída do show services pcp statistics comando contém o campo de versão sem suporte pcp, que é incrementado para indicar sempre que a versão não é 1 ou 2. Um novo campo, a nonce de solicitação de PCP não corresponde ao mapeamento existente, é introduzido para indicar o número de solicitações pcp versão 2 que foram ignoradas porque a carga de pagamento da nonce não correspondia à registrada no mapeamento (a autenticação falhou). Se a versão 2 estiver em uso, o nó do cliente é usado para autenticação.