Resumo

  • RFC 9868 usa o espaço do transporte IP que fica depois de UDP Length como surplus area para opções; ele não é dado de usuário UDP.
  • DTLS protege os dados de usuário, não a opção de transporte. Uma carga cifrada, uma OCS aprovada ou uma opção emitida não demonstram, sozinhas, que a opção foi protegida, aceita ou teve consequência.

Uma extensão pode ser tecnicamente correta e ainda assim sustentar uma conclusão errada. RFC 9868 explora a possibilidade de UDP Length apontar para menos bytes do que o espaço de transporte indicado por IP. Os bytes até esse limite formam o dado de usuário; os demais podem ser interpretados como opções por uma implementação que conhece o mecanismo. Essa separação é útil para transporte, mas não certifica o receptor, a rota nem o uso posterior pela aplicação.

O RFC preserva a natureza mínima do UDP. O protocolo continua sem estado e unidirecional; UDP Options é um quadro de opções, não uma conversa completa. Fora do conjunto que deve ser suportado por implementações que adotam a extensão, o emissor não força trabalho no receptor. Uma opção opcional pode ser ignorada sob configuração local. Assim, o fato de ter colocado uma opção no datagrama é apenas evidência da construção e emissão local.

O limite da proteção não admite atalho. RFC 9868 afirma que TLS e DTLS não protegem a camada de transporte: DTLS opera sobre os dados de usuário UDP. Também informa que o mecanismo não dá proteção específica contra mudança de cabeçalho, carga ou área excedente, salvo a fornecida por OCS, AUTH, UENC ou outra camada como IPsec. Sem criptografia aplicável, a opção continua visível no caminho. Dizer que há DTLS não prova confidencialidade, autenticidade ou integridade de uma opção ao lado da carga.

OCS tem uma função própria: detectar erro na área excedente. Não concede autorização, não atesta o caminho e não decide uma ação. O comportamento compatível com UDP legado pode entregar dados de usuário e ignorar opções após falha de uma OCS aplicável. Para fins de controle, o registro deve dizer qual política local avaliou a opção e qual foi o resultado local, não transformar uma soma em um selo genérico de segurança.

RFC 9869 mostra por que a sintaxe não basta. Seu DPLPMTUD com UDP Options requer habilitação no emissor e no receptor e confirmação explícita de uma sonda. Mesmo isso produz evidência limitada à troca observada. RFC 9868 observa que alguns caminhos podem remover a área excedente ou descartar datagramas com opções. Emissão, proteção selecionada, capacidade do par, observação de caminho e efeito de aplicação precisam manter suas identidades separadas.

O método de Heng Lu ajuda a conservar essa ordem. RFC 9868 disponibiliza um artefato comum e testável. Ativar o recurso, escolher proteção, definir o que fazer após uma falha e decidir se uma evidência basta para ação são escolhas locais. A opção só continua útil enquanto não se transforma na prova de uma decisão ou de um resultado que ela não contém.

Sources