Resumen

  • RFC 2989 evaluaba propuestas por sus capacidades; una función obligatoria no tenía que aparecer en cada intercambio.
  • Las columnas NASREQ, ROAMOPS y Mobile IP preservaban necesidades distintas, no una única política universal de despliegue.
  • Acuse de transporte, aceptación sintáctica, decisión semántica, responsabilidad contable, efecto de autorización y servicio eran recibos diferentes.

El alcance real de la matriz

RFC 2989 no especificó un protocolo de autenticación, autorización y contabilidad. Resumió requisitos para comparar candidatos. Separó criterios generales, autenticación, autorización, contabilidad y necesidades particulares de Mobile IP.

Las tablas retenían columnas para las comunidades de origen. M, S, O, N y B representaban MUST, SHOULD, MAY, MUST NOT y SHOULD NOT. La forma común facilitaba la comparación; la conservación de columnas impedía fingir que todos los entornos habían pedido exactamente lo mismo.

La sección sobre lenguaje normativo puso el límite. Los requisitos se usaban para evaluar capacidades del protocolo. Una propuesta que incumplía un MUST de una capacidad implementada no era conforme. Si cumplía las obligaciones pero no todas las recomendaciones, era condicionalmente conforme. Si satisfacía también los SHOULD, era incondicionalmente conforme.

Ninguna de esas categorías afirmaba que una instalación hubiera activado la capacidad.

El propio texto eligió la confidencialidad como prueba. Exigir que el protocolo pudiera proteger datos no significaba exigir cifrado para todo tráfico. Para pasar del documento al paquete hacían falta otros datos: versión de código, perfil, configuración, claves, pares, negociación, objeto protegido y resultado de verificación.

Un MUST no era telemetría

RFC 2119 da fuerza a una obligación dentro de su contexto. No convierte automáticamente una obligación de diseño en un hecho de producción.

La diferencia se veía en las columnas. Escalabilidad era obligatoria en los tres ámbitos. La conmutación a un servidor secundario aparecía como requisito fuerte en NASREQ y Mobile IP. IPv4 era común; IPv6, certificados y auditabilidad variaban. Una celda vacía no prohibía una función. Una M no ordenaba que cada mensaje la ejerciera.

El error institucional llega después: el fabricante presenta conformidad protocolaria; el comprador la interpreta como protección de todo tráfico; el operador cuenta una conexión; el informe la publica como acceso exitoso. Cada salto añade una conclusión sin observación propia.

La especificación mínima compartida debía coordinar la comparación, no apropiarse de futuras decisiones locales.

Dos perímetros de seguridad

La seguridad de transporte era salto a salto. Dos entidades AAA establecían autenticación, integridad y confidencialidad. Cuando el receptor procesaba el mensaje, esa envoltura se retiraba; el siguiente tramo necesitaba otra asociación.

La seguridad de objeto podía conservarse a través de proxies y corredores. La confidencialidad restringía ciertos atributos al destinatario final. La autenticación e integridad del objeto debían persistir y evitar que un intermediario modificara lo cubierto.

Que el protocolo soportara ambos modelos no demostraba su composición real. El operador aún debía probar qué capa se usó, qué campos cubrió, quién poseía las claves y qué hizo cada proxy.

La capacidad era una puerta disponible. La configuración decidía si se abría.

Entrega sin interpretación

El requisito de transporte fiable incluía retransmisión y failover por salto, control de reintentos por la aplicación AAA, respuestas oportunas y acuses. RFC 2989 nombró un acuse de transporte que indicaba entrega correcta del mensaje.

Luego declaró que ese acuse estaba separado de la evaluación sintáctica o semántica.

Un servidor podía recibir bytes y rechazar atributos. Un proxy podía aceptar su salto y no completar el siguiente. El respaldo podía responder sin tener estado reciente. La respuesta puntual podía ser una denegación.

Un único “éxito” ocultaría demasiadas fronteras. El registro útil conserva intento, salto, retransmisión, servidor elegido, acuse, análisis, decisión y acción del NAS.

La separación no rebajaba la fiabilidad: impedía atribuir al transporte una decisión que no había observado.

La contabilidad aceptaba custodia

La entrega garantizada de contabilidad introducía otro tipo de acuse. Era de aplicación y se enviaba cuando el servidor receptor estaba dispuesto a asumir responsabilidad por los datos.

Eso superaba la mera llegada, pero no demostraba persistencia durable, conciliación, tarificación, factura ni pago. La contabilidad recopilaba uso para tendencias, auditoría, facturación o reparto de costes. “Billing” era definido por separado como preparación de una factura.

Una reautorización podía producir varios registros para una sesión. Aceptar custodia cerraba un tramo; los estados posteriores necesitaban sus propios recibos.

Auditar no era absolver

RFC 2989 describió un proceso auditable como aquel que permitía determinar definitivamente las acciones realizadas sobre paquetes AAA desde el servidor doméstico al dispositivo y de vuelta.

La cadena podía contener actores diferentes. Un proxy local aplicaba política. Un proxy transparente no debía añadir, borrar ni modificar. Un proxy broker permanecía en el camino; un routing broker devolvía información para el contacto directo.

Un rastro podía demostrar la transformación. No probaba que estuviera autorizada, que la identidad fuera correcta, que la regla fuera justa o que el equipo ejecutara la respuesta.

La auditabilidad observaba custodia y cambios. Corrección y resultado pertenecían a otras verificaciones.

Autenticar, autorizar y contabilizar

La autenticación verificaba una identidad declarada como origen de mensaje o extremo de canal. La autorización decidía si conceder un derecho. La contabilidad recogía uso.

El protocolo debía permitir autorización sin exigir credenciales del usuario en ese mismo intercambio; bastaban identificación o afirmación. Eso no hacía auténtica la afirmación por sí sola. Reconocía que la prueba podía vivir en otra relación.

Rechazo, reglas, reautorización, conciliación y desconexión eran superficies de control, no resultados ya ejecutados.

El legado de la lista

RFC 2989 fue rigurosa porque no confundió el objeto evaluado. Capacidad no era activación. Entrega no era significado. Custodia no era factura. Auditoría no era corrección. Autorización no era servicio.

Las capas de realidad de Lu Heng ordenan la secuencia: fuente del requisito, texto, capacidad, implementación, configuración, mensaje, intermediario, decisión, efecto y resultado. La verdad de una capa no le da autoridad para hablar por todas.

El código en ejecución produce los recibos que faltan. La lista puntuaba al candidato. La red debía mostrar lo ocurrido.

Fuentes