Resumo

  • Em RFC 5189, o agente propõe um lifetime; o middlebox concede um valor limitado pelo pedido e pelo máximo anunciado na sessão. Só o valor concedido autoriza calcular a validade atual.
  • PRR pode reservar recursos sem mudar o processamento de pacotes. PER instala uma regra local, mas ainda não comprova travessia, recepção remota ou resultado da aplicação.

O erro começou antes de qualquer pacote. O banco tinha lifetime=3600, retirado da requisição. A resposta continha 600, mas foi arquivada como detalhe de protocolo. Dez minutos depois, o pinhole terminou conforme a autoridade que o criou.

Uma plataforma de controle precisa distinguir intenção, concessão e observação. O pedido descreve quanto tempo o agente gostaria de possuir a regra. A resposta descreve quanto tempo o middlebox aceitou. Uma leitura posterior descreve quanto ainda resta. Nenhum desses campos substitui os outros.

Reserva é capacidade futura

Policy Reserve Rule existe para quando o agente ainda não possui todos os parâmetros de uma regra de fluxo. Ele pode reservar endereço, porta ou faixa para uso futuro. O equipamento decide se a reserva ocorre no lado externo, nos dois lados ou em nenhum, conforme sua função.

PRR não cria binding e não abre pinhole. O texto normativo mantém o processamento de pacotes inalterado. Em um firewall puro, a transação pode ter sucesso com endereços e portas vazios, porque não há recurso NAT para reservar.

O recibo, portanto, precisa informar mais que sucesso. Deve guardar capacidade, interface, protocolo, faixa, paridade, tuples solicitados e retornados, regra, grupo e estado RESERVED. Valores vazios são evidência, não lacunas a preencher.

O lifetime concedido limita essa reserva. Se ela não for substituída por PER nem renovada, o recurso volta a ficar disponível. Um painel que usa o prazo pedido pode anunciar capacidade exclusiva depois de a exclusividade ter acabado.

Habilitação é outra decisão

Policy Enable Rule altera o processamento. Em NAT, instala bindings; em firewall, ações allow; em equipamento combinado, ambos. Ela pode consumir PRR ou ir diretamente de regra inexistente a ENABLED.

Ao substituir a reserva, PER pode reutilizar o identificador. A continuidade do ID liga os dois atos, mas não transforma retroativamente RESERVED em ENABLED. O histórico deve guardar a transição e o horário de cada resposta.

Se PER falha, PRR permanece. A equipe ainda possui uma reserva com seu próprio relógio, embora não tenha comunicação habilitada. Corrigir a solicitação, tentar de novo, excluir com lifetime zero ou esperar expirar são decisões diferentes.

PER bem-sucedida é um recibo local forte, não um teste fim a fim. O pacote ainda pode encontrar outra ACL, rota ausente, listener fechado ou recusa da aplicação. Capturas nos dois lados e um recibo do endpoint completam a afirmação de resultado.

Três números de tempo, três autoridades

No estabelecimento da sessão, o middlebox anuncia seu lifetime máximo. Em PRR, PER, RLC ou GLC, o agente envia um valor desejado. A resposta traz o concedido, menor ou igual ao pedido e ao máximo.

Essa regra impede que a intenção do controlador amplie a autoridade local. Também obriga observabilidade: requested, maximum, granted, observed remaining e expiry calculado devem permanecer ligados à mesma versão.

RLC pode pedir extensão, redução ou terminação com zero. O pedido de extensão pode falhar, preservando a duração anterior. Uma resposta de sucesso com zero termina a regra. Eventos assíncronos também podem alterar ou encerrar o estado.

O tempo não pertence apenas ao agente. Outro agente autorizado ou o próprio middlebox pode causar mudança. A notificação deve registrar origem, ordem e momento; uma última fotografia não explica por que o relógio mudou.

Sessão encerrada, lifetime ainda correndo

RFC 5189 mantém regras estabelecidas depois do encerramento normal, assíncrono ou por interrupção da sessão MIDCOM. Elas continuam até o próprio fim ou outro evento de terminação.

Essa independência protege tráfego de uma falha do controlador. Ao mesmo tempo, cria regras órfãs do ponto de vista operacional. O canal que poderia explicar a decisão já não existe, mas a decisão continua no equipamento.

Por isso o inventário não pode depender da sessão viva. Ele precisa preservar agent autenticado, owner, request, regra, grupo, lifetime concedido e eventos. “Controller offline” não deve significar “regra removida” nem “regra sem dono”.

Owner e grupo distribuem poder

O agente autenticado que cria a regra torna-se owner por toda a vida dela. Uma política local pode permitir que outro agente atue sobre regras desse owner. O poder delegado deve ser registrado; conexão atual não basta para atribuir a mudança.

Cada regra pertence a um grupo, e todos os membros compartilham owner. O grupo nasce com o primeiro membro e termina com o último. Seu lifetime deriva do maior lifetime restante dos membros até que GLC imponha um valor comum.

GLC zero encerra todas as regras do grupo. O ato é único, mas os efeitos são diferentes: remover RESERVED libera recurso; remover ENABLED também muda o tráfego. A tela de grupo deve manter estados e histórias por membro.

Atomicidade não elimina eventos

As request transactions são atômicas entre si. O agente não deve observar um estado intermediário estável. Uma transação assíncrona, porém, pode interromper ou terminar o processamento. Uma implementação que divide uma operação semântica pode mudar essa garantia.

Conflitos seguem first-come-first-served: a regra nova contraditória é rejeitada, a antiga fica. Sobreposições não conflitantes, inclusive idênticas, podem ser aceitas. A admissão determina configuração, não prova que um pacote passou.

O registro necessário

Guardar change, session, request, agent, owner e middlebox imutáveis; capacidade, interface, tipo de transação, rule ID, group ID e estado anterior. Em PRR, conservar todos os tuples e vazios. Em PER, conservar referência à reserva, direção, wildcards, bindings e pinholes.

Guardar requested, maximum e granted lifetime, razão de falha, conflito e sobrevivência de PRR. Acrescentar status e REN, GEN ou STN em ordem. Separar session end de rule end.

Por fim, ligar capturas, recepção remota, resposta da aplicação, expiry e rollback. Sem essa última camada, a frase honesta é “regra local válida até o prazo concedido”. Não é “serviço disponível por uma hora”.

Fontes

  1. RFC 5189 HTML
  2. RFC 5189 texto
  3. Registro RFC 5189
  4. Datatracker RFC 5189
  5. Histórico RFC 5189
  6. Referências RFC 5189
  7. Errata RFC 5189
  8. RFC 3989
  9. Registro RFC 3989
  10. RFC 3303
  11. Registro RFC 3303
  12. RFC 3304
  13. Registro RFC 3304
  14. RFC 3198
  15. RFC 3234
  16. RFC 3022
  17. RFC 6887
  18. Heng Lu — camadas de realidade
  19. Heng Lu — especificação inicial mínima
  20. Heng Lu — primazia do código em execução