Resumo

  • A RFC 1472 organizou protocolos de autenticação e pares ID/Secret por link, preferência, direção, protocolo e status.
  • valid tornava a linha elegível; uma autenticação real ainda dependia de mensagens PAP ou CHAP, da decisão do autenticador e de uma fase de rede separada.

A RFC 1472, publicada em junho de 1993, transformou segredos de PPP em objetos gerenciáveis. Ao mesmo tempo, preservou uma distinção que interfaces modernas frequentemente escondem: o estado da configuração não era o estado da conversa.

O documento fazia parte da mesma família da RFC 1471, dedicada ao LCP. Seu grupo de segurança era opcional porque continha identidades, segredos e controles capazes de mudar qual protocolo de autenticação seria tentado.

A preferência vinha antes do evento

pppSecurityConfigTable associava um protocolo a um link e a uma preferência. Valores menores eram tentados primeiro. O link zero funcionava como padrão para links sem entrada explícita.

Preferência não era classificação de segurança nem previsão de êxito. O campo de protocolo dizia o que tentar, não o que fora negociado. O padrão preenchia uma lacuna administrativa, mas uma entrada específica podia ocultá-lo.

O status podia ser valid ou invalid. Tornar uma linha inválida não obrigava o agente a apagá-la. A remoção dependia da implementação, e a estação de gerência precisava saber interpretar linhas presentes que já não estavam em uso.

Logo, encontrar uma linha respondia “ela existe”. Somente o status respondia se pertencia à configuração corrente.

Um índice não identificava quem estava no fio

A tabela de segredos aceitava vários pares ID/Secret para o mesmo link. Um índice os separava, mas a escolha do par era decisão da implementação local.

A direção era parte do significado. local-to-remote indicava o par usado pela entidade local para se autenticar diante da remota. remote-to-local indicava o par esperado do outro lado. Trocar a direção preservava os octetos, mas mudava o ator.

O protocolo também interpretava os campos. Em PAP, a identidade podia conter um Peer-ID e o segredo uma senha. Em CHAP-MD5, a identidade podia ser o CHAP Name e o segredo participar do cálculo da resposta. Por isso a MIB os tratava como cadeias de octetos dependentes de contexto.

Uma identidade configurada não provava uma pessoa. Um segredo armazenado não provava posse no instante do acesso. Uma linha válida não revelava qual par fora escolhido, se o remoto enviara uma resposta ou se o autenticador a aceitara.

A autenticação produzia outro recibo

A RFC 1334 descrevia PAP como o envio de Peer-ID e senha após o estabelecimento do link, seguido de Authenticate-Ack ou Nak. A posterior RFC 1994 descreveu CHAP como desafio, resposta calculada, comparação pelo autenticador e sucesso ou falha.

Essas mensagens registravam um acontecimento. Para ligá-lo à MIB, era preciso conservar link, protocolo negociado, identificador do pedido ou desafio, resposta, versão da credencial e decisão.

A RFC 1661 preservou a ordem das fases: estabelecer o enlace, possivelmente autenticar o par e depois abrir os protocolos de rede por NCP. Autenticação não comprovava IPCP aberto; IPCP aberto não comprovava rota, entrega ou resultado de aplicação.

A administração também precisava de proteção

A RFC 1472 desaconselhava fortemente implementar o grupo sem privacidade do SNMPv2. Views da MIB podiam isolar a subárvore. Tornar objetos somente leitura reduzia o poder de alteração, mas mantinha o risco de leitura do segredo.

Uma operação de gerência protegida continuava sendo uma operação de gerência. Ela não substituía a troca PPP. Centralizar as credenciais facilitava a operação e concentrava o risco de um padrão amplo, uma preferência alterada, uma view exposta ou uma linha antiga mal interpretada.

Dois históricos, uma correlação

O histórico administrativo deve guardar ator, horário, escopo do link, padrão herdado, preferência, protocolo, índice, direção, status e leitura do agente. O histórico operacional deve guardar fase LCP, protocolo negociado, pedido ou desafio, resposta, decisão, versão do segredo, NCP e tráfego.

Uma linha válida nunca escolhida é inventário. Uma linha inválida ainda escolhida é desvio. Um sucesso sem versão de credencial tem atribuição incompleta. Um link autenticado que para no IPCP apresenta falha posterior.

A lição da RFC 1472 é que uma tabela ganha credibilidade quando não reivindica o evento que apenas preparou.

Fontes