Resumen

  • Las etiquetas user, header, session, id e history seleccionaban superficies diferentes; no eran grados acumulativos de una orden universal de ocultación.
  • Identity/Identity-Info, Path, Replaces, Route, Service-Route y Target-Dialog quedaban fuera del objetivo directo, aunque algunos podían requerir otra actuación por integridad o por una correlación creada previamente.
  • El operador necesita recibos separados para la petición, la regla aplicable, la mutación, el estado conservado, la continuidad del protocolo y la exposición observada.

El proxy que confundió riesgo con mandato

Supongamos que una empresa instala una regla comprensible: cuando aparezca Privacy, elimine todo nombre de dominio que pueda delatar al usuario. El proxy encuentra un Route con el nombre de un proveedor, lo sustituye por un valor anónimo y registra que la información sensible ha desaparecido. El siguiente salto nunca recibe la petición.

El diagnóstico habitual dirá que la privacidad rompió la llamada. Es demasiado impreciso. La llamada se rompió porque una observación válida —el campo podía revelar algo— se convirtió sin autoridad en una acción distinta —alterar una instrucción de encaminamiento—. El problema no era perseguir privacidad, sino confundir tres capas: riesgo, permiso para actuar y resultado técnico.

La RFC 5379 surgió para reducir ese tipo de ambigüedad. Publicada en febrero de 2010 como documento Informational del Independent Stream, explicó la operación práctica de mecanismos definidos por las RFC 3323, 3325 y 4244. Declaró que no modificaba el mecanismo existente ni introducía conducta normativa nueva.

Esa condición importa. El documento no entregaba un poder adicional a los intermediarios. Ordenaba la lectura de poderes ya existentes y mostraba dónde terminaban.

Un vocabulario con objetos diferentes

La palabra privacidad podía engañar porque reunía solicitudes heterogéneas. user se refería a información insertada por el usuario. header trataba información de señalización añadida por la red. session actuaba sobre datos de la descripción de sesión. id atendía P-Asserted-Identity en el marco de confianza de la RFC 3325. history se ocupaba de History-Info. none y critical regulaban decisiones que no equivalían a una superficie adicional.

Por eso no era correcto ordenar los valores como una escala. Una petición session no contenía implícitamente todo lo que hacía header, ni user autorizaba a limpiar cualquier identificador encontrado. Cada valor necesitaba su objeto.

La RFC 5379 presentó una tabla por campos. Para unos recomendaba borrar; para otros, no añadir; para otros, anonimizar. También distinguía solicitudes y respuestas. La acción dependía del cruce exacto entre valor, campo y dirección.

En SDP, Privacy:session alcanzaba las líneas c, m, o, i, u, e y p. Era una lista concreta. Un producto que extendiera ese valor a todo el mensaje porque la sesión «incluye la llamada entera» estaría sustituyendo una definición técnica por una intuición verbal.

La primera condición de control es conservar el tipo. No basta guardar privacyRequested=true. Hay que retener los valores, el documento que les da sentido, el campo evaluado, la operación elegida y la condición que hizo segura esa operación.

Route mostraba el límite con claridad

La RFC enumeró seis grupos fuera del objetivo directo de esos valores: Identity/Identity-Info, Path, Replaces, Route, Service-Route y Target-Dialog. La instrucción no era que carecieran de información sensible, sino que no debían alterarse sobre la única base de un priv-value.

Route es la demostración más sencilla. Su contenido fuerza una petición a pasar por determinados proxies. Si el servicio lo anonimiza como si fuese un campo descriptivo, destruye la instrucción. Además, el valor va desapareciendo a medida que los proxies lo consumen, por lo que la exposición hacia participantes posteriores no se comporta como una etiqueta estática incluida para todos.

Path ofrece una tensión parecida. Puede indicar el dominio administrativo o visitado de un agente, pero también permite que las llamadas alcancen al usuario registrado. Ocultarlo sin conservar una ruta funcional sacrifica el propósito de la señalización. Si un operador quiere esconder topología, necesita una técnica y una autoridad propias, no una interpretación expansiva de la petición del usuario.

Service-Route aparece en respuestas de registro y describe al registrador. Replaces y Target-Dialog transportan identidad de otros diálogos. Todos pueden ser examinados desde la privacidad, pero ninguno queda sometido automáticamente al mismo acto por parecer cercano a la identidad.

La regla general es incómoda pero necesaria: un control no puede ampliar su competencia sólo porque detecta un riesgo real. Debe preservar el límite que permite a otros controles cumplir su función.

El campo no objetivo que debía retirarse

La lista tampoco era una orden de inmovilidad. Identity/Identity-Info expone el caso contrario.

La RFC 5379 utilizó el mecanismo histórico de la RFC 4474. Su firma cubría From, To, Call-ID, CSeq, Date, Contact y el cuerpo. Si un servicio de privacidad modificaba algunos de esos elementos, la firma dejaba de validar el mensaje resultante. Identity no era el objetivo de user, header o session, pero reenviar una prueba inválida tampoco era correcto.

El servicio podía necesitar retirar Identity por la pérdida de integridad. La causa debía registrarse así: una transformación autorizada sobre un campo protegido invalidó una prueba dependiente. No debía registrarse como si Privacy hubiese señalado directamente el campo Identity.

La RFC 4474 fue sustituida por la RFC 8224. No conviene convertir este ejemplo en configuración contemporánea sin consultar al sucesor. Sin embargo, la arquitectura probatoria sigue siendo válida: toda evidencia derivada depende de ciertos insumos. Si los insumos cambian, la evidencia debe revocarse o regenerarse por esa relación, no por una ficción retrospectiva sobre la solicitud original.

El identificador modificado seguía trabajando después

Call-ID muestra por qué una reescritura local puede generar una obligación distribuida. El servicio recibe C1 y emite C2. Debe conservar la correspondencia, porque futuros mensajes pueden mencionar el diálogo en In-Reply-To, Replaces, el parámetro replaces o Target-Dialog.

El mensaje posterior puede no incluir Privacy. Puede llegar desde otro participante y por otra ruta. Aun así, la traducción entre C1 y C2 será necesaria. Su fundamento no es una nueva orden del usuario. Es la deuda semántica que dejó la transformación anterior.

Los ejemplos de transferencia de la RFC 5379 son reveladores. Una petición REFER puede entregar a un tercero un identificador que éste utilizará en un INVITE con Replaces. Si el nuevo INVITE no atraviesa el servicio que conoce la correspondencia, o si el estado ya expiró, el diálogo buscado no existe desde la perspectiva del receptor. La privacidad fue aplicada al primer mensaje, pero la función del usuario se perdió más tarde.

Esto obliga a decidir antes de cambiar Call-ID: ¿permanecerá el servicio en todos los caminos relevantes?, ¿cuánto durará el estado?, ¿sobrevivirá a un reinicio?, ¿cómo se reconciliarán los nodos redundantes?, ¿qué ocurrirá con un diálogo largo o una devolución tardía?

Una métrica que marca éxito al emitir C2 ignora la mayor parte de la operación. El dueño de la mutación debe ser también dueño de la correlación hasta que ninguna transacción dependa de ella.

La política del proveedor no era la voz del usuario

El documento admitía variaciones de implementación y política de red. También reconocía que una información fuera de la tabla podía merecer tratamiento. Esa flexibilidad es legítima si se conserva la procedencia.

Un proveedor puede ejecutar ocultación de topología. Un dominio puede retirar P-Asserted-Identity cuando cruza hacia una entidad no confiable. Un servicio puede eliminar evidencia de integridad inválida. Un proxy puede restaurar Route después de haber transformado Record-Route. Son decisiones distintas.

Si el sistema las resume como «Privacy aplicado», la organización pierde la capacidad de atribuir daños y revisar reglas. La solicitud del usuario termina prestando legitimidad a actos que emitió el operador. La política local debe identificarse con su propio nombre, versión, propietario, ámbito y resultado.

Este punto excede SIP. Una señal técnica conserva su legitimidad cuando describe aquello para lo que fue creada. Cuando una institución la utiliza como paraguas para sus preferencias, el registro deja de ser evidencia y empieza a fingir mandato.

La ausencia del dato debía medirse desde algún lugar

Ni siquiera la ejecución exacta de la tabla prueba privacidad. Hay que definir el observador. El destinatario puede dejar de ver el nombre del llamante mientras el servicio intermedio lo conoce. El cuerpo SDP puede seguir revelando una dirección. Los registros de facturación pueden conservar una correlación. La eliminación de una firma puede revelar que hubo intervención.

Una prueba útil formula una afirmación limitada: el dato X no fue visible para el actor Y durante los mensajes Z y el flujo de medios correspondiente. También identifica qué sistemas conservaron capacidad de correlación y durante cuánto tiempo.

La prueba debe recorrer el camino: registro, INVITE inicial, respuestas, diálogo, transferencia, devolución y finalización. Debe comprobar simultáneamente no divulgación y continuidad de las funciones. Un paquete limpio que no llega no es un resultado satisfactorio. Una llamada completa que filtra el dato tampoco.

Documento, registro e implementación eran recibos diferentes

El estado Informational de la RFC 5379 evita otra inflación. Sus tablas son una guía de interpretación y no una fuente autónoma de todas las obligaciones que describen. El operador debe vincular cada comportamiento con la especificación normativa aplicable.

También debe conservar el tiempo. La RFC 4244 fue reemplazada por la RFC 7044; la RFC 4474, por la RFC 8224. El mecanismo histórico puede explicar por qué surgió una obligación sin demostrar cuál es hoy la implementación correcta.

IANA registra campos y valores SIP. El registro demuestra que existe una denominación compartida y una referencia. No demuestra soporte, ejecución correcta, estado duradero ni privacidad obtenida.

Un expediente operativo debe separar:

  • mensaje original, emisor y dirección;
  • valores solicitados y especificación vigente;
  • fila de la matriz elegida para cada campo;
  • política independiente aplicada fuera de ese objetivo;
  • cambio exacto y evidencia dependiente afectada;
  • correspondencias de identificadores y duración;
  • mensajes posteriores que las utilizaron;
  • resultado de ruta, diálogo, transferencia y medios;
  • exposición comprobada desde cada observador relevante.

La cadena mantiene modesta a cada capa. La solicitud pide. La tabla delimita. La política local se identifica. El servicio actúa. El estado mantiene la coherencia. La traza muestra si el protocolo funcionó. La medición demuestra, de forma acotada, qué permaneció privado.