Resumen

  • PRR reserva recursos para una futura regla, pero no instala bindings ni pinholes. PER intenta cambiar el procesamiento de paquetes; si esa sustitución falla, la reserva referenciada permanece.
  • El éxito de PER acredita una regla en ese middlebox, no el tránsito por toda la ruta ni la recepción de la aplicación. El inventario debe conservar ambas fronteras.

El operador vio “enable failed” y dio por revertida la solicitud. La siguiente llamada pidió el mismo puerto y recibió falta de recursos. El primer flujo nunca se habilitó; su reserva, sin embargo, todavía tenía tiempo concedido.

Este no es un detalle de limpieza. Es el efecto de un modelo con estados distintos. RFC 5189 asigna a PRR la acción reserve y a PER la acción enable. La primera protege una posibilidad futura. La segunda configura la decisión local que afectará a paquetes.

RESERVED no es un intento incompleto de ENABLED

PRR puede apartar una dirección, un puerto o un rango en uno o ambos lados, según la función del equipo. No crea una asociación de traducción ni una apertura del filtro. El procesamiento permanece igual.

En un firewall puro la misma transacción puede tener éxito sin reservar tuple alguno. Los valores vacíos describen correctamente la capacidad del dispositivo. El identificador y el grupo existen, la duración corre y el estado es RESERVED, pero no hay permiso de tráfico.

Tratar RESERVED como un ENABLED pendiente borra su propia utilidad. Una aplicación puede publicar el tuple reservado antes de conocer al par. Puede preparar señalización sin permitir todavía paquetes. Ese intervalo es una frontera de seguridad, no un defecto que el sistema deba rellenar.

El recibo necesita capacidad del middlebox, interfaces, protocolo, rango, paridad, A0 solicitado, A1/A2 devueltos y duración concedida. Debe conservar valores vacíos en vez de reemplazarlos por un supuesto.

El fallo de PER deja una obligación activa

PER puede consumir una PRR o crear directamente una regla ENABLED. Cuando la sustitución funciona, reutiliza el identificador y termina la reserva sin una notificación separada. El mismo ID pasa a representar otra acción.

Cuando la sustitución falla, RFC 5189 protege la PRR. El agente puede corregir parámetros y volver a intentar dentro de la duración disponible. También puede pedir una vida cero para eliminarla. Lo que no puede hacer es inferir su desaparición de la respuesta negativa de PER.

Las causas importan: falta de recursos, conflicto, interfaz inválida, falta de autorización o discordancia entre A0 reservado y solicitado no exigen la misma reparación. Un mensaje genérico “fallo de firewall” destruye la decisión operativa.

El conflicto sigue una regla determinista: una nueva política contradictoria se rechaza y la anterior permanece. Un solapamiento no conflictivo, incluso idéntico, puede aceptarse. El orden de admisión demuestra qué reglas existen, pero no qué paquete fue observado después.

ENABLED tiene autoridad local

En NAT, PER establece bindings. En firewall, configura una o varias acciones allow. En un equipo combinado hace ambas cosas, quizá con pares distintos por dirección. Su respuesta exitosa es un recibo fuerte de configuración local.

Esa fuerza tiene un límite exacto. El middlebox no puede certificar una ruta posterior, otra ACL, el listener remoto, la negociación de transporte ni la autorización de aplicación. Para afirmar comunicación hacen falta captura a ambos lados, recepción remota y resultado de aplicación.

Separar esos niveles mejora la automatización. Un verificador puede decidir si reintenta configuración, investiga red o escala al servicio. Un único estado “connectivity ready” obliga a adivinar.

La duración efectiva pertenece al middlebox

El agente propone lifetime; el middlebox devuelve el valor concedido, limitado por la propuesta y por el máximo anunciado al abrir la sesión. El contador operativo debe empezar con lt_granted, no con el deseo del agente.

RLC puede ampliar, acortar o terminar una regla. Solicitar cero la elimina. Un evento asíncrono puede cambiarla por decisión del equipo o de otro agente autorizado. Las notificaciones deben ordenarse junto a lecturas de estado, no sobrescribirse con la última instantánea.

Cerrar la sesión MIDCOM tampoco elimina automáticamente las reglas. Tras terminación normal, asíncrona o interrupción de conexión, siguen hasta expirar o recibir otro evento terminal. La reserva huérfana de nuestro ejemplo puede sobrevivir precisamente porque su reloj no era el de la sesión.

Propiedad y grupos no reemplazan la historia

El agente autenticado que crea la regla es su propietario durante toda la vida. La política local puede autorizar a otro agente a modificar reglas de ese owner, pero el acto debe quedar atribuido. Conocer quién está conectado ahora no identifica quién creó el estado.

Cada regla pertenece a un grupo y todos los miembros comparten propietario. El grupo nace con el primer miembro y desaparece con el último. Su vida deriva de los miembros; GLC puede imponer una vida común o terminar todos con cero.

Un grupo puede contener reservas y habilitaciones. La operación colectiva es uniforme, pero el impacto no: eliminar RESERVED libera capacidad; eliminar ENABLED también cambia tratamiento de paquetes. El informe debe enumerar miembros y estados antes de resumir el grupo.

Atomicidad observable

Las solicitudes MIDCOM son atómicas entre sí y no exponen un estado intermedio estable al agente. Las transacciones asíncronas sí pueden interrumpirlas. Una implementación concreta que divide la operación semántica puede alterar esa garantía.

Por eso el objeto de evidencia registra tanto la transacción normativa como los pasos reales: change ID, session, request, agent autenticado, owner, equipo, capacidades, regla, grupo, estado anterior y resultado.

Después añade parámetros PRR o PER, lifetimes solicitado, máximo y concedido, conflicto, razón de fallo y supervivencia de reserva. Finalmente incorpora eventos, final de sesión, captura, recibo remoto, respuesta de aplicación, expiración y rollback.

Sin la última capa, la frase correcta es “la regla local fue habilitada” o “la reserva sigue vigente”. Ninguna de ellas autoriza a escribir que el servicio funcionó.

Fuentes

  1. RFC 5189 HTML
  2. RFC 5189 texto
  3. Ficha RFC 5189
  4. Datatracker RFC 5189
  5. Historia RFC 5189
  6. Referencias RFC 5189
  7. Errata RFC 5189
  8. RFC 3989
  9. Ficha RFC 3989
  10. RFC 3303
  11. Ficha RFC 3303
  12. RFC 3304
  13. Ficha RFC 3304
  14. RFC 3198
  15. RFC 3234
  16. RFC 3022
  17. RFC 6887
  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