Resumen

  • RFC 3182 definió AUTH_DATA para llevar localizador de política, credencial, firma y errores dentro de POLICY_DATA. Cada campo aportaba una prueba distinta; ninguno concedía capacidad por sí solo.
  • La custodia cambiaba durante el recorrido. En unicast podía mantenerse el localizador del usuario y reemplazarse la credencial por la del nodo actual; en multicast, el PDP podía seleccionar qué identidad de aplicación quedaba representada.
  • Un principal autenticado todavía necesitaba una política, una decisión, ejecución local, capacidad y verificación del resultado. El análisis posterior de seguridad de RSVP confirmó que autenticación y autorización podían divergir.

La primera identidad no era la identidad del grupo

RSVP separaba dos decisiones: si había recursos y si el solicitante podía usarlos. RFC 2205 llamaba admission control a la primera y policy control a la segunda. RFC 3182, publicada como Proposed Standard en octubre de 2001, dio formato a la información que alimentaba la segunda.

El elemento podía ser AUTH_USER o AUTH_APP. Dentro aparecían un POLICY_LOCATOR, una credencial, una firma y, en mensajes de error, una causa de fallo. El localizador señalaba la política asociada a un nombre distinguido. La credencial podía ser texto, ticket Kerberos, certificado X.509 o certificado PGP. La firma protegía los atributos anteriores.

La estructura no era una autorización comprimida. La arquitectura de RFC 2753 ubicaba la decisión en el PDP y la ejecución en el PEP. El PDP podía consultar directorios, autenticación, contabilidad, facturación, grupos u horario. El controlador de recursos aún podía rechazar por falta de capacidad. Un nombre permitía buscar una regla; no decía quién estaba facultado para aplicarla ni cuál era su versión vigente.

RFC 3182 sustituyó a RFC 2752 para corregir un código de elemento y el tamaño de un campo. La actualización administrativa de 2026 en Datatracker tampoco fue una revisión del protocolo. Se relaciona con un erratum técnico verificado.

El erratum 2958 corrige la descripción Kerberos: el servidor extrae del ticket la clave de sesión y la usa para autenticar; no envía el ticket al KDC para obtener esa clave. Mantener la frase original convertiría un error reconocido en un supuesto hecho operativo.

Tres maneras de decir «soy»

La autenticación simple llevaba un nombre ASCII o Unicode. Para aplicaciones, el RFC ejemplificaba un nombre de ejecutable como vic.exe. El propio texto advertía que esa forma no contenía una credencial autenticable de manera segura. Una etiqueta de archivo no demuestra el binario ejecutado, su editor, su integridad ni el dueño del proceso.

Kerberos añadía un ticket para el siguiente nodo RSVP o su PDP, dentro de un reino y una infraestructura compartidos. Podía autenticar un principal bajo esas condiciones. No transportaba automáticamente el derecho a reservar recursos en el dominio siguiente.

La opción de clave pública añadía certificado y firma. Requería clave privada protegida, autoridad certificadora confiable y validación. Incluso un resultado criptográfico correcto no resolvía revocación, política local, autoridad organizativa ni identidad del proceso que enviaba paquetes.

RFC 4230 observó después que la clave pública imponía costes de procesamiento y ancho de banda, que Kerberos no daba confidencialidad completa de identidad y que autenticar al usuario podía resultar insuficiente para autorizar la reserva. Fortalecer el comprobante de identidad mejoraba un eslabón, no toda la cadena.

El sobre podía cambiar de firmante

En unicast, el localizador de usuario se copiaba desde el salto anterior, pero la credencial representaba al nodo de red actual. La persona o aplicación buscada y el actor que respondía por el mensaje podían proceder de fases distintas.

En multicast, tanto localizador como credencial de usuario correspondían al nodo actual. La identidad de aplicación seguía otra regla: se copiaba en unicast; en multicast podía ser la primera del mensaje o la elegida por el PDP. La identidad final era una decisión de orden o política, no un inventario de participantes.

El mensaje podía contener varios AUTH_DATA, y los nodos conscientes de política podían modificar elementos. Por eso una auditoría necesita entrada, salida, actor, dominio, asociación de seguridad y motivo. Guardar solo el último nombre elimina el origen y permite que una reducción legítima parezca una declaración inmutable de extremo a extremo.

Pasar un router podía no significar nada sobre la política

RFC 2753 no exigía política en cada nodo. Los policy-ignorant nodes podían depender de fronteras de confianza. RFC 3182 permitía que un router ignorante omitiera los objetos de política y continuara procesando RSVP.

Ese paso favorecía el despliegue gradual, pero no producía un recibo de autorización. En una frontera capaz, el PEP enviaba la consulta al PDP; una respuesta negativa rechazaba, mientras una positiva dejaba continuar el procesamiento. Otro salto podía carecer de capacidad, aplicar otra regla o no instalar estado.

Por ello «objeto recibido», «credencial validada», «política aprobada», «estado instalado» y «aplicación servida» deben permanecer separados. El silencio de un nodo ignorante no es aprobación.

Los errores nombraban la frontera exacta

Las causas incluían tipo de credencial no soportado, privilegio insuficiente, credencial expirada e identidad cambiada. Si el PDP no podía verificar AUTH_DATA, debía devolver fallo de policy control y debía aportar detalle cuando fuera posible.

Esas causas distinguían identidad, privilegio y capacidad. Pero EXPIRED_CREDENTIAL no demostraba que todos los estados se hubieran retirado; IDENTITY_CHANGED no demostraba que la aplicación hubiera recibido aviso; un error en una rama multicast no demostraba el mismo resultado en las demás.

El registro IANA actual conserva la clase POLICY_DATA y errores de policy control. Coordinar números no prueba que un subtipo esté desplegado ni que un router concreto lo haya interpretado.

La integridad no otorgaba legitimidad

RFC 3182 recomendaba proteger POLICY_DATA cuando no estaba protegido todo el mensaje. La integridad podía detectar cambios o repetición dentro de una asociación determinada. RFC 4230 diferenció el alcance del mensaje y del contenedor, y recordó que nodos y PDP podían modificar datos por diseño, que la identidad podía filtrarse después del primer salto y que no había confidencialidad general entre routers.

La comprobación correcta tiene tres pasos: bytes intactos, actor autenticado y mandato aplicable. Un digest responde al primero; ticket o firma pueden responder al segundo; la criptografía no decide el tercero.

En fronteras de proveedor, RFC 2753 anticipaba reescritura según acuerdos bilaterales. RFC 4230 halló que no había formato estandarizado suficiente para autorización en roaming ni mecanismo acordado para autorizar reservas QoS. La identidad viajaba más fácilmente que la autoridad.

La historia defendible conserva los descartes

El registro comienza con identidad declarada y elemento bruto. Luego conserva subtipo, verificador, principal, realm o cadena, protección, localizador, versión de política, otros insumos y decisión del PDP. Después añade recibo del PEP, capacidad, instalación y cambios posteriores. Paquetes y aplicación producen pruebas aparte.

Para multicast hay que conservar todas las identidades de entrada, el orden, el selector y las que desaparecieron. Si solo queda la ganadora, nunca podrá saberse si fue primera, representativa o simplemente conveniente.

La separación entre símbolo, poder y ejecución en las notas de Lu Heng sirve como lente editorial, no como atribución histórica. RFC 3182 llevó el nombre hasta la decisión. El sistema en ejecución todavía tenía que demostrar quién podía decidir, dónde se ejecutó y qué ocurrió.

Fuentes y límites

El expediente reúne el texto RFC 3182, su ficha RFC Editor, Datatracker, API, erratum 2958 y RFC 2752. El contexto procede de RFC 2205, 2750, 2753, 2747, 4230, 4094 y la posterior 4923. Los formatos históricos remiten a RFC 1510 y 2459; el registro presente es IANA RSVP Parameters.

El análisis usa como lente los ensayos de Lu Heng sobre capas de realidad y primacía del código en ejecución. Las 18 fuentes se congelaron el 2 de octubre de 2026 en Asia/Shanghai. No identifican implementación, operador, usuario, flujo, incidente, despliegue, prueba de interoperabilidad ni resultado de servicio. Cada recibo conserva un alcance limitado.