Resumen

  • RFC 1472 organizó preferencias de protocolos e identidades/secretos de PPP por enlace, dirección, protocolo y estado.
  • Una fila valid era configuración elegible; autenticar exigía todavía un intercambio PAP o CHAP, el veredicto del autenticador y una fase de red posterior.

La RFC 1472, publicada en junio de 1993, hizo algo delicado: volvió administrables los secretos de autenticación de PPP sin fingir que la administración era el propio evento de autenticación.

Formaba pareja con la RFC 1471, dedicada a los objetos de LCP. La sección de seguridad era opcional. Permitía leer o modificar decisiones capaces de cambiar la protección de un enlace, por lo que su mera existencia ampliaba la superficie de control.

La tabla ordenaba intentos

pppSecurityConfigTable asociaba protocolos con un enlace y un orden de preferencia. Los números menores se probaban primero. El enlace cero funcionaba como regla predeterminada para enlaces sin una entrada explícita.

Nada de eso era un resultado. La preferencia no medía fortaleza ni probabilidad. El nombre del protocolo decía qué intentar, no qué se había negociado. La regla cero no demostraba que rigiera un enlace particular: una fila más específica podía sustituirla.

El campo de estado podía ser valid o invalid. Invalidar una fila no obligaba a borrarla; la eliminación quedaba en manos de la implementación. Por eso la estación gestora debía aceptar que una tabla devolviera entradas visibles que ya no estaban en uso y consultar el estado antes de interpretarlas.

La presencia era un dato. La vigencia era otro.

Los octetos necesitaban contexto

La tabla de secretos admitía varios pares ID/Secret por enlace. El índice los distinguía, pero la selección efectiva era una decisión local de la implementación.

La dirección separaba dos papeles. local-to-remote era el par que la entidad local podía presentar para autenticarse ante el extremo remoto. remote-to-local era lo que la entidad local esperaba del par. Confundirlos podía conservar los mismos octetos y cambiar por completo el acto que se esperaba.

El protocolo también daba significado. En PAP, la identidad podía ser un Peer-ID y el secreto una contraseña. En CHAP-MD5, la identidad podía ser el nombre CHAP y el secreto el material para calcular la respuesta. La RFC los dejó como cadenas de octetos precisamente porque su semántica no vivía en el tipo de la columna.

Una identidad configurada no era una persona verificada. Un secreto guardado no demostraba quién lo poseía. Una fila válida no decía qué par fue elegido, si el remoto respondió o si el autenticador aceptó.

El suceso estaba fuera de la MIB

La RFC 1334 describía PAP: tras establecer el enlace, el par enviaba Peer-ID y contraseña y recibía Authenticate-Ack o Authenticate-Nak. La posterior RFC 1994 describía CHAP: reto, respuesta calculada, comparación local y reconocimiento o fallo.

Esos mensajes eran los recibos que faltaban en la tabla. Para reconstruirlos hacían falta enlace, protocolo negociado, identificador de solicitud o reto, respuesta, versión de credencial y resultado.

La RFC 1661 mantuvo además separadas las fases. Primero se establecía el enlace. Después podía autenticarse el par. Luego los NCP configuraban los protocolos de red. Solo entonces podían circular sus datagramas.

Así, una credencial configurada no probaba autenticación; una autenticación no probaba IPCP abierto; IPCP abierto no probaba entrega ni aceptación por una aplicación.

La ruta de gestión también debía protegerse

RFC 1472 desaconsejaba firmemente implementar el grupo sin privacidad de SNMPv2. Las vistas MIB podían aislar el subárbol. Hacer los objetos de solo lectura reducía el poder de escritura, pero seguía exponiendo identidades y secretos.

Proteger esa ruta demostraba, a lo sumo, que una operación administrativa viajó bajo un control determinado. No demostraba que un par PPP se autenticara después. La administración y el enlace tenían actores, tiempos y evidencias distintos.

La comodidad de una tabla central también concentraba riesgo. Un cambio de preferencia, una regla predeterminada demasiado amplia o una vista mal protegida podía alterar muchas conexiones sin que una sola palabra valid explicara cuál acabó usando la configuración.

Un historial con dos relojes

La auditoría necesita dos cronologías. La administrativa conserva autor, solicitud, hora, alcance del enlace, herencia del valor por defecto, preferencia, protocolo, índice, dirección, estado y lectura del agente. La operativa conserva fase LCP, mecanismo negociado, solicitud o reto, respuesta, decisión, fase NCP y tráfico.

Una fila válida nunca seleccionada es inventario. Una fila inválida que el proceso todavía usa es una desviación. Un éxito sin versión de credencial es un vacío de atribución. Un enlace autenticado que no abre el protocolo de red es un fallo posterior.

La lección de RFC 1472 no es que las tablas fueran inútiles. Es que eran útiles porque declaraban su límite: podían mostrar la preparación del sistema, no tomar prestada la prueba de un acontecimiento que aún no había sucedido.

Fuentes