Resumo

  • O RFC 2356 propôs que o firewall identificasse um nó Mobile IP por um seletor NSID/MKID estável, e não pelo care-of address que mudava a cada ponto de conexão.
  • O primeiro pacote autenticado podia iniciar o encaminhamento sem uma negociação anterior, mas componentes públicos confiáveis, ACL nômade, vínculo dinâmico e travessia correta continuavam indispensáveis.

O problema começava com duas frases verdadeiras e incompatíveis para um filtro simples. A máquina era a mesma. O endereço de onde ela enviava já não era.

O Mobile IP do RFC 2002 tinha separado o endereço residencial, estável, do care-of address, associado à conexão atual. Um home agent interceptava o tráfego dirigido ao endereço residencial e o encaminhava ao ponto em que o nó estava. Essa arquitetura preservava a continuidade de roteamento, mas retirava do endereço de origem a função cômoda de identificar o dispositivo perante o firewall.

Publicado em junho de 1998 como Informational, o RFC 2356 descreveu uma proposta de G. Montenegro e V. Gupta, da Sun Microsystems. Não era um padrão da Internet. Tratava de um caso delimitado: um nó pertencente a uma rede privada protegida, conectado diretamente à Internet pública por um care-of address co-localizado. Não resolvia o cenário em que esse nó estivesse atrás de outra rede privada.

O texto comparava o relé de aplicações do SOCKS 5 com uma solução no nível IP baseada em SKIP. A característica atraente do SKIP era ser descrito como gerenciamento de chaves sem sessão. As informações de autenticação podiam acompanhar cada pacote, permitindo que o firewall encaminhasse já o primeiro pacote autenticado, sem esperar uma troca específica para estabelecer sessão.

Essa economia de ida e volta não eliminava a preparação da confiança. Nó móvel, firewall e home agent precisavam dos componentes públicos Diffie-Hellman autenticados uns dos outros. Eles podiam ser configurados antes ou obtidos por diretório e descoberta de certificados. O pacote chegava pronto para ser avaliado; a relação entre nome e chave não surgia naquele instante.

O passo decisivo era mudar o índice da associação de segurança. Em vez de procurar apenas os endereços fonte e destino, o cabeçalho SKIP podia carregar um NSID, que definia o espaço de nomes, e um MKID, que selecionava a identidade. Com NSID 1, o MKID podia usar o endereço residencial estável mesmo que o cabeçalho externo exibisse um care-of address temporário. Com NSID 8, o identificador podia derivar do componente público Diffie-Hellman não assinado, embora os nomes dos participantes ainda precisassem ser comunicados de modo seguro na ausência de uma autoridade certificadora.

Assim surgia a entrada nomadic na lista de controle de acesso. Ela não autorizava qualquer endereço. Ela dizia ao firewall que pacotes vindos de fontes variadas poderiam ser avaliados como pertencentes a uma identidade de chave específica. O pacote ainda precisava passar pela autenticação AH — ou por uma transformação ESP que também autenticava — e a política local ainda precisava permitir aquele destino e uso.

Quando o nó iniciava o contato, o firewall observava o care-of address e criava uma ligação dinâmica entre a identidade da chave, o endereço residencial e o endereço atual. Esse vínculo servia ao tráfego de retorno. Seu significado, porém, era “último endereço autenticado sob estas regras”, não “localização universalmente confirmada”. A solicitação de registro mais recente substituía a anterior. Vínculos Mobile IP simultâneos exigiriam que o firewall entendesse melhor as mensagens de registro.

O estado aprendido também prendia a resposta a um caminho. Se um firewall criasse o vínculo ao ver a Registration Request, a Registration Reply deveria normalmente sair pelo mesmo equipamento. Em um perímetro com vários firewalls, uma rota assimétrica podia levar a resposta a um dispositivo sem estado. Um firewall consciente do protocolo Mobile IP poderia recuperar informações na resposta e reduzir essa dependência, ao custo de interpretar mais semântica no meio da rede.

Antes do vínculo havia outra escolha: classificar a conexão como interna ou externa. Faixas de endereços ajudavam, mas o RFC reconhecia que instalações reais podiam tornar a distinção difícil. A indicação direta da pessoa usuária podia ser valiosa, pois ela sabia que estava fora mesmo quando o endereço era ambíguo. Tal indicação era evidência operacional, não prova de localização física ou de vínculo empregatício.

O home agent precisava saber por quais limites encaminhar. A Traversal Extension, incluída em solicitações e respostas de registro, transportava endereços de travessia nos dois sentidos e podia representar vários firewalls. Valores aprendidos da direção oposta podiam funcionar como indícios. A presença de um endereço na extensão não provava que autenticação, encapsulamento ou passagem tivessem ocorrido.

O RFC examinava ainda quatro arranjos de canal. A criptografia podia cobrir apenas o lado público. Podia ser ponta a ponta, deixando o firewall como relé e o home agent como autenticador. Uma autenticação intermediária podia dar visibilidade de identidade ao firewall, mas exigia revelar a ele um segredo Diffie-Hellman pareado e duradouro. Ou dois canais cifrados separados podiam terminar no firewall, permitindo inspeção entre eles. Um túnel adicional entre nó e home agent restabeleceria sigilo perante o próprio firewall.

Essas escolhas mostram por que “tráfego criptografado” não determina quem enxerga nem quem decide. O encapsulamento IP-in-IP do RFC 2003 tornava endereços internos transportáveis através de outro espaço de roteamento. AH autenticava. ESP cifrava e podia autenticar. São controles distintos; nenhum deles, isoladamente, demonstra que a aplicação interna recebeu ou aceitou a mensagem.

No retorno, o home agent capturava o pacote para o endereço residencial, encapsulava-o rumo ao care-of address e o enviava pelo firewall. O firewall consultava o vínculo dinâmico e protegia o trecho público. Uma Registration Reply bem-sucedida, um vínculo criado e um pacote retransmitido eram marcos úteis. Ainda não eram a resposta do correspondente nem o resultado visto pelo usuário.

A seção de segurança deslocava parte do perímetro para o notebook. O nó podia continuar fazendo tráfego público sem criptografia para DHCP ou cobrança, portanto precisava de capacidade própria de filtragem. Se fosse comprometido, sua identidade válida poderia abrir caminho à rede privada. Resolver a continuidade de identidade também aumentava o dano de conceder autoridade demais a um dispositivo móvel.

O valor histórico do RFC 2356 está nessa separação. Fonte externa observada, endereço residencial alegado, NSID/MKID, origem do componente público, resultado de AH ou ESP, decisão da ACL, criação e expiração do vínculo, classificação de lado, extensão de travessia, registro, relé, entrega e efeito na aplicação são recibos diferentes. A expressão “usuário confiável” não pode substituí-los.