Resumo

  • No RFC 5320, a saída relata fragmentação IPv4 externa, a entrada compara a mensagem com uma janela de SEAL_ID e altera o S_MSS da próxima geração de segmentos.
  • Um recibo confiável separa intenção de sonda, identidade de 32 ou 16 bits, observação, atualização, remontagem IPv4, remontagem SEAL, entrega superior e a condição Experimental do documento.

Uma avaria virou amostra

O encapsulamento atravessa uma topologia virtual cujos enlaces físicos podem ter MTUs diferentes. O SEAL normalmente envia o IPv4 externo com DF=0. Um roteador pode fragmentá-lo, a saída pode informar o evento e a entrada reduz os segmentos seguintes até que a fragmentação desapareça.

A ideia é útil porque transforma um sintoma em entrada para um controle. Mas o sintoma continua estreito. O primeiro fragmento mostra que um pacote encontrou algum limite menor. Não nomeia o enlace, não fixa a MTU permanente, não confirma os demais fragmentos e não observa a aplicação.

Portanto, “relato aceito” e “caminho validado” não são estados equivalentes. O primeiro pode justificar um ajuste. O segundo exigiria evidência independente em várias fronteiras.

O NAT reduz o contrato de identidade

No modo comum, SEAL_ID tem 32 bits: a extensão de 16 bits no cabeçalho SEAL forma a metade alta e o Identification IPv4 externo forma a metade baixa. A entrada escolhe um início aleatório por saída e incrementa módulo 2^32.

Um NAT IPv4 pode reescrever a metade externa. Nesse modo, apenas a extensão de 16 bits permanece como identidade, avançando módulo 2^16; o campo externo recebe um valor aleatório. Juntar os dois campos depois da tradução criaria uma identidade que nenhum extremo manteve.

Mesmo uma correspondência correta só vincula o retorno ao estado recente. Ela não autentica os roteadores, o conteúdo ou o desfecho do pacote. O recibo deve registrar o modo, a época do estado flexível e a janela usada.

S_MRU e S_MSS respondem a perguntas distintas

S_MRU, inicialmente no máximo 2 KB, limita o que a saída deve remontar. S_MSS limita cada segmento e deriva da MTU IPv4 inferior, dos cabeçalhos e de um piso relacionado a S_MRU/8.

Chamando ambos de “MTU do túnel”, perde-se a responsabilidade de cada variável. Uma governa a obrigação de reconstrução; a outra, o tamanho de emissão. Reduzir S_MSS não muda automaticamente a MTU apresentada à origem interna. Um pacote interno grande e não fragmentável ainda pode ser descartado, com PTB para a origem.

O registro precisa manter MTU de interface, sobrecargas, S_MRU, valor e geração de S_MSS, tamanho interno, permissão de fragmentar e o sinal que autorizou a transição.

Segmentação e fragmentação são atos diferentes

O SEAL pode dividir o pacote intermediário em até oito segmentos sem sobreposição. Os não finais têm o mesmo tamanho; o último não é maior; o bit More Segments e o número de três bits descrevem a sequência. A saída recompõe antes de entregar acima.

Isso não é fragmentação do IPv4 interno, nem fragmentação do IPv4 externo por um roteador. As três operações têm produtores, identidades, pontos de remontagem e respostas diferentes. Um contador único chamado “fragmentos” não explica o que ocorreu.

A remontagem IPv4 externa pode ter sucesso e a remontagem SEAL falhar. A segunda pode ter sucesso e a camada superior rejeitar o resultado. Nenhuma etapa preenche automaticamente a seguinte.

R e A pedem evidências diferentes

Com R=1 no segmento zero, a entrada pede um relato caso o IPv4 externo fragmente. A=1 pede confirmação. Uma sonda explícita pode levar dados ou ser NULL com No Next Header, e seu SEAL_ID entra na janela de envios pendentes.

Se R e A estiverem presentes e houver fragmentação, a saída manda um Fragmentation Needed, não duas confirmações independentes. O motivo original do envio precisa sobreviver no registro.

O silêncio também é ambíguo. A saída pode limitar relatos sem confirmação; a sonda ou a resposta pode se perder; ou não houve fragmentação. Ausência de mensagem não escolhe uma dessas hipóteses.

O primeiro fragmento pode mentir sobre o limite

ICMP bruto é uma pista flexível: pode ser forjado e citar pouco do pacote. O retorno encapsulado por SEAL e dentro da janela atual tem associação melhor, mas ainda pode não revelar a MTU do enlace restritivo.

Na fragmentação runt, o primeiro pedaço é menor que o limite real. Por isso o RFC 5320 usa busca iterativa: reduzir, enviar na nova geração e observar outra vez. Uma medida isolada não vira verdade permanente.

Somente o primeiro relato aplicável deve alterar S_MSS em uma geração. Mensagens posteriores do estado antigo não são ordens novas de redução. Uma nova decisão espera tráfego produzido sob o novo valor.

Correlação não é autenticação

Nonce, identidade e janela recente reduzem a aceitação de mensagens sem contexto. Ainda assim, o cabeçalho SEAL pode ficar visível sem IPsec, e integridade de camada 2 cobre apenas um trecho local. O conjunto não atesta criptograficamente o caminho.

A interface deve dizer “retorno associado a envio ainda ativo”, acompanhado por modo NAT, época, janela, geração e tipo de sonda. “Caminho autenticado” transformaria correlação temporal em garantia de segurança.

Remontagem tem permissão para desistir

A saída controla marcas d'água, lacunas, duplicatas, reordenação e pressão de memória. A espera expira em 15 segundos. Um conjunto incompleto pode ser descartado mesmo depois de um relato válido ter voltado à entrada.

O encadeamento correto registra separadamente cápsula recebida, IPv4 externo remontado, segmentos SEAL reconstruídos, pacote entregue ao protocolo superior e resultado observado. Sucesso do ajuste não é sucesso da aplicação.

Experimental limita a autoridade institucional

O RFC 5320 foi publicado em fevereiro de 2010 como Independent Submission Experimental. A nota do IESG informa que ele não passou pelo processo normal de consenso. SEAL_PROTO, SEAL_PORT e SEAL_OPTION são valores experimentais e não devem aparecer em produtos enviados ou implantações comuns.

RFCs posteriores sobre Identification, fragmentação e descoberta de MTU enriquecem a avaliação, mas não transformam retroativamente o SEAL em padrão. Um número RFC identifica um documento; não concede autorização de produção.

O recibo da decisão

Guardar horário, entrada, saída, modo 32/16 bits, época, SEAL_ID, R, A, NULL ou dados, tamanho transmitido, janela ativa, S_MRU, valor e geração de S_MSS, fragmento observado, origem do relato, mudança aprovada e resultados separados das duas remontagens e da entrega superior.

Um sistema adaptativo apaga os sintomas que o ensinaram. Sem o recibo, sobra o parâmetro e desaparece sua justificativa. O sinal continua útil quando permanece dentro da autoridade que realmente possui.

Fontes