Resumo

  • A revisão 08 de draft-nir-ipsecme-big-payload saiu em 10 de setembro de 2026. O comparador oficial registra datas, expiração, uma correção de palavra e referência atualizada a Classic McEliece, sem redesenhar o mecanismo da revisão 07.
  • O projeto transforma um bit reservado no indicador L, que troca o comprimento de 16 por 32 bits depois do anúncio booleano LARGE_PAYLOAD_SUPPORTED em IKE_SA_INIT.
  • O anúncio não contém teto de bytes, classe de carga, memória, esforço de processamento ou concorrência. O texto permite que a implementação imponha limites de sanidade.
  • O Datatracker ainda mostra candidato ativo do IPSECME, no estado “Call For Adoption By WG Issued”, sem shepherd ou aprovação do IESG. O valor solicitado não consta no registro IANA atual.

O novo campo mede bytes, não disponibilidade

O problema de formato começa no desenho do RFC 7296. O cabeçalho da mensagem IKE completa possui quatro octetos de Length. Já o cabeçalho genérico de cada payload reserva apenas dois octetos para Payload Length. Assim, o invólucro pode representar uma mensagem maior, enquanto uma carga isolada continua abaixo de 65.536 octetos.

O rascunho propõe um uso direto do bit L: desligado, mantém a disposição tradicional; ligado, o comprimento passa a ocupar quatro octetos. Antes de usar a disposição estendida, o remetente precisa ter recebido do outro lado a notificação LARGE_PAYLOAD_SUPPORTED. É uma forma econômica de impedir que um analisador antigo leia o campo errado.

Mas a economia de sinalização cobra uma disciplina de interpretação. A notificação não informa se o limite local é 100 quilobytes ou dez megabytes. Não promete espaço para certificados, listas de exclusão ou qualquer outra classe. Não declara memória de remontagem, tempo máximo de criptografia, número de objetos em voo ou o que acontece quando a máquina já está pressionada. Um “sim” para o formato não é uma procuração para consumir qualquer quantidade expressável por 32 bits.

Cada direção faz sua própria promessa de formato

O aviso aparece durante IKE_SA_INIT, embora o próprio projeto proíba payloads grandes nessa troca inicial. Para material inicial de troca de chaves que não cabe no fluxo comum, ele aponta para o IKE Intermediate Exchange do RFC 9242.

Também não exige simetria. Quem envia a notificação afirma que sabe receber o formato longo. Sem receber a mesma indicação do interlocutor, não pode transmitir payloads longos na direção contrária. A negociação seleciona o analisador disponível em cada sentido; não cria uma reserva de recursos compartilhada nem garante capacidades iguais.

Ao chegar uma carga, o receptor confere se o comprimento anunciado cabe nos octetos restantes da mensagem IKE. Se não couber, a resposta prevista é INVALID_SYNTAX. Se houver dados suficientes, a carga segue o processamento normal e não pode ser rejeitada só porque o comprimento também caberia no formato curto.

Esse dever evita duas sintaxes concorrentes para o mesmo conteúdo. Ele não elimina uma camada posterior de admissão que limite um objeto bem formado por tamanho, custo ou condição operacional.

O exemplo de DELETE mostra as duas fronteiras

Uma carga DELETE pode reunir SPI de associações IPsec. Cada SPI tem quatro octetos, e o contador chega a 65.535 entradas. O cabeçalho atual impede colocar a lista inteira numa única carga. Com o comprimento estendido, o exemplo do rascunho chega a 262.150 octetos.

Há, portanto, utilidade prática em ampliar a representação. Ainda assim, o projeto não obriga todo produto a preparar memória para a maior lista possível. Ele declara que implementações podem impor um limite razoável ao número de SPI dentro de um DELETE. A conformidade do parser e o teto da fila de trabalho permanecem decisões distintas.

Ocultar essa diferença prejudicaria justamente a interoperabilidade. Um emissor encontraria o limite real por timeout, falha genérica ou degradação. Uma equipe poderia classificar uma proteção intencional como falta de suporte. Outra poderia aceitar demais e descobrir a fronteira apenas sob ataque ou pico legítimo. O bit resolve a leitura do cabeçalho; não deve virar uma política implícita de capacidade.

Fragmentação e TCP não concedem recursos

O RFC 7383 fragmenta mensagens IKE criptografadas para atravessar caminhos em que um pacote grande falharia. O RFC 9329 transporta IKEv2 e IPsec sobre TCP quando UDP está bloqueado ou degradado. Ambos tratam da viagem dos octetos, não do orçamento no destino.

Fragmentos consomem estado até a remontagem. Uma conexão TCP pode entregar dados com confiança e ainda alimentar trabalho acima do que o sistema deseja executar. Há pelo menos três decisões: qual formato representa o comprimento, como os bytes atravessam a rede e qual quantidade a política local admite. Misturá-las deslocaria autoridade para o emissor sem um campo de protocolo que sustente esse deslocamento.

Uma atualização editorial em um processo ainda não concluído

A revisão 08 foi enviada em 10 de setembro. A diferença oficial diante da 07 atualiza datas e vencimento, corrige than para that e renova uma referência a Classic McEliece. Nenhum limite quantitativo ou mecanismo de orçamento foi introduzido. A notícia técnica é continuidade, não uma mudança de arquitetura.

No processo, os registros precisam ser lidos em conjunto. O Datatracker associa o documento ao IPSECME e exibe “Call For Adoption By WG Issued”. O histórico registra a definição do grupo e do stream IETF e a abertura da chamada em 22 de julho. A mensagem à lista aceitava comentários até 15 de agosto. O anúncio automático da revisão 08 o chama de “work item” do IPSECME.

Por outro lado, a página atual continua dizendo Candidate, não lista shepherd, mantém “I-D Exists” no IESG e não mostra Area Director responsável ou telechat. O nome draft-nir é indício compatível com origem individual, não ato decisório. Relatar apenas um desses sinais produziria uma certeza que o próprio registro não oferece.

O texto pretende Standards Track e afirma que atualizaria o RFC 7296 se aprovado; o metadado do Datatracker mostra intended status “(None)”. Trata-se de diferença documental, não aprovação. O registro IANA de Notify Message Status Types do IKEv2 também não contém LARGE_PAYLOAD_SUPPORTED. O pedido de número ainda não é uma atribuição. As fontes analisadas não provam consenso IETF, aprovação do IESG, RFC publicado, implementação, teste de interoperabilidade, implantação ou incidente.

Fontes