Summary

  • O RFC 2979 separou a recusa de segurança intencional da falha involuntária de um uso conforme; a segunda cabia ao firewall e aos softwares associados.
  • Os exemplos de descoberta do MTU e de extensões SMTP mostraram como um intermediário podia interromper uma conversa ao aplicar uma regra aparentemente simples.

Negar por política não é o mesmo que quebrar o protocolo

Por volta de 2000, o ideal de comunicação de ponta a ponta encontrava uma fronteira prática. Organizações conectavam sistemas internos valiosos a redes que não controlavam plenamente e usavam firewalls como pontos de triagem. Mas o comportamento desses dispositivos era muitas vezes pouco especificado e variava entre implementações, criando problemas além da política que deveriam aplicar.

O RFC 2775 já tratava “transparência” como várias questões arquiteturais: funções de ponta a ponta, desempenho e transparência de endereços. O RFC 2979 delimitou a discussão a um contrato operacional. A introdução de um firewall, túnel ou mecanismo de negociação de acesso não devia provocar a falha involuntária de um uso legítimo e conforme aos padrões que funcionaria sem ele. Se isso acontecesse, era preciso corrigir o firewall ou o software associado; não se devia exigir uma mudança no protocolo existente ou em sua implementação.

Isso não obrigava a liberar todo pacote. O RFC reconhecia que cada local podia bloquear acessos que considerasse ilegítimos, mesmo quando o tráfego seguisse um padrão. Também admitia mecanismos adicionais de autenticação ou autorização, como SOCKS, inclusive configurações que os exigissem, mas pedia que houvesse configurações em que não fossem obrigatórios. A distinção essencial era entre uma recusa deliberada conforme a política e uma quebra acidental causada por um intermediário que não entendia a comunicação.

Descartar uma resposta ICMP podia criar um buraco negro

O exemplo de Path MTU Discovery tornava a regra concreta. Em IPv4, o remetente podia marcar um pacote com Don't Fragment. Se um enlace posterior não pudesse transportá-lo, um roteador devolvia ICMP “Destination Unreachable / Fragmentation Needed” para que o remetente diminuísse o pacote. Um firewall que permitisse a saída, mas descartasse a resposta correspondente, podia deixar o remetente repetindo tráfego grande demais: um buraco negro, não uma decisão de segurança útil.

O RFC não dizia que todo ICMP devia passar. Diferenciava o erro relacionado a tráfego legítimo de saída de Echo, Redirect ou erros sem relação, que podiam ser bloqueados. O contexto importava: a mesma família de protocolos continha informações de controle necessárias a uma troca válida e mensagens que uma política podia recusar.

A lista EHLO podia criar um impasse entre três partes

No SMTP, o cliente pergunta pelas extensões usando EHLO; o servidor anuncia o que suporta; e o cliente pode escolher uma capacidade. Um proxy que apenas aceitasse o comando EHLO, sem filtrar a lista de respostas do servidor, podia permitir que os dois extremos concordassem sobre uma extensão que o proxy não compreendia. Ambos os lados agiam de forma plausível, mas o intermediário deixava passar uma conversa que não sabia transportar corretamente.

A lição não era obrigar cada firewall a implementar todas as extensões novas. O RFC recomendava facilitar a operação através de firewalls quando isso não prejudicasse a aplicação. Também alertava contra encapsular um novo protocolo em HTTP apenas porque a porta 80 provavelmente estaria aberta; um subconjunto seguro, um mecanismo apropriado de travessia ou uma porta registrada separadamente podiam ser escolhas mais honestas.

O que o RFC mostra — e o que não comprova

O RFC 2979 é Informativo, não um Padrão da Internet. O histórico do rascunho registra a aprovação pelo IESG em agosto de 2000 e a publicação em outubro. O documento comprova um princípio de projeto e exemplos, não a adoção por produtos, taxas de conformidade, a redução de desvios ou ganhos de segurança mensurados.

Sua contribuição histórica foi demarcar responsabilidades: uma política de segurança podia negar um fluxo, mas uma incompatibilidade acidental não devia virar silenciosamente o problema do desenvolvedor de aplicações. Hoje, um operador pode classificar uma falha perguntando: houve uma recusa deliberada ou um filtro, proxy ou analisador quebrou o uso conforme? Essa é uma inferência operacional, não uma medição do comportamento dos operadores na época.

O RFC 3093 é um artefato próximo, mas diferente: publicado em abril de 2001 e datado do dia 1º, propôs o Firewall Enhancement Protocol, que encapsularia IP/TCP em HTTP. Ele não prova que o RFC 2979 falhou nem que o túnel foi implantado. Filtragem também não é sinônimo de NAT: o RFC 2979 trata as funções separadamente, mesmo quando o mesmo equipamento executa ambas.

Fontes: RFC 2979; RFC 2775; RFC 3093; histórico do rascunho; RFC 1191; RFC 1869.