Resumo

  • A revisão 15 do rascunho UCL do OPSAWG amplia o modelo de ACL do RFC 8519 com grupos de endpoints e uma agenda efetiva por ACE, reutilizando o modelo de agendamento do RFC 9922.
  • Uma regra armazenada com o horário correto não comprova que todos os PEPs a ativaram no mesmo instante. A evidência precisa unir relógio, fuso, revisão, estado ativo, correspondência de pacotes e resultado do serviço.

O relatório de conformidade mostrava duas configurações iguais. O mesmo Group ID, a mesma ACE, o mesmo período finalizando às 18h e a mesma revisão do controlador. Ainda assim, às 18h03, uma conexão continuava aberta quando passava pela segunda fronteira.

A equipe procurou primeiro uma diferença de texto. Não havia. A diferença estava no momento de aplicação. Um equipamento havia confirmado a agenda e mudado o estado da regra; o outro tinha aceitado a configuração, mas atrasado a ativação durante uma recuperação interna. O painel contava ambos como deployed.

Esse episódio mostra uma propriedade desconfortável de políticas programadas: o tempo não é metadado. Ele participa da decisão de permitir ou negar. Se a organização verifica apenas o documento armazenado, pode provar que pretendia fechar a janela e não conseguir provar quando cada pacote deixou de atravessá-la.

O Internet-Draft A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control, revisão 15, torna essa questão concreta. Seu módulo ietf-ucl-acl adiciona grupos de usuários, dispositivos e aplicações ao modelo do RFC 8519, permite correspondência por Group ID e acrescenta effective-schedule às ACEs. Também propõe o atributo RADIUS User-Access-Group-ID.

O documento está avançado no processo: pertence ao OPSAWG, pretende Proposed Standard, foi submetido ao IESG e aparece na fila do RFC Editor, em revisão final. A análise da IANA está concluída com ações necessárias. A revisão 15 é de 2 de abril de 2026 e expira em 4 de outubro. Ainda é um Internet-Draft sem número de RFC. O estado documental não deve ser convertido em alegação de implementação ou operação.

A agenda muda o predicado sem mudar o grupo

O módulo permite dois formatos principais de agenda. Uma ACE pode valer durante um período ou segundo uma recorrência de estilo iCalendar, baseada no RFC 9922. Se effective-schedule não for configurado, a ACE é aplicada imediatamente e o tempo todo.

Essa capacidade evita criar cópias manuais de políticas para turnos, manutenções ou autorizações temporárias. Também acrescenta campos que precisam permanecer semanticamente alinhados: início, fim ou duração, regra de recorrência, identificador de fuso, datas de exceção e origem do relógio.

O Group ID pode permanecer constante enquanto o predicado da ACE muda de falso para verdadeiro e depois volta a falso. Um inventário que indexa apenas grupo e revisão da ACL não consegue reconstruir qual estado governava um pacote na borda de uma janela.

É preciso distinguir configuração armazenada de regra ativa. Uma resposta de commit pode provar que o documento foi aceito. Uma leitura posterior pode provar que o documento está no datastore. Nenhuma das duas, isoladamente, prova que o mecanismo de tempo avaliou a ocorrência esperada naquele instante.

Relógios aparentemente sincronizados também não eliminam o problema. Um equipamento pode usar um banco de fusos diferente, interpretar uma exceção antiga, perder sincronização durante uma falha ou ativar a nova agenda depois de concluir outra transação. A incerteza de relógio deve aparecer no recibo, não ser arredondada para certeza.

A confidencialidade da agenda também é controle

As considerações de segurança do rascunho tratam effective-schedule como dado sensível. Uma escrita não autorizada pode alterar quando regras são aplicadas e provocar interrupção ou indisponibilidade. Uma leitura não autorizada pode revelar quando controles estão ativos e ajudar um atacante a escolher a janela de ação.

Essa dupla propriedade impede duas simplificações. A primeira é publicar agendas completas em observabilidade ampla para facilitar auditoria. A segunda é esconder toda evidência temporal e pedir confiança. Um desenho melhor separa prova e conteúdo: o sistema pode registrar internamente a regra exata, seu hash, fuso, ativação e autoridade; relatórios menos privilegiados podem mostrar que a verificação ocorreu sem expor a janela.

O acesso ao YANG por NETCONF ou RESTCONF deve usar transporte seguro e autenticação mútua. NACM pode restringir usuários e operações. Essas proteções são necessárias para impedir alterações e leituras indevidas. Elas não demonstram que dois PEPs ativaram a mesma revisão simultaneamente.

Autenticação responde quem acessou o plano de controle. O recibo de execução responde qual estado temporal governou o pacote.

O grupo é estável; sua projeção não é

O problema temporal se soma ao problema de mapeamento. O rascunho busca reduzir a dependência de endereços instáveis: mobilidade, endereços temporários IPv6, NAPT e migração de aplicações tornam políticas baseadas apenas em IP e portas difíceis de manter.

Um controlador pode mapear Group ID para campos de pacote, como um cinco-tupla, e distribuir ACLs convencionais. Outra opção é o PEP entender grupos e classificar pacotes localmente. A primeira exige atualizações frequentes quando o contexto muda; a segunda pode exigir suporte de hardware ou software e afetar desempenho.

Em qualquer opção, a agenda pode ser correta para o grupo errado ou o mapeamento pode ser correto sob a agenda errada. Por isso, revisão de mapeamento e revisão temporal precisam ser ligadas, não registradas em painéis separados sem chave comum.

O próprio texto diz que a string Group ID não precisa corresponder exatamente à etiqueta usada no pacote e deixa fora de escopo a forma de mapear a string para campos de encapsulamento. RFC 9638 fornece apenas um exemplo de GBP. A observação de uma etiqueta precisa da tabela que lhe dava sentido naquele PEP e naquele momento.

A seção sobre consistência recomenda preparação adequada e cuidado quando mecanismos diferentes, como RADIUS, convivem. A agenda acrescenta mais um mecanismo: o mesmo mapeamento deve encontrar a mesma política ativa no instante relevante.

RADIUS não transforma tempo local em verdade global

User-Access-Group-ID pode aparecer em Access-Accept para indicar grupos usados após autenticação. Em Access-Request, pode aparecer apenas como dica de preferência; o servidor não é obrigado a atendê-la. Várias instâncias em Access-Accept significam múltiplos grupos.

Se cada grupo possui ACEs com calendários diferentes, o conjunto efetivo pode mudar ao longo da sessão sem qualquer nova autenticação. A pertença continua, mas uma autorização temporal expira. Um sistema que consulta apenas o último Access-Accept pode mostrar acesso atual mesmo quando todas as regras aplicáveis terminaram.

O atributo também pode aparecer em CoA-Request. Isso permite alterar a pertença durante a sessão, adicionando outra linha do tempo: decisão AAA, recepção no NAS, recálculo do controlador, distribuição, ativação temporal e observação. Um CoA recebido perto da borda de uma janela exige ordem explícita entre versões.

Em Accounting-Request, o NAS pode reconhecer que recebeu o atributo e está aplicando a política. O registro é importante, mas sua granularidade pode não incluir cada PEP ou cada transição de agenda. A afirmação do NAS deve ser mantida com origem e intervalo, não elevada a testemunho de toda a rede.

Múltiplos PEPs tornam o agora um vetor

O rascunho admite múltiplos PEPs. Em uma rede real, um fluxo pode cruzar NAS, firewall, tecido e gateway de aplicação. Cada um possui capacidade, configuração, fila de transações e relógio próprios.

O estado global não é um único now. É um vetor: PEP A ativo na revisão 44 às 18:00:00; PEP B com revisão 44 armazenada, mas revisão 43 ativa até 18:03:12; PEP C sem suporte ao recurso de agenda e recebendo uma ACL expandida; PEP D não alcançável.

Uma plataforma pode decidir que a mudança só está concluída quando todos os PEPs obrigatórios confirmam ativação. Pode também adotar quorum para políticas de menor risco. O ponto não é impor uma escolha universal, mas declarar a escolha e impedir que o primeiro sucesso represente o conjunto.

O conjunto alvo merece versão própria. Se um novo gateway não aparece no inventário do controlador, nenhum monitor de implantação vai acusar ausência. A descoberta de PEPs é parte da autoridade de execução.

Os estados devem ser distintos: enviado, validado, instalado, programado, ativo e lido de volta. Para regras temporais, programado não é ativo; para regras recorrentes, uma ativação correta hoje não prova a próxima ocorrência.

O pacote precisa depor em seu próprio tempo

Contadores de ACL podem mostrar que uma regra coincidiu com pacotes. Devem ser relacionados à revisão e ao intervalo de coleta. Um contador cumulativo sem reset conhecido pode ter crescido antes da nova agenda. Uma amostra sem caminho conhecido pode ter atravessado outro PEP.

Canários positivos verificam que o tráfego permitido ainda funciona durante a janela. Canários negativos tentam o acesso depois do fechamento. Sondas de serviço verificam resposta, não apenas passagem em um filtro. Nenhum teste isolado cobre todos os caminhos, mas um conjunto declarado de observações limita o que pode ser afirmado.

O relatório correto pode dizer: três PEPs previstos; dois ativaram na borda com relógio saudável; um ativou 192 segundos depois; o canário negativo falhou naquele caminho durante o atraso; após a correção, todas as rotas testadas recusaram. Isso é mais sério do que policy applied, porque preserva a consequência.

Também é preciso proteger a privacidade e a segurança dos testes. Publicar um canário detalhado ou a janela exata pode criar uma receita para evasão. Evidência operacional pode ser retida com controle de acesso e resumida de forma segura para governança.

Validação formal não mede atraso de ativação

O Datatracker registra zero erros e zero avisos na validação YANG da revisão 15. Isso comprova uma verificação formal da estrutura publicada. Não mede deriva de relógio, atraso de commit, interpretação de recorrência ou consistência entre fornecedores.

A comparação entre as revisões 14 e 15 mostra ajustes de data, linguagem, expansão de NVO3 e atualização da referência de diretrizes YANG para o RFC 9907. Não há novo estudo de implantação ou benchmark. A proximidade do RFC Editor merece precisão editorial, não entusiasmo causal.

O texto também alerta que alguns dispositivos podem não possuir capacidade nativa para políticas por grupo. Atualizações de software ou hardware podem ser necessárias. Um controlador deve registrar capacidade por PEP antes de escolher entre regra de grupo e ACL convencional expandida.

Quando uma plataforma cai para um modo compatível, esse fato deve constar do recibo. A mesma política pode ter um Group ID nativo em um ponto e uma lista de IPs no outro. As superfícies de falha e os tempos de atualização são diferentes.

O recibo temporal mínimo

Primeiro, conservar sujeito autenticado, sessão, autoridade e todos os grupos aceitos. Separar dica em Access-Request de decisão em Access-Accept. Registrar CoA como transição, não edição instantânea.

Segundo, ligar cada grupo à revisão do mapeamento: origem, campos ou etiqueta, validade e gatilho de mudança. Terceiro, ligar a revisão de ACL à agenda: período ou recorrência, fuso, exceções, precedência e regra para conflitos entre grupos.

Quarto, registrar o conjunto de PEPs e a capacidade de cada um. Quinto, guardar por PEP validação, instalação, programação, ativação, saúde do relógio e leitura. Sexto, observar pacotes e serviço com tempo e caminho declarados.

Heng Lu chama atenção para uma especificação inicial mínima que preserve o handoff sem congelar decisões locais. Esse recibo não exige o mesmo fornecedor nem a mesma arquitetura. Exige apenas que enforced não esconda relógio, mapeamento e parcialidade.

Na separação de camadas de realidade, Group ID e agenda são símbolos e objetos de controle; a regra ativa no PEP é estado executável; o pacote e a resposta do serviço são realidade observada. Uma camada não herda a verdade da anterior.

Running-Code Primacy sugere testar a meia-noite, mudanças de fuso, exceções, relógio degradado, reinício do controlador, migração do usuário e indisponibilidade de um PEP. Um sistema seguro pode falhar um teste; o que não pode é apagar a diferença e continuar declarando execução total.

No incidente inicial, as duas configurações eram iguais porque a pergunta estava incompleta. O que importava era quando cada uma governou o tráfego. Política com horário só existe de fato quando o tempo, o equipamento e o pacote contam a mesma história.

Sources