Resumen

  • RFC 5193 admite que un canal seguro anterior a PANA puede descansar en protección física, no sólo en criptografía. Esa protección debe ser cierta para el enlace concreto: que el cliente no comparta el medio con actores capaces de suplantar o escuchar.
  • Una declaración de aislamiento pierde alcance cuando cambian el segmento, el equipo de acceso, la ruta al EP o la forma de compartir el enlace. Si la clasificación no cambia, puede justificar una selección EAP y la omisión de una asociación segura que ya no corresponden a la realidad.

La criptografía deja rastros familiares: pares, claves, algoritmos, negociaciones. El aislamiento físico parece más sencillo y por eso suele auditarse peor. Una casilla de inventario dice “punto a punto”, el diagrama coloca un solo cliente detrás del puerto y la conclusión se conserva durante años.

RFC 5193 no permite esa comodidad ilimitada. Al describir redes con canal seguro antes de PANA, menciona un ejemplo DSL en el que la protección física del cableado hace que, en la práctica, sólo un cliente pueda enviar y recibir en el enlace. La propiedad importante no es la etiqueta DSL. Es la restricción efectiva frente a suplantación y escucha.

Cuando una modificación introduce un dominio compartido, cambia la premisa que gobierna el resto de la arquitectura.

El aislamiento tiene una frontera

Una prueba física debe nombrar aquello que aísla: puerto, bucle, segmento, equipo de concentración, ruta y punto de aplicación. También debe explicar qué adversarios quedan fuera de esa frontera. “Acceso fijo” no basta. Dos clientes pueden terminar compartiendo un tramo aunque sus acometidas iniciales sean distintas.

El recibo operativo puede venir de una combinación de inventario verificado, descubrimiento de topología, configuración de puertos y observación del camino. RFC 5193 no prescribe estas fuentes. Lo que sí hace es vincular una propiedad del entorno con decisiones posteriores. Por eso la fuente debe ser auditable y su alcance explícito.

Si el diagrama muestra aislamiento pero la telemetría ve un dispositivo compartido, no conviene fusionar ambas señales en un promedio. Existe una contradicción. La afirmación secure-before queda sin demostrar hasta que la superficie responsable la resuelva.

La expansión transforma una propiedad sin tocar al cliente

El cliente puede no moverse. Su interfaz, dirección y sesión pueden conservarse. Sin embargo, una intervención fuera de él altera el dominio de confianza: un nuevo concentrador, una VLAN extendida, un puente temporal, una función de acceso virtualizada o un camino de respaldo.

Éste es el problema de tratar la seguridad como atributo del dispositivo. La realidad relevante pertenece a la relación entre PaC y EP. Cualquier cambio intermedio puede modificarla sin actualizar la ficha del abonado.

La clasificación debe versionarse con la topología que la sustenta. Una decisión basada en el plano A no puede aplicarse retroactivamente al plano B. Las sesiones iniciadas bajo A conservan su historia; las nuevas decisiones bajo B requieren nueva evidencia. Si una transición ocurre durante una sesión, la política local debe declarar qué hace. El RFC no impone cancelación, reautenticación o cierre, y el artículo no inventa una regla. Exige que la decisión sea visible.

La consecuencia llega hasta la elección EAP

RFC 5193 distingue el caso en que el canal seguro ya existe del caso en que PANA corre inicialmente sobre un medio vulnerable a escucha y suplantación. En este segundo entorno, la método EAP debe resistir esos ataques y generar material criptográfico para el protocolo de asociación segura posterior.

Por tanto, una topología obsoleta no sólo produce una nota imprecisa. Puede hacer que el selector aplique un perfil de método construido para un canal que ya no existe. También puede marcar como innecesario el trabajo que habría creado protección por paquete después de PANA.

El registro debe unir la versión topológica, la clasificación, el perfil EAP elegido, la expectativa de claves y la decisión sobre asociación posterior. Así, un auditor puede seguir la causalidad desde el cambio de segmento hasta la omisión de un control.

Una autenticación PANA exitosa no corrige la premisa. El éxito responde a su propia superficie. No demuestra que el canal inicial estuviera aislado, ni que un tercero no pudiera observarlo, ni que el método elegido fuera adecuado para otro entorno.

Colocación no equivale a aislamiento

RFC 5193 permite que PAA y EP residan en el mismo nodo, o que PAA y servidor de autenticación estén juntos. Esto puede sustituir un protocolo interno por una API. No elimina la topología situada entre el cliente y ese nodo.

Una caja integrada puede recibir tráfico de muchos clientes en un segmento compartido. La distancia lógica entre PAA y EP es cero mientras la exposición del enlace de acceso sigue intacta. Informar “PAA/EP colocados” como prueba de canal seguro mezcla una propiedad interna con otra externa.

El mismo cuidado vale para el backend AAA. RADIUS o Diameter pueden devolver autenticación y atributos de autorización. Esos resultados no observan automáticamente el cable, la radio o el puente por el que el cliente alcanzó el EP. El servidor de autenticación no obtiene autoridad sobre una topología que no midió.

Capacidad, configuración y estado

El equipo intermedio puede soportar separación por puerto o filtros que impidan tráfico entre clientes. Ese soporte es capacidad. La plantilla puede pedirlo: configuración. El dispositivo puede haber aceptado la orden: aplicación. Los paquetes pueden demostrar que el aislamiento funciona: observación.

Cada paso merece identidad, versión y tiempo. Si sólo se conserva el último valor “habilitado”, una sustitución de hardware o un rollback puede dejar una afirmación huérfana. Si sólo se conserva una captura de paquetes, puede faltar la explicación de qué política debía existir.

La disciplina no busca acumular datos por sí mismos. Busca limitar el significado de cada dato. Un inventario puede probar qué se esperaba. Una lectura puede probar qué estaba configurado. Una prueba de camino puede aportar evidencia del comportamiento. Ninguna debe hablar sola en nombre de todas.

Recibo mínimo para la protección física

Conservar el identificador del cliente y la interfaz, el segmento y el equipo de acceso, la versión de topología, el EP previsto, la base del aislamiento, los actores excluidos, los controles complementarios, la fecha de verificación y el propietario de la declaración. Vincular después la clasificación de entorno y sus consecuencias EAP.

Activar disparadores cuando se añade un nodo compartido, cambia la VLAN, aparece un puente, se conmuta a respaldo, se reemplaza un equipo o caduca la verificación. El resultado no tiene por qué ser automáticamente “inseguro”; puede ser “no probado”. Esa honestidad evita que un registro antiguo ejerza una autoridad que la red ya no le concede.

Lu Heng formula el límite de modo más general: el registro describe la realidad; no la crea. Un plano de aislamiento puede coordinar trabajo y preservar historia. No puede aislar físicamente un paquete.

Fuentes

  1. RFC 5193 HTML
  2. RFC 5193 texto
  3. Registro RFC 5193
  4. Datatracker RFC 5193
  5. Historial RFC 5193
  6. Referencias RFC 5193
  7. Erratas RFC 5193
  8. RFC 5191
  9. Registro RFC 5191
  10. RFC 4058
  11. Registro RFC 4058
  12. RFC 4016
  13. RFC 3748
  14. RFC 4306
  15. RFC 2409
  16. RFC 2865
  17. RFC 3588
  18. Heng Lu — capas de realidad
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — primacía del código en ejecución