Resumo

  • O PCAP v2 só contém pacotes em um formato LinkType. O projeto observa que isso frequentemente corresponde a uma interface, porque nem todo LinkType identifica interface; frequência operacional não é garantia do formato.
  • Agregação, replay e conversão podem colocar várias origens sob uma gramática comum. Preservar a procedência exige recibos anteriores à normalização, não inferência posterior a partir do cabeçalho.

O arquivo parecia simples. Um cabeçalho, um LINKTYPE_ETHERNET, milhares de registros. O relatório atribuiu todos os fluxos ao tap de borda citado no nome do arquivo e montou uma linha do tempo contínua.

Na realidade, o arquivo era uma entrega composta. Um agente havia exportado tráfego de uma máquina virtual; um packet broker havia espelhado outra parte; um laboratório reproduzira três sessões; e um sensor de filial enviara registros por um formato próprio. Antes da entrega, um serviço converteu tudo para quadros com aparência Ethernet e removeu as informações de origem que não cabiam no PCAP legado.

O LinkType estava correto. A procedência estava ausente.

Essa diferença é o centro de Link-Layer Types for PCAP-related Capture File Formats. A revisão 18 é de 6 de abril de 2026 e expira em 8 de outubro de 2026. No corte de 3 de outubro, era um Internet-Draft OPSAWG ativo, destinado a Informational, na fila do RFC Editor aguardando o primeiro editor e ainda sem número RFC. O avanço editorial não certifica uma ferramenta nem uma cadeia de captura.

O projeto propõe um registro IANA para valores LinkType usados por PCAP e pcapng. O número de 16 bits seleciona o formato de metadados e encapsulamento de camada 2 que precede o pacote capturado. Ele diz ao leitor onde procurar os campos. Não diz quem observou o evento.

A palavra decisiva é “frequentemente”

O projeto PCAP-09 documenta uma limitação importante do formato v2: um arquivo só pode conter pacotes em um formato LINKTYPE. Isso frequentemente significa que os pacotes vêm de uma única interface, pois nem todos os tipos fornecem uma forma de indicar de qual interface veio cada pacote.

O raciocínio operacional é compreensível. Uma ferramenta abre uma interface, escolhe um tipo e grava um arquivo. Durante décadas, esse foi um caminho comum. Mas o cabeçalho não contém a garantia “todos os registros foram adquiridos pela mesma interface”. Ele contém um contrato de representação.

Uma etapa de normalização pode converter origens heterogêneas para a mesma forma. Um replay pode gerar registros sem observação ao vivo. Um arquivo pode ser recortado, concatenado ou produzido por exportação. Uma captura Ethernet pode ter vindo de um switch virtual, de um túnel já desencapsulado ou de um gerador.

Se a plataforma lê “um LinkType” e grava “uma origem”, ela preenche com certeza um campo que o formato não entregou. O problema não é apenas documental. Correlação de incidentes, atribuição de segmento, cálculo de alcance e ações automatizadas passam a depender de uma identidade inventada.

pcapng cria espaço para procedência, não verdade automática

pcapng supera parte da limitação. Interface Description Blocks guardam LinkType e SnapLen; Enhanced Packet Blocks podem apontar para um Interface ID. O mesmo arquivo pode representar várias interfaces.

Ainda assim, o ID é único somente dentro da Section. O número zero em uma Section posterior pode designar outra interface. Simple Packet Blocks não carregam Interface ID e se referem implicitamente à primeira descrição. Uma ferramenta que funde seções sem preservar o escopo pode ligar pacotes ao sensor errado.

Opções como nome, descrição, sistema operacional e filtro de captura enriquecem o contexto. Mas são declarações do escritor. Um arquivo estruturalmente válido pode chamar uma interface de tap-borda sem ter passado por ela. A procedência nasce quando essas declarações são ligadas a configuração do sensor, identidade do produtor, relógio, hash de aquisição e cadeia de custódia verificáveis.

O ganho do pcapng é permitir um envelope melhor. Não é abolir a necessidade do envelope.

Normalização precisa deixar recibo

Uma conversão legítima muda a representação. Pode remover um pseudo-header local, transformar um DLT do sistema em LinkType portável, ajustar byte order ou reunir registros em um formato que as ferramentas de destino compreendam. O erro é tratar essa mudança como se não tivesse ocorrido.

O projeto alerta que DLT e LinkType costumam ter o mesmo valor numérico, mas nem sempre. Alguns DLT são específicos do sistema operacional e não são padronizados. Copiar apenas o inteiro pode escolher a gramática errada em outro ambiente.

O recibo mínimo deve conservar arquivo e hash originais, namespace DLT ou LinkType, sistema e biblioteca produtores, regra e versão do conversor, perdas introduzidas, LinkType final, agrupamento de origem e validação. Se vários sensores entram em um arquivo, cada registro precisa manter uma referência estável ao lote e à origem, ou o produto deve declarar explicitamente que essa distinção foi perdida.

Uma identidade desconhecida é operacionalmente desconfortável, mas honesta. Uma identidade inferida do formato é confortável e falsa.

SnapLen também limita o que a origem pode afirmar

PCAP registra Captured Packet Length e Original Packet Length. SnapLen pode cortar o restante. O formato do que ficou é definido pelo LinkType, mas o conteúdo removido não reaparece porque a gramática foi reconhecida.

O projeto LinkType destaca o risco de campos internos anunciarem comprimentos maiores do que os bytes armazenados. Isso pode causar leituras além do buffer se o parser não validar cada acesso. Como o arquivo pode ser controlado por um atacante, a entrada deve ser tratada como arbitrária.

Há também uma consequência para a investigação. Um padrão ausente depois do limite de captura é desconhecido, não negativo. Se a normalização elimina as duas medidas de comprimento, a análise perde até a prova de que houve truncamento.

Por isso o envelope precisa combinar procedência e cobertura: quem capturou, onde, com qual filtro, direção e SnapLen; quantos bytes chegaram; o que a transformação conservou; qual parser leu; quais campos falharam.

Registro oficial não resolve cadeia de custódia

O registro proposto reserva 0–65000 para Expert Review e 65001–65535 para uso experimental. Os valores privados históricos 147–162 continuam suportados, mas novos usos devem preferir a faixa experimental. Valores experimentais em geral não devem sair da entidade que os usa.

Essa política evita que significados locais colidam no intercâmbio. O especialista pode identificar duplicação e exigir uma descrição clara dos octetos antes de IPv4 ou IPv6. Mas especificação pública não é requisito; uma especificação privada e um contato podem bastar.

Isso delimita a autoridade do registro. Ele coordena número e gramática. Não autentica o arquivo, não prova o sensor, não garante que metadados são verdadeiros e não autoriza uma ação de resposta.

O princípio de camadas de realidade de Heng Lu torna a arquitetura objetiva. O pacote em execução, a observação do sensor, a política de retenção, o arquivo, a conversão, o decode, a hipótese e a ação são estados diferentes. Um número no quinto estado não pode adquirir retroativamente a autoridade do segundo.

O teste de código deve montar um arquivo com várias origens normalizadas sob um LinkType; reutilizar Interface ID em duas Sections; falsificar if_name; truncar uma carga decisiva; copiar um DLT incompatível; enviar um valor experimental ambíguo. O sistema maduro conserva o fato estreito que conseguiu provar e marca os demais como declarados, desconhecidos ou conflitantes.

Um LinkType único torna os bytes legíveis em conjunto. Não torna a história deles única.

Fontes