Resumen

  • Las hojas config false de la revisión 01 constituyen un techo jerárquico para los cambios en reglas SCHC; no son una concesión de identidad al solicitante.
  • La autorización debe unir quién realiza la petición con qué mutación admite el objeto, y después demostrar versión, validación, sincronización del par y reversibilidad.

El controlador conoce al solicitante. El canal lo autenticó y NACM permite que su grupo actualice datos de configuración. La entrada SCHC también devuelve change-tv. Para un motor de flujo, el resultado parece obvio: actor autorizado más campo modificable equivale a cambio autorizado.

Falta una relación. La política de sesión permite una clase de operación. La hoja SCHC permite una clase de transformación. Todavía hay que probar que esa identidad puede actuar sobre ese Context y ese RuleID, y que la regla leída antes de la decisión sigue siendo la regla vigente. Después habrá que demostrar que el otro extremo adoptó el mismo significado.

El ejemplo no procede de una incidencia publicada. Es una reconstrucción de la frontera que abre draft-ietf-schc-access-control-01. El documento ofrece una herramienta valiosa, pero también recuerda una diferencia institucional: describir lo que puede cambiar no designa a quien tiene el mandato de cambiarlo.

La regla compartida ocupa el lugar de bits ausentes

SCHC aprovecha tráfico predecible en redes restringidas. El RFC 8724 define un Context compartido: el RuleID remite a información que ya conocen compresor y descompresor. En una regla de compresión, cada Field Descriptor combina identificador, longitud, posición, dirección, Target Value, Matching Operator y Compression/Decompression Action.

La eficiencia depende de que ambos lados mantengan ese acuerdo. Si una modificación cambia el significado local sin coordinar el remoto, el paquete comprimido no trae una copia completa del encabezado que resuelva la disputa. El RFC 9363 señala la consecuencia: alterar direcciones de aplicación puede cortar comunicación o facilitar escucha, por lo que debe validarse la identidad del solicitante y un dispositivo sólo debe modificar sus propias reglas.

El borrador de acceso intenta expresar límites que una autorización genérica no alcanza. Dentro de la misma regla, podría permitirse modificar el Target Value de Uri-Path y prohibirse tocar un prefijo de aplicación. Una política que sólo diga «este grupo puede escribir el módulo» pierde esa distinción.

La autorización del objeto tiene tres pisos

En el primer piso, ac-modify-set-of-rules distingue entre no cambiar, modificar elementos existentes y añadir o retirar elementos. El segundo, ac-modify-compression-rule, controla los Field Descriptions. El tercero, ac-modify-field, pretende separar ningún cambio, cambio de Target Value y cambio conjunto de TV, MO y CDA.

La cadena es restrictiva. La hoja de la regla de compresión sólo actúa si su padre permite modificar; la del campo necesita permiso de ambos padres. Un valor permisivo en profundidad no deroga un no-change superior. Si la hoja no está presente, el texto considera la información inmutable.

Además, son hojas de sólo lectura: config false. El editor remoto no puede escribir la autorización como paso previo a usarla. Eso evita una circularidad elemental.

Sin embargo, la cadena no incluye principal. No contiene usuario, grupo, certificado, sesión, propietario, delegación o versión de política. Indica el máximo cambio tolerado por el modelo de reglas. No determina qué identidad tiene acceso a ese máximo.

Dos controles complementarios

El propio borrador separa los papeles. Cita NACM como mecanismo para que usuarios y grupos realicen acciones, pero sostiene que esa granularidad no encaja por completo con las reglas SCHC. El RFC 8341 recibe del transporte un nombre de usuario autenticado y grupos, examina operaciones y nodos, y niega con access-denied. La política efectiva al iniciar un mensaje se mantiene durante todo su procesamiento.

NACM responde por el actor y la petición. Las hojas SCHC responden por el objeto y la forma de la mutación. La decisión segura es la intersección, no la alternativa. Un grupo amplio no debe poder saltarse la hoja de campo; una hoja permisiva no debe servir a cualquiera que llegue al endpoint.

Los protocolos de gestión aportan otras piezas. NETCONF exige autenticación y puede ofrecer validación, datastore candidato, bloqueo y rollback-on-error. RESTCONF puede condicionar una edición a un ETag mediante If-Match, útil cuando otro escritor ha cambiado el recurso. CORECONF lleva YANG sobre CoAP de manera compacta y exige impedir lectura y escritura no autorizadas, dejando que el despliegue elija mecanismos apropiados como DTLS, OSCORE o ACE OAuth.

Ninguna pieza aislada resuelve todo. CRUDX no modela por sí solo la semántica de cada Target Value. change-tv no autentica a nadie. Un bloqueo evita interferencia durante una transacción, pero no demuestra que el par SCHC haya activado la nueva regla.

Una escritura aceptada puede dejar dos realidades

La revisión 01 no especifica de dónde salen las hojas de sólo lectura, quién las aprovisiona, cómo se revocan o cómo se enlaza una identidad con la propiedad de un Context. Tampoco define control de versión, resolución de escritores simultáneos, atomicidad entre campos, activación, confirmación del par, auditoría o recuperación.

Son huecos de composición, no una prohibición de implementar. RESTCONF ya ofrece una forma de detectar versiones obsoletas. NETCONF puede aislar y validar cambios. Una plataforma puede guardar un historial y un punto conocido como bueno. Pero el operador debe ensamblar esos controles y demostrar el ensamblaje.

La diferencia decisiva aparece al activar. El servidor puede devolver 204 o <ok/> porque el datastore aceptó el cambio. Mientras tanto, el otro extremo puede seguir interpretando el RuleID con el Context anterior. El recibo de gestión acredita una escritura; no acredita aún una transición de protocolo.

Por eso el control debería registrar no sólo el resultado de la API, sino la revisión esperada, la revisión resultante, los pares afectados, la hora de activación, una prueba de compatibilidad y el camino de reversión. Sin estos datos, una acción válida en una capa puede crear un desacuerdo invisible en otra.

Un borrador muestra también sus límites

La versión estudiada es un Internet-Draft activo del grupo SCHC, con cabecera Standards Track y fecha de 29 de septiembre de 2026. No es un RFC. Terminology contiene ToDo; Security Considerations e IANA Considerations dicen TBD. El módulo YANG conserva una revisión de 2023 y texto sobre compound-ack y RFC YYYY; las descripciones de los valores de acceso al campo siguen diciendo Reserved slot number.

No conviene rellenar estas lagunas con supuestos. Son señales de que la interfaz y su análisis de amenazas pueden cambiar. El borrador de arquitectura SCHC de julio de 2026 pide autenticar y autorizar gestores, auditar cambios y poder restaurar un Context conocido, pero reconoce que ciclo de vida y gestión requieren más desarrollo.

Las fuentes no prueban despliegue general, interoperabilidad, rendimiento ni un caso real de abuso. La conclusión debe mantenerse a la escala de la evidencia: el diseño jerárquico es prometedor; su contrato operacional todavía debe componerse y madurar.

El recibo que falta en la automatización

Antes de aceptar una modificación con consecuencias, conservar:

  1. principal autenticado, grupos, sesión y protección del transporte;
  2. operación, Context, Set of Rules y RuleID de destino;
  3. revisión anterior o ETag y valores exactos antes/después;
  4. las tres capas de permisos SCHC aplicables;
  5. revisión de NACM o de la política equivalente;
  6. validación, exclusión de colisiones y resultado transaccional;
  7. activación por par y evidencia de compatibilidad;
  8. observación de servicio, responsable y punto de recuperación probado.

La automatización segura no convierte todos esos datos en un único «permitido». Mantiene visible quién decidió, qué objeto limitó la decisión, qué versión se transformó y quién asumió el efecto. La mutabilidad es una propiedad técnica. El mandato sigue necesitando un sujeto y una cadena de responsabilidad.

Sources